Important New Requirement for IPv4 Requests

Not the annual report, the actual books and records, including details on individual expenses.

Well... ARIN is structured with a bottom-up community driven policy process. That has
served us well for many years, and, I think that changing it would be a mistake. However,
in this case, that means that the following people are specifically excluded from proposing
policy:

  The BoT (other than via the emergency process)
  ARIN Staff

Policy proposals must come from the community. Either at large, or, from the ARIN AC
which is an elected subgroup of the community tasked with developing good policy for
ARIN. The AC itself depends largely on community input for what kind of policy the
community wants us to develop, and, at the end of the day, community consensus is
required in order for a proposal to become policy.

It's served us so well that we are running out of IP space and no effective way to migrate to the already existing replacement solution. The argument that it's always been that way, just doesn't cut it. It's the same with all these issues. If ARIN were to hire someone whose job it was to avangelize a workable solution, I am sure you would see individuals willing to come forth and support it and create a consensus. And FYI, there is nothing saying that consensus is required for a proposal to become policy, look at the US government, they make policy every day without consensus. If the situation is as bad as it's being made out to be, then ARIN MUST act in the best interest of the community as a whole.

B) Again, while it might be the IETF's "job", shouldn't the group trusted with the management of the IP space at least have a public opinion about these solutions are designed. Ensuring that they are designed is such a way to guarantee maximum adoption of v6 and thus reducing the potential for depletion of v4 space.

The IETF specifically does not accept organizational input and requires instead that
individuals participate. This is one of the great strengths, and, also one of the great
weaknesses of the IETF. However, it means that even if ARIN could develop a public
opinion (which would have to come from the ARIN community by some process which
we don't really have as yet), this opinion wouldn't mean much in the IETF's eyes.

Again, if ARIN were to put out a "best practices" guide, and promote it as a way to push forward IPv6. Instead they are saying "not my problem" and "the guys who are working on it, won't let us play with them"

C) Are ARIN's books open for public inspection? If so, it might be interesting for the group to see where all our money is going, since it's obviously not going to outreach and solution planning. Perhaps it is being spent in a reasonable manner, and the fees are where they need to be to sustain the organizations reasonable operations, but perhaps not.

I will leave this to the BoT to answer, but, I know that the treasurer presents a report
at every members meeting which provides at least some high level details. I believe
that as a non-profit corporation, a great deal of openness is required for accountability
to ARIN members.

Why is travel such a large percentage of their expenses? If people want to be on the board, they should pay for their own travel to the meetings. This is a Not For Profit, not a corporation, big difference.

Mr Curran, given the response you've seen from the group, and in particular the argument that most CEO's or Officers of firms will simply sign off on what they IT staff tells them (as they have little to no understanding of the situation), can you explain what exactly you are hoping to achieve by heaping on yet an additional requirement to the already over burdensome process of receiving an IPv4 allocation?

I can't say what Mr. Curran expects, but, here's how I see it:

1. If an officer of the organization signs off, then, that means that both the
  organization and the officer personally can be held accountable for any
  fraud that is later uncovered. If the officer is an idiot, perhaps he'll just
  sign, but, most officers I have experience with don't do that. They usually
  engage in some level of verification before signing such a statement.

How do you figure, under what law is this enforceable? Most Officers will simply say to the person asking them to sign it "Is this true" and when they say yes, he'll sign it. The CEO of most corporation does not have the time, experience or expertise to determine if his firm truly needs additional IP Space.

2. Organizations which are submitting fraudulent requests may be less
  willing to do that when someone has to make a signed attestation under
  penalty of perjury. Especially when that person has fiduciary liability to
  the organization as an officer.

Again, what law are they violating? How is this considered perjury?

3. There are lots of things people will do if they don't think there are potential
  consequences. A signed attestation by a corporate officer dramatically
  reduces the apparent lack of consequences to a fraudulent application.

Sure, there will always be criminals and criminals may not be bothered
by this signed attestation process. However, having it does give the ARIN
legal team a better shot at them as well.

Again how does signing an attestation = criminal liability? Maybe civil liability, but certainly not criminal liability.

B) Again, while it might be the IETF's "job", shouldn't the group trusted with the management of the IP space at least have a public opinion about these solutions are designed. Ensuring that they are designed is such a way to guarantee maximum adoption of v6 and thus reducing the potential for depletion of v4 space.

The IETF specifically does not accept organizational input and requires instead that individuals participate.

So how is the RIR model where you become a member and then participate better? If ARIN or the other RIRs have compelling arguments the only reason those arguments are compelling is because of their merit, not because they're from a RIR.

it means that even if ARIN could develop a public
opinion (which would have to come from the ARIN community by some process which
we don't really have as yet), this opinion wouldn't mean much in the IETF's eyes.

Well, if you, ARIN, or anyone else has input that should be considered when writing with a better specification for an IPv6-IPv4 translator, please let us know.

For the past year or so the IETF behave working group has been considering the issue, and looked at a whole bunch of scenarios: from a small IPv6 network to the public IPv4 internet, to private IPv4 addresses, from a small IPv4 network to the public IPv6 internet, to (not entirely) private IPv6 addresses. The IPv6->IPv4 case seems doable with a bunch of caveats (it's still NAT) and we (for some value of "we") want to get it out fast, but the other way around looks much more difficult and will at the very least take longer.

The softwire(s?) working group is looking at tunneling IPv4 over IPv6 towards a big "carrier grade NAT" so IPv4 hosts/applications can still work across an IPv6 access network with only one layer of NAT.

In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user.

So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses.

Iljitsch van Beijnum wrote:

In v6ops CPE requirements are being discussed so in the future, it should be possible to buy a $50 home router and hook it up to your broadband service or get a cable/DSL modem from your provider and the IPv6 will be routed without requiring backflips from the user.

So there is a fair chance that we'll be in good shape for IPv6 deployment before we've used up the remaining 893 million IPv4 addresses.

I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published?

If the IETF is talking "future" and developers are also talking "future", us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on.

/RANT

Jack

I think this annoys people more than anything. We're how many years into the development and deployment cycle of IPv6? What development cycle is expected out of these CPE devices after a spec is FINALLY published?

That's certainly one way to look at this, and I'm just as unhappy about how long this has taken as you. On the other hand, it has been argued that these issues are outside the scope of the IETF in the first place, as it's just application of already established protocols, not developing something new. So another way to look at it is that at least the IETF is finally doing something because so far, nobody else has. What would have helped here is more push in this direction.

If the IETF is talking "future" and developers are also talking "future", us little guys that design, build, and maintain the networks can't really do much. I so hope that vendors get sick of it and just make up their own proprietary methods of doing things. Let the IETF catch up later on.

People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established.

Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers.

Iljitsch van Beijnum wrote:

What would have helped here is more push in this direction.

What really would help is more people who are not on NANOG pushing vendors to support IPv6. Even my Juniper SE has mentioned that I'm one of 2 people he's had seriously pushing for IPv6 features. Other vendors have just blown me off all together (we'll have it sometime).

People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established.

Serious input and participation means work and money. Too much for me. Doesn't help that when I was a wee one, mom dated someone who bragged about his status in the IETF and even had a pen. Sad way to be introduced to any organization, but I have seen similar mentalities regarding IETF mentioned here reinforcing my belief that arrogance is alive and I don't have the time and money to deal with it.

Proprietary methods duking it out in the market place is nice for stuff that happens inside one box or at least within one administrative domain, but it would be a nightmare in broadband deployment where I want my Windows box to talk to my Apple wifi base station and my Motorola cable modem to the ISP's Cisco headend and their Extreme switches and Juniper routers.

Sure, but the largest missing pieces for IPv6 are single box implementations. Proprietary NAT is single box. Will it break stuff? Probably, but when hasn't it? Corporate networks won't care. They'll deploy the vendor that supports it if that is what they want. BRAS/Aggregation is another single box solution but defines everything about an edge broadband network, supported by the access devices (switches, dslams, wireless ap/backhauls, etc). The layer 3 aware access devices all tend to have their own single box methods of security (DHCP snooping, broadcast scoping, etc, etc). I've seen quite a few systems that can't turn the security support off and break IPv6 because of it.

Jack

Ron Bonica is leading a BOF during NANOG46 in Philly which may be of interest -

BOF: IETF OPS & MGMT Area,
Ron Bonica, Juniper Networks
Presentation Date: June 14, 2009, 2:00 PM - 3:30 PM

Abstract:
The IETF OPS & MGMT Area documents management technologies and
operational best common practices. The purpose of this BoF is to
review activities in that area and solicit feedback to determine the
usefulness of those activities to the operator community. We will also
solicit proposals for new work that is of interest to users.

The full agenda is up at - http://www.nanog.org/meetings/nanog46/agenda.php
Cheers, -ren

This work is actually mostly being done by some guys at Cisco, and other vendors have plenty of input as well.

I would be surprised if CPEs that support the outcome of this work are far behind the RFC being published (or even a late draft).

Jack Bates wrote:

Iljitsch van Beijnum wrote:

In v6ops CPE requirements are being discussed so in the future, it
should be possible to buy a $50 home router and hook it up to your
broadband service or get a cable/DSL modem from your provider and the
IPv6 will be routed without requiring backflips from the user.

So there is a fair chance that we'll be in good shape for IPv6
deployment before we've used up the remaining 893 million IPv4 addresses.

I think this annoys people more than anything. We're how many years into
the development and deployment cycle of IPv6? What development cycle is
expected out of these CPE devices after a spec is FINALLY published?

ipv6 cpe devices have been / are being developed already. the doesn't
mean there isn't more work to be done, in

If the IETF is talking "future" and developers are also talking
"future", us little guys that design, build, and maintain the networks
can't really do much. I so hope that vendors get sick of it and just
make up their own proprietary methods of doing things. Let the IETF
catch up later on.

Generally the presumption is that people bring work that they are
working on to the table. I work for an equipment vendor, if there's no
reason for us to implement something why would would we expend cycles to
work on it in the IETF either?

What really would help is more people who are not on NANOG pushing vendors to support IPv6. Even my Juniper SE has mentioned that I'm one of 2 people he's had seriously pushing for IPv6 features. Other vendors have just blown me off all together (we'll have it sometime).

Right. And I'm also the only one asking for 32-bit AS numbers.

People who run networks can do a lot: believe it or not, the IETF really wants input from network operators, especially in the early phases of protocol development when the requirements are established.

Serious input and participation means work and money.

You can participate on mailinglists without attending meetings, so in that sense it doesn't have to cost money. As an operator, it would make sense to spend a little time in the requirements phase but not after that. So yes, it would take time, but we're not talking about hours a day on an ongoing basis.

Doesn't help that when I was a wee one, mom dated someone who bragged about his status in the IETF

:slight_smile:

and even had a pen. Sad way to be introduced to any organization, but I have seen similar mentalities regarding IETF mentioned here reinforcing my belief that arrogance is alive and I don't have the time and money to deal with it.

In any case, if you have input on this whole NAT64 business, let me and/or Fred know. If you have input on anything else, speak up on this list or a NANOG meeting and there's a decent chance that someone will take those comments back to the IETF.

After trying to participate on mailing lists for about 2 or 3 years, it's pretty hard to get anything done without going to meetings.

Just participating in mailing lists is good for keeping up to date, but not so good for getting things changed.

That's what I've found, anyway. Might not always be true.

Depends on the issue. Sometimes bad ideas get traction in the IETF, it's hard to undo that. But there are also times when even a single message containing good arguments can have an effect.

Also don't expect too much from IETF participation: if doing X is going to make a vendor more money than doing Y, they're going to favor X, even if Y is the superior solution.

Iljitsch van Beijnum wrote:

Depends on the issue. Sometimes bad ideas get traction in the IETF, it's hard to undo that. ....

That's an understatement.

Also don't expect too much from IETF participation: if doing X is going to make a vendor more money than doing Y, they're going to favor X, even if Y is the superior solution.

Some wag around here re-christened it the IVTF (V stands for Vendor, not
Victory). :wink: I haven't bothered to go in years....

If you were to go to meetings, you would realize that it won't help in "gettings things changed" significantly better than active mailing list participation would... :-/

If the people with operational experience stop going, you can't blame the group for
being full of vendors.

Methinks its time a large cabal of network operators should represent
at IETF and make their opinions heard as a collective group.
That would be how change is brought about in a participative organisation,
no? :slight_smile:

Adrian

Operator participation in IETF has been a problem for at least
  18 years. I remember a fairly large dustup w/ John Curran and
  Scott Bradner over why the OPS area was so lacking in actual
  operators at the Columbus IETF. Its never gotten any better.

  IETF used to be populated by developers and visionaries (grad students
  with lofty ideas). Once commercialization set in (they graduated
  and got jobs) their funding sources changed from government grants
  to salaries. And management took a more active role. the outcome
  is that vendors now control much of the IETF participation and indirectly
  control IETF output.

  just my 0.02 from the cheap seats.

--bill

I got heaps done in SFO - to the point where I'm happy to pay to get to Stockholm and Hiroshima later this year (I'm self employed, and live at the end of the world, so for me it's harder than most who just have to convince the boss :-).

Why don't you start by simpling stating what you want to have happen?

So far I've seen a number of messages complaining about the IETF (btw, if you like complaining about the IETF, go to the meetings, there is significant time set aside for that there) but not a single technical request, remark or observation.

The IETF works by rough consensus. That means if people disagree, nothing much happens. That is annoying. But a lot of good work gets done when people agree, and a lot of the time good technical arguments help.

Like I said, the IETF really wants input from operators. Why not start by giving some?

Apologies for a somewhat latent response - I was attending an IPv6
Seminar (of which ARIN was a sponsor) the last two days and am just
getting to nanog mail today.

I'm not sure if anyone agrees with me, but these responses seem like a big
cop out to me.

A) If ARIN is so concerned about the potential depletion of v4 resources,
they should be taking a more proactive roll in proposing potential solutions
and start conversation rather then saying that the users should come up with
a proposal which they then get a big vote one.

"They" is YOU. ARIN policy is created by the community - "Your voice,
your community." The statement should read: If [you] are so concerned
about the potential depletion of v4 resources, [you] should be taking
a more proactive [role] in proposing potential solutions and
start[ing] conversation.

If you participated in the ARIN PDP (1), even by just lurking on the
ppml (2), you would already be aware that many folks have proposed
many potential solutions (some of which have already been adopted) and
that there _is_ an ongoing conversation that I strongly encourage you
to join.

B) Again, while it might be the IETF's "job", shouldn't the group trusted
with the management of the IP space at least have a public opinion about
these solutions are designed. Ensuring that they are designed is such a way
to guarantee maximum adoption of v6 and thus reducing the potential for
depletion of v4 space.

I think that developing resource management policy to meet those goals
is much more in line with ARINs mandate. As I mentioned above, this
is happening.

C) Are ARIN's books open for public inspection? If so, it might be
interesting for the group to see where all our money is going, since it's
obviously not going to outreach and solution planning. Perhaps it is being
spent in a reasonable manner, and the fees are where they need to be to
sustain the organizations reasonable operations, but perhaps not.

Links to annual statements etc. have already been provided. I am sure
an email to ARIN (3) would help you answer your question further.

Mr Curran, given the response you've seen from the group, and in particular
the argument that most CEO's or Officers of firms will simply sign off on
what they IT staff tells them (as they have little to no understanding of
the situation), can you explain what exactly you are hoping to achieve by
heaping on yet an additional requirement to the already over burdensome
process of receiving an IPv4 allocation?

I obviously can not speak for Mr. Curran, but I do applaud this
effort. I believe that adding this requirement will lower
exaggeration and fraud as well as raise awareness. These are both
noble goals and well worth the marginal effort required. The argument
that most officers will sign anything put in front of them is not very
convincing to me. I have a hard time accepting incompetence or
laziness as a valid rational for any argument at all really.

~Chris (speaking for myself)

(1) - https://www.arin.net/participate/policy/pdp/
(2) - https://www.arin.net/participate/community/mailing_lists/
(3) - mailto:info@arin.net

Chris Grundemann wrote:

"They" is YOU. ARIN policy is created by the community - "Your voice,
your community." ...

If you participated in the ARIN PDP (1)...

Ok, so am I the only one who missed which policy proposal this was that generated the new requirement that an officer sign off on the request for more IPv4 space?

I can't find the Policy Proposal number or the Draft Policy ID, but then maybe I'm not looking hard enough.

Matthew Kaufman