I-D Action:draft-azinger-scalable-addressing-00.txt

[Michael Sinatra]

On 09/25/10 20:15, Mark Smith wrote:
> On Sat, 25 Sep 2010 12:28:46 -0700
> Michael Sinatra<ms at berkeley.edu>  wrote:
>
>> On 09/24/10 23:51, Fred Baker wrote:
>>> I would appreciate opinions from the operators forum; please post
>>> comments to v6ops at ietf.org.
>>>
>>> The IPv6 Operations Working Group has been asked to adopt this
>>> document as a working group draft. In essence, the outcome would
>>> become a suggestion to the RIR and *NOG communities regarding the way
>>> the IETF would suggest that IPv6 prefixes be allocated. Note the use
>>> of the word "suggest". In summary, what this says is that the IETF
>>> holds no strong opinions about specific prefix lengths or boundaries,
>>> but strongly feels that the allocation policies should be scalable -
>>> which means that PI allocations to edge networks should be done only
>>> when Really Truly Appropriate.
>>>
>>> My question is: is this something that the operational community
>>> would consider helpful, or is it something the operational community
>>> would prefer the IETF kept its nose out of? If the operational
>>> community would find it helpful, is the specific suggestion
>>> reasonable from an operational perspective?
>>
>> I may be a bit of a curmudgeon here, but I think one sentiment you might
>> hear from the operations community is: "No thank-you.  The IETF has
>> already done more than enough to place obstacles in front of IPv6
>> adoption, particularly by 'end sites'.  We don't need to add to that."
>>
>
> I'm curious as to what specifically these obstacles are or have been?

The thread has moved a bit beyond this topic, but I think it's useful to 
go over this, since my statement has been characterized as stating the 
the IETF has deliberately put obstacles in the way of v6 adoption. 
While there probably are some in the ops community that believe this, I 
don't quite agree.  However, regardless of the intent of the IETF, IPv6 
adoption has been less than seamless (to say the least), and the IETF 
bears some responsibility for that, despite their good efforts (more on 
that later).

Obstacle 1: IPv6 is on-the-wire incompatible with IPv4.  This has been 
pointed out by many others (including Randy Bush in his various IPv6 vs. 
Operational Reality presentations), but the point still stands.  Could 
the IETF have created a protocol that was sufficiently compatible?  I 
honestly don't know, but the IETF is ultimately responsible for IPv6 and 
for asking the operations community to adopt an incompatible protocol. 
I think it's reasonable for the ops community to make a good faith 
effort to adopt, but that brings us to obstacle 2.

Obstacle 2: IPv6 was designed to be massively aggregable with only PA 
addressing.  However, no reasonable mechanism was ever deployed or even 
proffered to deal with multi-homing and the routing policy derived from 
that (cf. shim6), nor for renumbering (cf. A6 DNS records).  I actually 
agree with Fred that ILNP and even stateless prefix translation are 
promising, but we have to move forward now with the IPv6 we have, not 
the one we want.  While this probably isn't the IETF's fault, a 
reasonable response from the ops community is "so you want me to deploy 
this thing, but it is incompatible *and* it doesn't give me as much 
freedom to multi-home and change providers as IPv4 does.  Great!"

Obstacle 3: IPv6 was designed with service-providers, not end-users, in 
mind.  Keep in mind that I am actually coming at this from a 
service-provider perspective.  As I said before, IPv6's PA-only 
addressing architecture imposes more costs on end users and generates 
more benefit for service-providers.  There simply hasn't been incentive 
for end sites to adopt IPv6, and that's led to a situation where IPv6 
adoption is well behind where most of us think it needs to be.

The RIRs have responded to these obstacles in pretty much the only way 
they can: In response to the demands of their paying members, they have 
liberalized the PI assignment of IPv6 address space.  There is no 
disagreement that this has serious implications for the DFZ routing 
table.  There is also no disagreement that this is a critical time, and 
the previous anemic adoption of IPv6 has been a big problem given the 
current state of IPv4 address run-out.

I don't fault the IETF for producing these obstacles in the first place. 
  What I do fault the IETF for doing is for essentially ignoring the 
obstacles and how the ops community has attempted to overcome them and 
insisting that we go back the the beginning with an essentially PA-only 
IPv6 Internet.

michael