Subject: Re: [v6ops] ULA Usage Guide draft requesting for review

From: Mark Smith <[email-masked]>
Date: Fri, 1 Mar 2013 00:18:18 -0800 (PST)

----- Original Message -----
> From: Brian E Carpenter <[email-masked]>
> To: Owen DeLong <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Sent: Thursday, 28 February 2013 10:29 PM
> Subject: Re: [v6ops] ULA Usage Guide draft requesting for review
> 
> On 28/02/2013 09:23, Owen DeLong wrote:
>>  On Feb 28, 2013, at 00:50 , Brian E Carpenter 
> <[email-masked]> wrote:
> 
> ...
>>  What is the significant benefit to "without PI"?
> 
> Saving BGP4. Using a PI prefix is selfish as far as the
> Internet is concerned, so we need to encourage alternatives.
> 
>> 
>>  PI seems to be very nice as near as I can tell. It is working very
>>  well here.
>> 
>>>>  Section 3.1
>>>> 
>>>>  The last sentence should be deleted. GUA is an equally viable
>>>>  option for these networks.
>>>  Only if you have an ISP, which by definition you don't.
>> 
>>  ?? I know of a number of networks that are using GUA for those
>>  purposes without involving an ISP. Could you explain why you
>>  think that's not possible?
> 
> You need to get your prefix either from an ISP or from an LIR.
> You don't need to talk to anyone, or pay anyone, to get your ULA
> prefix. In fact, it can be generated automatically in a SOHO
> scenario, so that the user doesn't have to know anything.
> 

I agree. I think requiring a GUA prefix to build a private IPv6 network is fundamentally creating an annual licence fee model for the use of IPv6 technology.

For projects such as the following one, annual RIR or ISP fees for a GUA would probably be exorbitant, and not good value considering the other things that the money could help provide, such as cleaner water, better education or better health care.

http://villagetelco.org/about/

.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Mar 2013 08:57:31 +0000

On 01/03/2013 00:40, joel jaeggli wrote:
> On 2/28/13 12:14 PM, Owen DeLong wrote:
>> On Feb 28, 2013, at 3:29 AM, Brian E Carpenter
> Strictly speaking PI holders are not the obnoxious polluters in the
> routing system to today. there are ~43K AS in my internet today.
> somewhat less then half of them announce only one route yet there are
> 445K routes in my ipv4 table.
> 
> Is is plausble to assert that there a potentially a lot more multihomers
> out there then there are ISPs. 

Well yes, and the concern (which led to LISP among other things) is
that the potential number of multihomers is more like ten million than
43K. At the moment there is a loose correlation between the number
of active AS and the number of PI prefixes, but it's when that
correlation breaks that we will have a big problem.

ULA takes away one of the arguments for PI. Of course I agree with
Owen that encouraging NPTv6 would be a very bad thing.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Mar 2013 01:03:04 -0800

> 
>> Section 2.2.2.1
>> 
>> IMHO, this section should be deleted in its entirety or at least come with a
>> strong cautionary note that such designs are ill-conceived and detrimental in
>> nature. Pretending that NAT or NPT improve security at all is dubious at best.
>> In fact, NPT and especially NAT provide more tall weeds for attackers to hide
>> in, if anything.
> 
> [Bing] Such designs come from special requirements such as the abovementioned information security sensitive enterprises or governments. If you want the endpoints disconnected as default and only connected via central control, it is quite reasonable to pick ULA+Proxy. 
> However, normally we won't recommend to use ULA in this model. But I think it might not be proper to justify such scenarios as ill. My point is: if you really have special requirements, just use it in this model; but please don't misunderstanding ULA was just designed for this kind of use.
> 

Then clarify that this is only intended to address ULA on default-disconnected + Proxy networks and _NOT_ NAT or NPT which should never be used with ULA.

>> AL Proxies can be implemented equally effectively using GUA and there is no
>> significant advantage to ULA in such a case.
> 
> [Bing] If require endpoints default disconnected, egress filtering would be easier and more stable for ULA than GUA. And can save some operation to apply PA/PI.
> 

I disagree. I can filter 2001:db8::/32 just as easily as I can filter fc00::7.

Either way, it's just an entry in a prefix list.

By definition, ULA isn't in any default prefix lists or hard coded into being blocked by routers, so there are no special global default semantics to it that distinguish it from GUA. Only human convention.

>> 
>> Section 3.1
>> 
>> The last sentence should be deleted. GUA is an equally viable option for
>> these networks.
>> 
>> Section 3.3.2
>> 
>> I'm unable to decipher Paragraph 2, so I cannot make a suggestion on
>> rewording it. However, since I can't tell what you're trying to say, I'm pretty
>> sure it needs to be rewritten.
> 
> [Bing] It is only a corner case, that is, if the NAT64 prefix is shorter than 48/, it would divide the 40bit of ULA into two parts. But in most of the practices NAT64 just use 96/. I'll rewritten it for ease of reading. 
> 

That's probably best addressed in a document that says "If you're going to do NAT-64, then don't use a prefix shorter than /48". Certainly there's no need to do so.

Thanks,

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Mar 2013 01:05:41 -0800

> correlation breaks that we will have a big problem.

Pretty much by definition, the correlation will remain. However, the number
of ASNs is now scoped to n<2^32, so that's still a really large number of
prefixes.

> Owen that encouraging NPTv6 would be a very bad thing.

It really doesn't. It just creates another opportunity for ISPs to treat their customers
as captive second class citizens all over again.

We never should have punted on solving the routing scale problem in IPv6.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Mar 2013 10:05:03 +0000

Owen,

We're getting close to off-topic, but...

On 01/03/2013 09:05, Owen DeLong wrote:
> Pretty much by definition, the correlation will remain. 

I don't think so. As the Internet matures, more and more small business
users will want redundancy, i.e. two service providers. That will break
the linkage between AS and multihoming, and then the correlation
might vanish.

> However, the number

We didn't punt; we tried and failed. IMHO it's still the hardest problem we
have, but that discussion belongs elsewhere.

   Brian

---

From: "Liubing (Leo)" <[email-masked]>
Date: Fri, 1 Mar 2013 11:32:45 +0000

> > [Bing] Such designs come from special requirements such as the
> abovementioned information security sensitive enterprises or governments.
> If you want the endpoints disconnected as default and only connected via
> central control, it is quite reasonable to pick ULA+Proxy.
> > However, normally we won't recommend to use ULA in this model. But I
> think it might not be proper to justify such scenarios as ill. My point is: if you
> really have special requirements, just use it in this model; but please don't
> misunderstanding ULA was just designed for this kind of use.
> >
> 
> Then clarify that this is only intended to address ULA on
> default-disconnected + Proxy networks and _NOT_ NAT or NPT which should
> never be used with ULA.

[Bing] Generally we consider ULA+NAT a not recommended model for connected network. But if you for some reason chose to use NAT, then ULA is a natural selection.
The reason to use NAT, my understanding is as section 1 of RFC6296(NPTv6), to get the address independence without acquiring PI. And also some benefits as described in section 4 of RFC4864.

> > [Bing] If require endpoints default disconnected, egress filtering would be
> easier and more stable for ULA than GUA. And can save some operation to
> apply PA/PI.
> >
> 
> 

[Bing] It is actually the discussion of distinctive range between you and Victor. 

I realize there are several important topics that are not so explicit. I'll try to summarize them according to the discussion and raise some new threads.

Best regards,
Bing

---

From: Ivan Pepelnjak <[email-masked]>
Date: Fri, 1 Mar 2013 16:32:07 +0100

Speaking of potential multihomers, there are large corporations that will have to make every single site (read: high thousands) PI multihomed. We've spent loads of time with one of them, trying every possible design option, and it was either NPT66 or PI /48 per site.

Welcome to the brave (or is it broken?) new world.

=====
Mistyped and autocorrected on a clunky virtual keyboard

On 1. mar. 2013, at 09:57, Brian E Carpenter <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Mar 2013 18:49:05 -0800

> The reason to use NAT, my understanding is as section 1 of RFC6296(NPTv6), to get the address independence without acquiring PI. And also some benefits as described in section 4 of RFC4864.

Which is why I want to see a statement in this draft that notes the tradeoffs and that these solutions are not recommended before it advances.

Owen

---

From: Doug Barton <[email-masked]>
Date: Fri, 01 Mar 2013 21:36:08 -0800

> Which is why I want to see a statement in this draft that notes the tradeoffs and that these solutions are not recommended before it advances.

Documenting the tradeoffs would be useful, yes. "Not recommended" is 
almost certainly going too far.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Fri, 1 Mar 2013 21:52:47 -0800

On Mar 1, 2013, at 21:36 , Doug Barton <[email-masked]> wrote:

> Documenting the tradeoffs would be useful, yes. "Not recommended" is almost certainly going too far.
> 

In the case of NPTv6, I really don't think that it is.  There are serious impacts to the intended nature of IPv6 if NPT starts getting widely deployed.

Owen

---

From: Doug Barton <[email-masked]>
Date: Fri, 01 Mar 2013 22:24:23 -0800

> In the case of NPTv6, I really don't think that it is.  There are serious impacts to the intended nature of IPv6 if NPT starts getting widely deployed.

Yes, I get that there are a lot of people in the IPv6 literati that wish 
for the return of the end-to-end model, and dramatically resist anything 
that tries to take that away. The problem, as was recently discussed 
(again) in nauseating detail on [email-masked] is that most 
organizations not only don't want end-to-end back, they prioritize ease 
of renumbering much higher than any benefits IPv6 might bring.

Because for end user networks there is no compelling reason to deploy 
IPv6 right now, nor is there likely to be one in the near future, we 
need to understand the real world needs for those organizations, and 
focus on ways to deliver them. ULA + NPTv6 does that, and the costs are 
minimal (although not non-existent, which is why documenting the 
tradeoffs is valuable).

Even for those end-user networks where PI space makes sense (and I would 
argue that they are few and far between) the costs, both monetary in 
terms of RIR fees, and opex; are non-zero, so discussing the pros _and_ 
cons of all the solutions will have value for the target audience.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sat, 2 Mar 2013 05:12:58 -0800

> Yes, I get that there are a lot of people in the IPv6 literati that wish for the return of the end-to-end model, and dramatically resist anything that tries to take that away. The problem, as was recently discussed (again) in nauseating detail on [email-masked] is that most organizations not only don't want end-to-end back, they prioritize ease of renumbering much higher than any benefits IPv6 might bring.
> 
> Because for end user networks there is no compelling reason to deploy IPv6 right now, nor is there likely to be one in the near future, we need to understand the real world needs for those organizations, and focus on ways to deliver them. ULA + NPTv6 does that, and the costs are minimal (although not non-existent, which is why documenting the tradeoffs is valuable).
> 

The cost is not minimal. The cost is borne not by those deploying NPT. The cost is borne by every application developer, every security professional, law enforcement, etc.

NPT and NAT are the network equivalent of the toxic polluter model. Sure, it's cheap to dump toxic chemicals into the creek upstream. The true costs are borne by those downstream, not the person dumping the chemicals.

> Even for those end-user networks where PI space makes sense (and I would argue that they are few and far between) the costs, both monetary in terms of RIR fees, and opex; are non-zero, so discussing the pros _and_ cons of all the solutions will have value for the target audience.

An up front $1,250 and an annual $100 is _NOT_ a significant expense IMHO and that is what PI  /48 costs from ARIN. I don't know about the other RIRs.

In terms of Opex, PI costs no more and probably somewhat less than NPT because if it is set up correctly, it's basically fire and forget. The configuration complexity for changing providers is no greater than that with NPT+ULA. You get the further advantage that you can have actually redundant routers, not just redundant connections (the NPT solution basically requires putting both providers into a single box or REALLY complex workarounds such as STONITH to make sure only one router sends RAs at a time).  You also get the advantage that sessions can (and usually do) survive a failover event.

Owen

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Mar 2013 13:43:08 -0800

On 03/02/2013 05:12 AM, Owen DeLong wrote:
>>>>
>>>
>>> In the case of NPTv6, I really don't think that it is.  There are
>>> serious impacts to the intended nature of IPv6 if NPT starts
>>> getting widely deployed.
>>
>> Yes, I get that there are a lot of people in the IPv6 literati that
>> wish for the return of the end-to-end model, and dramatically
>> resist anything that tries to take that away. The problem, as was
>> recently discussed (again) in nauseating detail on
>> [email-masked] is that most organizations not only don't
>> want end-to-end back, they prioritize ease of renumbering much
>> higher than any benefits IPv6 might bring.
>>
>> Because for end user networks there is no compelling reason to
>> deploy IPv6 right now, nor is there likely to be one in the near
>> future, we need to understand the real world needs for those
>> organizations, and focus on ways to deliver them. ULA + NPTv6 does
>> that, and the costs are minimal (although not non-existent, which
>> is why documenting the tradeoffs is valuable).
>>
>
> The cost is not minimal. The cost is borne not by those deploying
> NPT. The cost is borne by every application developer, every security
> professional, law enforcement, etc.

To some extent I agree with you, but these are already sunk costs. We 
already have v4 NAT, and application developers who care have already 
solved these problems. Most of them get better with NPTv6, some of them 
stay the same, none of them get worse. But railing against these costs 
are pointless because _they are never going away_. NAT of some form will 
always exist, the end-to-end model is never coming back, PLEASE adjust 
to this reality, since not doing so actively damages the cause of IPv6 
deployment.

> NPT and NAT are the network equivalent of the toxic polluter model.
> Sure, it's cheap to dump toxic chemicals into the creek upstream. The
> true costs are borne by those downstream, not the person dumping the
> chemicals.

Histrionics don't help here. And saying these kinds of things to serious 
people who already have/like their v4 NAT makes us all look foolish, and 
ensures that the people you're trying to persuade will not take v6 
seriously.

>> Even for those end-user networks where PI space makes sense (and I
>> would argue that they are few and far between) the costs, both
>> monetary in terms of RIR fees, and opex; are non-zero, so
>> discussing the pros _and_ cons of all the solutions will have value
>> for the target audience.
>
> An up front $1,250 and an annual $100 is _NOT_ a significant expense
> IMHO

Great! I'll send you my PayPal info and you can put that amount in my 
account. Heck, I'll even give you a discount, say an even grand?

Seriously though, When you look at the options of zero cost, vs. some 
non-zero cost, it's hard for most organizations to justify, especially 
when the reason we think they should pay it doesn't line up with their 
operational needs.

> and that is what PI  /48 costs from ARIN. I don't know about the
> other RIRs.
>
> In terms of Opex, PI costs no more and probably somewhat less than
> NPT because if it is set up correctly, it's basically fire and
> forget.

I'm far from a network expert, but I would think that coordinating your 
ISP announcing your PI block would take more effort in both setup and 
ongoing updates/monitoring than it would to set up NPTv6 on the border. 
The latter only needs to be changed/updated when you change providers. 
But I'm happy to concede this point to anyone who can provide solid facts.

> The configuration complexity for changing providers is no
> greater than that with NPT+ULA. You get the further advantage that
> you can have actually redundant routers, not just redundant
> connections (the NPT solution basically requires putting both
> providers into a single box or REALLY complex workarounds such as
> STONITH to make sure only one router sends RAs at a time).  You also
> get the advantage that sessions can (and usually do) survive a
> failover event.

In my mind the NPTv6 + ULA solution is targeted more towards those that 
only have a single provider in the first place. As in, the overwhelming 
majority of mid-size and SOHO market that makes up the majority of the 
enterprise end-user networks. Those who already have multiple providers 
should be looking at PI and multihoming, I agree with you there.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sat, 2 Mar 2013 15:19:28 -0800

On Mar 2, 2013, at 13:43 , Doug Barton <[email-masked]> wrote:

> To some extent I agree with you, but these are already sunk costs. We already have v4 NAT, and application developers who care have already solved these problems. Most of them get better with NPTv6, some of them stay the same, none of them get worse. But railing against these costs are pointless because _they are never going away_. NAT of some form will always exist, the end-to-end model is never coming back, PLEASE adjust to this reality, since not doing so actively damages the cause of IPv6 deployment.

That statement shows a profound misunderstanding of the situation.

Most applications haven't yet been ported to IPv6. Adding support for IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide variety of NATs and other oddities surrounding network behavior related to NAT require substantial regression testing and QA for every release. That's _NOT_ a sunk cost. It's an ongoing tax.

The question is not whether NAT will exist or not, but, whether it will remain in use by a sufficiently large mass to drive the industry. Many of us are still holding out hope that with IPv6, it will not. It's still possible and it's a perfectly valid reason to state in an RFC discussing intended uses of ULA that NPT and NAT are NOT recommended in IPv6.

> Histrionics don't help here. And saying these kinds of things to serious people who already have/like their v4 NAT makes us all look foolish, and ensures that the people you're trying to persuade will not take v6 seriously.
> 

This isn't histrionics. It's a simple fact... Deploying NAT/NPT does, in fact, inflict costs on others that are not borne by those deploying NAT and those costs are not currently considered by most NAT fanatics.

> Great! I'll send you my PayPal info and you can put that amount in my account. Heck, I'll even give you a discount, say an even grand?
> 

Very funny.

> Seriously though, When you look at the options of zero cost, vs. some non-zero cost, it's hard for most organizations to justify, especially when the reason we think they should pay it doesn't line up with their operational needs.
> 

I suppose that's because you aren't considering all of the costs. ULA isn't free. NPT isn't free. The fact that you want to pretend it is doesn't make it so.

I would bet that the annualized cost of maintaining all the extra code and the additional security risks involved in running a network with translation far exceed $100/year. So much so that I bet you get your $1,250 back in less than 4 years.  For most finance people, that's what they call a no-brainer.

> I'm far from a network expert, but I would think that coordinating your ISP announcing your PI block would take more effort in both setup and ongoing updates/monitoring than it would to set up NPTv6 on the border. The latter only needs to be changed/updated when you change providers. But I'm happy to concede this point to anyone who can provide solid facts.
> 

It shows. On the other hand, I've got almost 30 years of experience as a network expert and have actually done this many times. Coordinating your ISP accepting your announcement of your block and forwarding it on usually takes an email or two, sometimes including a form. In terms of ongoing updates, there actually aren't usually any unless/until you switch providers.

Those are the solid facts. I'm not sure what else you want.

Here's a BGP configuration from a router actually running multihomed dual-stack connectivity to two upstream ISPs through two different connections. It's a little
bit more complex because the sessions with AS8121 are on another router that's in a different location and it's set up to have a second peer router at its same
location which also has connections to the other remote routers (AS6939 and AS8121), but even this more complex scenario is, as you can see below, pretty simple.

bgp {
    local-as 1734;
    group HE {
        type external;
        import from-he;
        family inet6 {
            any;
        }
        export to-he;
        peer-as 6939;
        neighbor 2001:470:1f03:9c::1;
    }
    group internal {
        type internal;
        export ibgp-next-hop-self;
        peer-as 1734;
        neighbor 2620:0:930:7000::1 {
            family inet6 {
                unicast;
            }
            export v6-next-hop-self;
        }
        neighbor 2620:0:930:7001::1 {
            family inet6 {
                unicast;
            }
            export v6-next-hop-self;
        }
        neighbor 192.124.40.193 {
            local-address 192.124.40.194;
            import via-cable;
            family inet {
                unicast;
            }
        }
        neighbor 192.124.40.197 {
            local-address 192.124.40.198;
            import via-dsl;
            family inet {
                unicast;
            }
        }
    }
}

> In my mind the NPTv6 + ULA solution is targeted more towards those that only have a single provider in the first place. As in, the overwhelming majority of mid-size and SOHO market that makes up the majority of the enterprise end-user networks. Those who already have multiple providers should be looking at PI and multihoming, I agree with you there.

I think that's a temporary majority, frankly. The internet is becoming too mission critical to accept single-homing for much longer in most cases. Many of my clients are actually paying me to move them to multi-homed connectivity and this seems to be a growing trend.

Frankly, if you're single-homed, you're better off setting up your network for easy renumbering, running static provider-assigned prefixes, and taking a month with both prefixes present to renumber the network. It's really not that hard in IPv6 and can be done with almost no disruption to the users. (Yes, I've done this a couple of times for medium-sized networks. If you plan for it in the original network design it really can be pretty straight forward.)

Owen

---

From: Doug Barton <[email-masked]>
Date: Sat, 02 Mar 2013 16:31:10 -0800

> Most applications haven't yet been ported to IPv6. Adding support for IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide variety of NATs and other oddities surrounding network behav…

Assuming you are right about all of this (which to some extent you are, 
but for sake of argument let's say you're 100% right) it still doesn't 
matter. Adding NPTv6 support is in the statistical noise from a 
development perspective. Well-written applications need little or no 
additional development work to support IPv6, poorly written ones will 
need to be updated, but that's going to be true regardless, and adding 
NPT support is still going to be a small marginal cost.

The ongoing "tax" you refer to is going to be paid regardless, because 
v4 NAT is never, ever going away; and we're 20-30 years away from v4 
support being a thing of the past.

> The question is not whether NAT will exist or not, but, whether it will remain in use by a sufficiently large mass to drive the industry. Many of us are still holding out hope that with IPv6, it wi…

Yes, I understand your position thoroughly. My point is that "not 
recommended" is at best pollyanish, and at worst counter productive. 
OTOH, a fair, rational discussion of the tradeoffs is beneficial to all 
concerned.

> This isn't histrionics. It's a simple fact... Deploying NAT/NPT does, in fact, inflict costs on others that are not borne by those deploying NAT and those costs are not currently considered by most…

"Toxic waste" analogies are histrionic by definition. And even if I 
fully agreed with your arguments about how bad NAT is, telling people 
that use/like it that they are the network equivalent to toxic waste 
dumpers is not only not helping, it's hurting.

>> Great! I'll send you my PayPal info and you can put that amount in my account. Heck, I'll even give you a discount, say an even grand?

So what you're saying is that you would consider sending me $1,000 to be 
a not-insignificant expense?

> I suppose that's because you aren't considering all of the costs. ULA isn't free. NPT isn't free. The fact that you want to pretend it is doesn't make it so.

I'm not saying it's free, I'm saying "Let's rationally discuss the 
tradeoffs." It is unarguably true that ULA does not require an RIR fee, 
but putting down the other costs in writing will help people to make up 
their minds about which costs they are willing to bear.

> I would bet that the annualized cost of maintaining all the extra code and the additional security risks involved in running a network with translation far exceed $100/year. So much so that I bet y…

... except for my now-oft-repeated point that those costs are never 
going to go away. Not to mention that most enterprise end-user networks 
are not in the business of code development, so your concern doesn't 
apply to them.

> Those are the solid facts. I'm not sure what else you want.

So ISPs never reconfigure routers, BGP sessions never flap, nothing ever 
happens with this kind of configuration that needs ongoing monitoring 
and updates?

> I think that's a temporary majority, frankly. The internet is becoming too mission critical to accept single-homing for much longer in most cases. Many of my clients are actually paying me to move…

No argument there, but your sample is severely corrupted by volunteer 
bias. The number of small-medium enterprises who could not even spell 
"multihomed" is pretty vast.

> Frankly, if you're single-homed, you're better off setting up your network for easy renumbering, running static provider-assigned prefixes, and taking a month with both prefixes present to renumber…

Again, for those that actually are, or will be multihomed we're in 
agreement. My argument is for the overwhelming majority of small-medium 
enterprises who will not ever be multihomed. The perceived benefits of 
v4 NAT, especially no need to ever renumber, are much more important 
than anything v6 can provide them. They don't want the end-to-end model 
back, no matter how much some of us think they should.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Sun, 3 Mar 2013 01:28:47 -0800

> Assuming you are right about all of this (which to some extent you are, but for sake of argument let's say you're 100% right) it still doesn't matter. Adding NPTv6 support is in the statistical noise from a development perspective. Well-written applications need little or no additional development work to support IPv6, poorly written ones will need to be updated, but that's going to be true regardless, and adding NPT support is still going to be a small marginal cost.

Again, I cannot agree with you here. Your attempt to classify any application that wants to be talking end-to-end without having its packets mutilated along the way as "poorly written" simply doesn't hold water. There are lots f reasons to want to be able to communicate (reasonably) directly and not all of them involve including layer 3 addressing as layer 7 payload (which I believe is what you actually intended to target).

Consider, for example, the desire to host some sort of collaborative process on a desktop machine without requiring a third-party rendezvous server. That's not a poorly written application, it's a perfectly valid one which requires that the host machine have an accessible global address.

Sure, some enterprises may want to block such activities and they can do that perfectly well through policy and stateful inspection. No need for NPT and NPT brings no benefit to that process.

> The ongoing "tax" you refer to is going to be paid regardless, because v4 NAT is never, ever going away; and we're 20-30 years away from v4 support being a thing of the past.

I disagree. I think IPv4 will drop into the noise much faster than you expect because it will become so completely expensive to maintain that nobody will want to touch it.

> Yes, I understand your position thoroughly. My point is that "not recommended" is at best pollyanish, and at worst counter productive. OTOH, a fair, rational discussion of the tradeoffs is beneficial to all concerned.

I'm all for a fair rational discussion of the tradeoffs. However, I think it is reasonable and prudent at the end of that discussion to include the conclusion that damaging the protocol in such a manner is not recommended.

> "Toxic waste" analogies are histrionic by definition. And even if I fully agreed with your arguments about how bad NAT is, telling people that use/like it that they are the network equivalent to toxic waste dumpers is not only not helping, it's hurting.

From webseter:

Definition of HISTRIONICS

1
: theatrical performances
2
: deliberate display of emotion for effect

I don't think it qualifies as a theatrical performance.
It wasn't a display of emotion, it was a simple analogy about who pays the true cost.

> So what you're saying is that you would consider sending me $1,000 to be a not-insignificant expense?
> 

No, what I'm saying is that I had no problem paying for my PI assignment and I cannot imagine an actual business operation that wants to be multihomed finding it difficult to cover the minimal expenses involved in obtaining addresses to do so.

Given the number of different things involved in just creating a business that cost more than that, I don't find it a very credible argument.

> I'm not saying it's free, I'm saying "Let's rationally discuss the tradeoffs." It is unarguably true that ULA does not require an RIR fee, but putting down the other costs in writing will help people to make up their minds about which costs they are willing to bear.

Your quote (still present above) states "zero cost". That's the same as 'free" by most people's definition, so yes, you did say it was free. It's in your quote above.

A rational discussion of the tradeoffs has to include the real costs, regardless of who bears them. People who like/want NAT like/want it because it allows them to dump the cost burden on others. Admittedly, many of them do not realize that they are doing so, just like there was a time when people didn't realize the impact that dumping stuff in the oceans was having.

> ... except for my now-oft-repeated point that those costs are never going to go away. Not to mention that most enterprise end-user networks are not in the business of code development, so your concern doesn't apply to them.

Yes, you keep repeating this, but it isn't true and repeating it doesn't make it true just because you want it to be true.

I already agreed with you about the last part... In fact, that's the part that lines up with the toxic polluter as an analogy, not histrionics. Unfortunately, you were too caught up in dismissing what I was saying as histrionics to actually look at the metaphor.

> So ISPs never reconfigure routers, BGP sessions never flap, nothing ever happens with this kind of configuration that needs ongoing monitoring and updates?

Monitoring, yes. As to configuration changes, very very rarely. ISPs don't like to make customer effecting changes. They take a lot of time and coordination and they are very expensive. They also tend to make customers unhappy. As such, we try to avoid them whenever possible. A BGP session flap doesn't require a configuration change, it requires fixing the problem. If the configuration on the router worked last week and it doesn't work this week, the configuration on the router isn't the thing that changed, so the question is what did. If the ISP changed their configuration, then you may need to change the local configuration, but that's going to rarely be the case. More often, you need to do one of the following:

	1.	Get the circuit fixed. (most common problem)
	2.	Get the ISP to fix whatever they accidentally changed on their side.
	3.	Investigate a more unusual problem in more detail before taking any action.

In case 3, that's not any more or less likely to happen with a BGP session than it is with a static routed session going through NAT/NPT and it's not any more difficult to debug/troubleshoot. In fact, since you don't have to trace things through state tables and address mutilations in the headers, it's usually quite a bit easier.

As an example,  think the last time I changed the BGP configuration I included was about 3.5 years ago.

> No argument there, but your sample is severely corrupted by volunteer bias. The number of small-medium enterprises who could not even spell "multihomed" is pretty vast.

Today, that's true. However, the number that can say "Hey, Mr. IT consultant, our internet isn't reliable enough and when its down, our credit card processor doesn't work any more. Is there any way we can get a more reliable internet connection?" is not nearly so limiting. If "Mr. IT Consultant" has half a brain, he figures out how to get them multi-homed. If he doesn't, then he's one of those guys that gives the rest of us a bad name.

> Again, for those that actually are, or will be multihomed we're in agreement. My argument is for the overwhelming majority of small-medium enterprises who will not ever be multihomed. The perceived benefits of v4 NAT, especially no need to ever renumber, are much more important than anything v6 can provide them. They don't want the end-to-end model back, no matter how much some of us think they should.

That's because those people largely don't know how much easier it is to renumber in IPv6. Seriously, renumbering (especially prefix-only renumbering) can be done for the average SME over the course of about a month without significant disruption and without even requiring all that many man hours in the process. It's not like IPv4. That part did actually get mostly fixed in IPv6.

Owen

---

From: Gert Doering <[email-masked]>
Date: Sun, 3 Mar 2013 14:06:11 +0100

Hi,

> Those are the solid facts. I'm not sure what else you want.

Please get back a bit closer to reality...

Ever tried setting up a BGP session with comcast cable or verizon LTE?

Most lower-budget ISP connections will not come with the option to run
BGP there - over here, the difference is somewhere between "30 EUR a 
month for a 16 Mbit ADSL line with a PA /56 assigned to it" and 
"starting at 100 EUR/month for the same line, but with BGP routing".

BGP isn't free on the provider side - all the mass-market (=cost-saving)
provisioning tools won't really help you, as there are lots of steps
that need to be done and verified for every new customer.  Yes, much of
this can be automated (and usually is), but it's still much more effort
than "not doing BGP".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: joel jaeggli <[email-masked]>
Date: Sun, 03 Mar 2013 07:47:42 -0800

> this can be automated (and usually is), but it's still much more effort
Bgp peering with your providers is a comparatively high-touch service 
for an ISP. The price is structured accordingly particularly at retail 
volumes. wholesale transit customers enjoy large encomies of scale on 
pricing.

Customer aggregation routers in retail ISPs (or datacenters) frequently 
don't need to carry a full table, consequently they are much cheaper, 
but also they can't provide you with one. That can be done therefore 
with a multihop bgp session from a device which can, with all the 
attendant considerations that entails.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 3 Mar 2013 09:09:56 -0800

already have v4 NAT, and application developers who care have already
solved these problems. Most of them get better with NPTv6, some of them
stay the same, none of them get worse. But railing against these costs are
pointless because _they are never going away_. NAT of some form will always
exist, the end-to-end model is never coming back, PLEASE adjust to this
reality, since not doing so actively damages the cause of IPv6 deployment.

Doug

Afaik, the  ietf is fundamentally committed to the e2e model. The ietf
structure allows for revisiting this topic everyday, but I would advise not
to. Especially in this working group.

I, for one, only participate in the ietf for the purpose of facilitating
the e2e model whenever possible. E2e fits my world view as well as my
employer's bottom line.

CB
> Seriously though, When you look at the options of zero cost, vs. some
non-zero cost, it's hard for most organizations to justify, especially when
the reason we think they should pay it doesn't line up with their
operational needs.
ISP announcing your PI block would take more effort in both setup and
ongoing updates/monitoring than it would to set up NPTv6 on the border. The
latter only needs to be changed/updated when you change providers. But I'm
happy to concede this point to anyone who can provide solid facts.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 3 Mar 2013 09:27:11 -0800

> Please get back a bit closer to reality...

I base this entirely on reality. I'm running it today.

> Ever tried setting up a BGP session with comcast cable or verizon LTE?

Services not offered, at least presently.

> "starting at 100 EUR/month for the same line, but with BGP routing".

I can point to readily available free BGP peering, so I don't buy your premise.

> this can be automated (and usually is), but it's still much more effort

Interesting. http://tunnelbroker.net as a counterpoint.

Owen

---

From: Gert Doering <[email-masked]>
Date: Sun, 3 Mar 2013 21:54:31 +0100

Hi,

> Interesting. http://tunnelbroker.net as a counterpoint.

Paid from your marketing budget.  It will not be free forever.

Sure, you can get free tunnel-based BGP-routed IPv6 today, and 
tunnelbroker.net is quite impressive for automating all these things - 
do you provide it for IPv4?  Do you provide it comparatively-priced
if not based on tunnels, but on a normal end-customer line, with a 
price similar to what I pay for an ADSL line at DTAG?

I also wonder how it does things like "verification of customer 
announcements, with AS data spread over (at least) 5 different IRR 
databases"...  as that is part of what makes BGP customer connections
more work than mass market.

Gert Doering
        -- NetMaster

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Mar 2013 00:14:30 -0800

Given that we've entered the "misquote/misrepresent what I wrote in the 
past" phase of the discussion, I will restate my position one more time, 
then stop boring people. :)

The short version for the list is that I definitely think fairly stating 
the pros and cons of the various alternatives would be a valuable 
addition to the document. I think that saying ULA + NPTv6 is "not 
recommended" is way too much.

Regarding this most recent post ...

When I said "poorly written," I was referring to those applications 
still using the old get*by*() functions instead of more modern ones like 
getaddrinfo() which bring you IPv6 compatibility basically for free. 
OTOH, in this day and age any application that needs to allow outside 
hosts to connect in which doesn't have a NAT traversal strategy is in 
fact poorly written.

Your example of desktop collaboration software will work perfectly well 
inside the firewall, where NPT is irrelevant. There are precious few 
enterprises that allow any connections in, whether they use NAT or not. 
This isn't going to change, and is one of the chief reasons why the 
whole "we need to go back to the end-to-end model" mantra is so much 
foolishness.

My "zero cost" comment was in the context of RIR fees, which you 
conveniently snipped out. I have never said that ULA + NPT comes with 
absolutely no cost at all, any more than NAT, PI, or PA space do. That 
is why a fair discussion of the tradeoffs will be valuable.

Finally, enterprises HATE renumbering. The costs associated are not 
merely limited to giving systems new addresses, they include changing 
firewall rules, ACLs, applications, configurations, etc. I could tell 
you horror stories about how deeply embedded bad assumptions and 
practices are rampant in the average enterprise, but the short version 
is that enterprises hate renumbering, and not without good reason. 
Telling an enterprise "renumbering is easy, it only takes a month" would 
get me laughed out of the room.

In short, ULA + NPTv6 meets a real need, in spite of the costs, and 
should be included in the analysis of any solution matrix in this space.

Doug

On 03/03/2013 01:28 AM, Owen DeLong wrote:
>>> Most applications haven't yet been ported to IPv6. Adding support for
>>> IPv6 NPT and NAT traversal is _NOT_ a sunk cost. Further, the wide
>>> variety of NATs and other oddities surrounding network behavior
>>> related to NAT require substantial regression testing and QA for
>>> every release. That's _NOT_ a sunk cost. It's an ongoing tax.
>>
>> Assuming you are right about all of this (which to some extent you
>> are, but for sake of argument let's say you're 100% right) it still
>> doesn't matter. Adding NPTv6 support is in the statistical noise from
>> a development perspective. Well-written applications need little or no
> Again, I cannot agree with you here. Your attempt to classify any
> application that wants to be talking end-to-end without having its
> packets mutilated along the way as "poorly written" simply doesn't hold
> water. There are lots f reasons to want to be able to communicate
> (reasonably) directly and not all of them involve including layer 3
> addressing as layer 7 payload (which I believe is what you actually
> intended to target).
>
> Consider, for example, the desire to host some sort of collaborative
> process on a desktop machine without requiring a third-party rendezvous
> server. That's not a poorly written application, it's a perfectly valid
> one which requires that the host machine have an accessible global address.
>
> Sure, some enterprises may want to block such activities and they can do
> that perfectly well through policy and stateful inspection. No need for
> NPT and NPT brings no benefit to that process.
>
> I disagree. I think IPv4 will drop into the noise much faster than you
> expect because it will become so completely expensive to maintain that
> nobody will want to touch it.
>
>>
>>> The question is not whether NAT will exist or not, but, whether it
>>> will remain in use by a sufficiently large mass to drive the
>>> industry. Many of us are still holding out hope that with IPv6, it
>>> will not. It's still possible and it's a perfectly valid reason to
>>> state in an RFC discussing intended uses of ULA that NPT and NAT are
>>> NOT recommended in IPv6.
>>
>> OTOH, a fair, rational discussion of the tradeoffs is beneficial to
>> all concerned.
>
> I'm all for a fair rational discussion of the tradeoffs. However, I
> think it is reasonable and prudent at the end of that discussion to
> include the conclusion that damaging the protocol in such a manner is
> not recommended.
>
>>
>>>> Histrionics don't help here. And saying these kinds of things to
>>>> serious people who already have/like their v4 NAT makes us all look
>>>> foolish, and ensures that the people you're trying to persuade will
>>>> not take v6 seriously.
>>>>
>>>
>>> This isn't histrionics. It's a simple fact... Deploying NAT/NPT does,
>>> in fact, inflict costs on others that are not borne by those
>>> deploying NAT and those costs are not currently considered by most
>>> NAT fanatics.
>>
>     Definition of /HISTRIONICS/
>
> 1
> *:* theatrical performances
> 2
> *:* deliberate display of emotion for effect
>
>>>> Great! I'll send you my PayPal info and you can put that amount in
>>>> my account. Heck, I'll even give you a discount, say an even grand?
>>>>
>>>
>>> Very funny.
>>
> No, what I'm saying is that I had no problem paying for my PI assignment
> and I cannot imagine an actual business operation that wants to be
> multihomed finding it difficult to cover the minimal expenses involved
> in obtaining addresses to do so.
>
> Given the number of different things involved in just creating a
> business that cost more than that, I don't find it a very credible argument.
>
>>>> Seriously though, When you look at the options of zero cost, vs.
>>>> some non-zero cost, it's hard for most organizations to justify,
>>>> especially when the reason we think they should pay it doesn't line
>>>> up with their operational needs.
>>>>
>>>
>>> I suppose that's because you aren't considering all of the costs. ULA
>>> isn't free. NPT isn't free. The fact that you want to pretend it is
>>> doesn't make it so.
>>
>> tradeoffs." It is unarguably true that ULA does not require an RIR
>> fee, but putting down the other costs in writing will help people to
>> make up their minds about which costs they are willing to bear.
>
> Your quote (still present above) states "zero cost". That's the same as
> 'free" by most people's definition, so yes, you did say it was free.
> It's in your quote above.
>
> A rational discussion of the tradeoffs has to include the real costs,
> regardless of who bears them. People who like/want NAT like/want it
> because it allows them to dump the cost burden on others. Admittedly,
> many of them do not realize that they are doing so, just like there was
> a time when people didn't realize the impact that dumping stuff in the
> oceans was having.
>
>>
>>> I would bet that the annualized cost of maintaining all the extra
>>> code and the additional security risks involved in running a network
>>> with translation far exceed $100/year. So much so that I bet you get
>>> your $1,250 back in less than 4 years.  For most finance people,
>>> that's what they call a no-brainer.
>>
>> going to go away. Not to mention that most enterprise end-user
>> networks are not in the business of code development, so your concern
>> doesn't apply to them.
>
> Yes, you keep repeating this, but it isn't true and repeating it doesn't
> make it true just because you want it to be true.
>
> I already agreed with you about the last part... In fact, that's the
> part that lines up with the toxic polluter as an analogy, not
> histrionics. Unfortunately, you were too caught up in dismissing what I
> was saying as histrionics to actually look at the metaphor.
>
>>>> I'm far from a network expert, but I would think that coordinating
>>>> your ISP announcing your PI block would take more effort in both
>>>> setup and ongoing updates/monitoring than it would to set up NPTv6
>>>> on the border. The latter only needs to be changed/updated when you
>>>> change providers. But I'm happy to concede this point to anyone who
>>>> can provide solid facts.
>>>>
>>>
>>> It shows. On the other hand, I've got almost 30 years of experience
>>> as a network expert and have actually done this many times.
>>> Coordinating your ISP accepting your announcement of your block and
>>> forwarding it on usually takes an email or two, sometimes including a
>>> form. In terms of ongoing updates, there actually aren't usually any
>>> unless/until you switch providers.
>>>
>> So ISPs never reconfigure routers, BGP sessions never flap, nothing
>> ever happens with this kind of configuration that needs ongoing
>> monitoring and updates?
>
> Monitoring, yes. As to configuration changes, very very rarely. ISPs
> don't like to make customer effecting changes. They take a lot of time
> and coordination and they are very expensive. They also tend to make
> customers unhappy. As such, we try to avoid them whenever possible. A
> BGP session flap doesn't require a configuration change, it requires
> fixing the problem. If the configuration on the router worked last week
> and it doesn't work this week, the configuration on the router isn't the
> thing that changed, so the question is what did. If the ISP changed
> their configuration, then you may need to change the local
> configuration, but that's going to rarely be the case. More often, you
> need to do one of the following:
>
> 1.Get the circuit fixed. (most common problem)
> 2.Get the ISP to fix whatever they accidentally changed on their side.
> 3.Investigate a more unusual problem in more detail before taking any
> action.
>
> In case 3, that's not any more or less likely to happen with a BGP
> session than it is with a static routed session going through NAT/NPT
> and it's not any more difficult to debug/troubleshoot. In fact, since
> you don't have to trace things through state tables and address
> mutilations in the headers, it's usually quite a bit easier.
>
>>>> In my mind the NPTv6 + ULA solution is targeted more towards those
>>>> that only have a single provider in the first place. As in, the
>>>> overwhelming majority of mid-size and SOHO market that makes up the
>>>> majority of the enterprise end-user networks. Those who already have
>>>> multiple providers should be looking at PI and multihoming, I agree
>>>> with you there.
>>>
>>> I think that's a temporary majority, frankly. The internet is
>>> becoming too mission critical to accept single-homing for much longer
>>> in most cases. Many of my clients are actually paying me to move them
>>> to multi-homed connectivity and this seems to be a growing trend.
>>
> Today, that's true. However, the number that can say "Hey, Mr. IT
> consultant, our internet isn't reliable enough and when its down, our
> credit card processor doesn't work any more. Is there any way we can get
> a more reliable internet connection?" is not nearly so limiting. If "Mr.
> IT Consultant" has half a brain, he figures out how to get them
> multi-homed. If he doesn't, then he's one of those guys that gives the
> rest of us a bad name.
>
>>> Frankly, if you're single-homed, you're better off setting up your
>>> network for easy renumbering, running static provider-assigned
>>> prefixes, and taking a month with both prefixes present to renumber
>>> the network. It's really not that hard in IPv6 and can be done with
>>> almost no disruption to the users. (Yes, I've done this a couple of
>>> times for medium-sized networks. If you plan for it in the original
>>> network design it really can be pretty straight forward.)
>>
>> agreement. My argument is for the overwhelming majority of
>> small-medium enterprises who will not ever be multihomed. The
>> perceived benefits of v4 NAT, especially no need to ever renumber, are
>> much more important than anything v6 can provide them. They don't want
>> the end-to-end model back, no matter how much some of us think they
>> should.
>
> That's because those people largely don't know how much easier it is to
> renumber in IPv6. Seriously, renumbering (especially prefix-only
> renumbering) can be done for the average SME over the course of about a
> month without significant disruption and without even requiring all that
> many man hours in the process. It's not like IPv4. That part did
> actually get mostly fixed in IPv6.
>
> Owen
>

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Mar 2013 00:35:34 -0800

On 03/03/2013 09:09 AM, Cameron Byrne wrote:
> Doug
>
> Afaik, the  ietf is fundamentally committed to the e2e model.

[citation needed]

> The ietf
> structure allows for revisiting this topic everyday, but I would advise
> not to. Especially in this working group.
>

Cameron,

With all due respect to those involved, the history of the IETF, and 
particularly some of those who have pushed various aspects of the IPv6 
protocol as it was envisioned 15 years ago, is replete with decisions 
that show a stunning lack of familiarity with real world needs.

The fact that it took the content networks years to drag the IPv6 
literati kicking and screaming into allowing for PI space is one 
excellent example. The continuing failure to permit a full-featured 
DHCPv6 protocol is similarly slowing down adoption by the end-user 
networks.

The whole concept of "returning to the end-to-end model" is 
anachronistic, and does not meet the needs of the overwhelming majority 
of end-user networks. Completely aside from the NAT/renumbering issues, 
the firewalls on nearly all enterprise networks are closed. The same 
should be true for home users, in fact one could argue that it's more 
important there. Thus, any software that needs to allow connections from 
the outside in has to have something like UPNP/PMP, or a rendezvous 
server; so whether it's punching that hole in "just a SPIF," or "SPIF + 
NAT/NPT" doesn't matter.

So, yes ... I will continue to talk about this problem, until I'm 
confident that all of the right people understand it.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2013 13:17:39 +0000

On Mar 4, 2013, at 3:35 AM, Doug Barton <[email-masked]>
 wrote:
> The fact that it took the content networks years to drag the IPv6 literati kicking and screaming into allowing for PI space is one excellent example. The continuing failure to permit a full-featured DHCPv6 protocol is similarly slowing down adoption by the end-user networks.

?

---

From: Gert Doering <[email-masked]>
Date: Mon, 4 Mar 2013 15:25:30 +0100

Hi,

> > The fact that it took the content networks years to drag the IPv6 literati kicking and screaming into allowing for PI space is one excellent example. The continuing failure to permit a full-featu…

I think he's lamenting the lack of routing information in DHCPv6.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2013 15:06:55 +0000

> I think he's lamenting the lack of routing information in DHCPv6.

Huh.   That's not what I would call out as DHCPv6's biggest lack... :)

---

From: Gert Doering <[email-masked]>
Date: Mon, 4 Mar 2013 16:09:31 +0100

Hi,

> Huh.   That's not what I would call out as DHCPv6's biggest lack... :)

So what is it that you're missing?  "Sane implementations" is not really
something the IETF can provide.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Mon, 4 Mar 2013 15:12:11 +0000

> something the IETF can provide.

Support for multiple provisioning domains is high on my list.   Support for DNS zone maintenance as well.

---

From: Nalini Elkins <[email-masked]>
Date: Mon, 4 Mar 2013 08:35:32 -0800 (PST)

We would like to invite everyone to a snack BoF to talk about the special needs of end user organizations who run large data centers.   It will be on Wed. March 13th 1710-1740 at one end of the Caribbean Foyer where the beverage and snack break is held.   Our group includes three large end user organizations.  We hope to talk with anyone who is interested in such issues.

For whoever wants to, we can continue after the IETF and Operations Plenary & over dinner & drinks.

There has been some discussion on this list about addressing 'real-world' problems.  We could not agree more!

Thanks,

Nalini Elkins
Inside Products, Inc.
(831) 659-8360
www.insidethestack.com

________________________________

---

From: Gert Doering <[email-masked]>
Date: Mon, 4 Mar 2013 20:00:32 +0100

Hi,

> Support for multiple provisioning domains is high on my list.   Support for DNS zone maintenance as well.

But that's all in the "all software sucks" domain, not that much IETF 
standards can do about it.  Or am I misunderstanding you?

The general beef in the IETF IPv6 working groups seems to be that one
camp wants "everything that's needed to configure a host" in RA, and the
other camp thinks DHCP is good enough for everything and thinks having
to run RA as well is evil, and should not be done.  Or such.

I think people from both camps should be drowned somewhere, for refusing 
to acknowledge that networks in the real world out of their ivory towers 
*differ* in nature, and some would benefit from "just RA" while others 
might want "just DHCPv6".

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Mar 2013 12:50:58 -0800

On Mar 4, 2013, at 12:14 AM, Doug Barton <[email-masked]> wrote:

> Given that we've entered the "misquote/misrepresent what I wrote in the past" phase of the discussion, I will restate my position one more time, then stop boring people. :)
> 
> The short version for the list is that I definitely think fairly stating the pros and cons of the various alternatives would be a valuable addition to the document. I think that saying ULA + NPTv6 is "not recommended" is way too much.
> 
> When I said "poorly written," I was referring to those applications still using the old get*by*() functions instead of more modern ones like getaddrinfo() which bring you IPv6 compatibility basically for free. OTOH, in this day and age any application that needs to allow outside hosts to connect in which doesn't have a NAT traversal strategy is in fact poorly written.

What on earth does that have to do with whether they survive or function correctly in a NAT/NPT world or not?

As to the latter, it is an assertion which assumes multiple "facts" not in evidence.

> Your example of desktop collaboration software will work perfectly well inside the firewall, where NPT is irrelevant. There are precious few enterprises that allow any connections in, whether they use NAT or not. This isn't going to change, and is one of the chief reasons why the whole "we need to go back to the end-to-end model" mantra is so much foolishness.

There's lots of desktop collaboration that occurs outside of the enterprise world. Further, with the ever increasing level of BYOD, multiple connectivities, etc. I think that our authentication and authorization models for network traffic are going to change significantly in the future, especially when you consider things that are possible with MIP6. I think you'll see more end-to-end ESP/AH used rather than straight firewalls and that you will see direct untranslated traversal through the firewall of packets which are part of valid existing security associations or which are intended to set up such security associations.

> My "zero cost" comment was in the context of RIR fees, which you conveniently snipped out. I have never said that ULA + NPT comes with absolutely no cost at all, any more than NAT, PI, or PA space do. That is why a fair discussion of the tradeoffs will be valuable.

You stated that one option had costs and the other option did not. I pointed out (rightly so) that you were choosing to focus on one of the costs in the overall system and ignoring the others.

It's sort of like saying that driving a private car is a no-cost option because you don't have to pay a fare every time you get into the car while ignoring the cost of gasoline, maintenance, and vehicle registration.

I admit that this is a popular way for enterprises to look at the issue of NAT vs. PI, but it doesn't change the facts of the matter.

> Finally, enterprises HATE renumbering. The costs associated are not merely limited to giving systems new addresses, they include changing firewall rules, ACLs, applications, configurations, etc. I could tell you horror stories about how deeply embedded bad assumptions and practices are rampant in the average enterprise, but the short version is that enterprises hate renumbering, and not without good reason. Telling an enterprise "renumbering is easy, it only takes a month" would get me laughed out of the room.

As I said, one has to plan ahead and construct the network with the anticipation of renumbering up front, or it does, indeed, hurt at least once. In IPv4, it was virtually impossible to do so and such assumptions are rampant. In IPv6, it would be easy for such assumptions to become rampant, but we do have the option of doing it better this time and we should try to make use of that option.

> In short, ULA + NPTv6 meets a real need, in spite of the costs, and should be included in the analysis of any solution matrix in this space.

In short, ULA+NPTv6 may provide convenience for those that are too lazy to learn to do things right, but that's far from meeting a real legitimate need.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Mar 2013 13:02:33 -0800

On Mar 4, 2013, at 12:35 AM, Doug Barton <[email-masked]> wrote:

> With all due respect to those involved, the history of the IETF, and particularly some of those who have pushed various aspects of the IPv6 protocol as it was envisioned 15 years ago, is replete with decisions that show a stunning lack of familiarity with real world needs.

True.

> The fact that it took the content networks years to drag the IPv6 literati kicking and screaming into allowing for PI space is one excellent example. The continuing failure to permit a full-feature…

Revisionist history.

As the author of the first successful policy which allowed PI space in IPv6, I will point out the following factual errors in your statement:

	1.	The content networks were not really part of the discussion.
	2.	The IPv6 literati (whoever they are supposed to be) were not really part of the discussion, either.
	3.	This was done as an RIR policy in the ARIN region through the ARIN Internet Resource Policy
		Evaluation Process (IRPEP) which was later subsumed by the PDP and now the revised PDP.
	4.	The policy has now been replaced by an even more liberal IPv6 assignment policy which was
		primarily written by David Farmer (University of Michigan), but which I made significant contributions
		to. I was (at the time) primarily focused on making sweeping changes to the ISP IPv6 allocation
		policy. I'm happy to say that both policies are now in place and operational in the ARIN region and
		that it is easier than ever before to obtain IPv6 addressing in very generous quantities.

The only feature missing from DHCPv6 that is at all significant is the ability to provide routing information. There are actually sufficient tools within the RA framework that this feature, while desirable in order to facilitate existing role distribution within the enterprise, is not vital and is more of an excuse than a reason for any failure to deploy IPv6.

> The whole concept of "returning to the end-to-end model" is anachronistic, and does not meet the needs of the overwhelming majority of end-user networks. Completely aside from the NAT/renumbering issues, the firewalls on nearly all enterprise networks are closed. The same should be true for home users, in fact one could argue that it's more important there. Thus, any software that needs to allow connections from the outside in has to have something like UPNP/PMP, or a rendezvous server; so whether it's punching that hole in "just a SPIF," or "SPIF + NAT/NPT" doesn't matter.

No, it isn't. Yes, enterprises (and others) want to block end-to-end communication in many cases. Fine, that's up to them to do as they wish through firewalls, packet filters, stageful inspection, whatever. However, end-to-end addressing is neither anachronistic, nor undesirable. It meets many needs for many people outside of those enterprises and will, in fact, support future needs in those very enterprises of which you speak when other things are more mature as I described above. If you want to see early development work in this area, you need look no further than things like Apple's "Back to my Mac" and Micr0$0ft's "Direct Access".

Yes, closed firewalls are a fine thing in today's environment. Assuming that will always be the case is absurd.

There is a very large difference between allowing for some protocol to open paths through a filtration mechanism and requiring applications to support non-transparent addressing. The former is much simpler than the latter and can be done in a much more secure manner than existing probl^h^h^h^h^h"solutions" like UPNP/PMP.

It actually does matter whether you're punching a hole in just a SPIF (a very simple matter with isolated consequences to a single host) or a SPIF+NAT/NPT (a much more complicated matter that includes mapping, packet mutilation, a series of additional state tables, and may have side effects that hit hosts other than the intended parties).

> So, yes ... I will continue to talk about this problem, until I'm confident that all of the right people understand it.

Hopefully you will eventually understand it.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Mar 2013 13:16:57 -0800

Gert,

I'm in the "make both protocols complete and interoperable such that operators
can choose the features that best meet their needs" camp.

However, the IETF has not done so. RA (until recently) lacked RDNS support
which was a glaring failure to provide everything needed to configure a host.
I'm not sure much more should be added to RA as it's intended to be a very
lightweight protocol.  I think RA has arrived at a reasonably complete state in
its current form. (implementations notwithstanding, as they are not IETF's issue).

OTOH, lack of routing information in DHCPv6 is a glaring omission and the
purists that have, thus far, managed to keep it out of the IETF specs are likely
to force an alternative solution to get adopted as a de facto standard which
will eventually then be documented after the fact by IETF.

My recommendation in discussing this with the DHCP product manager at
ISC has been to provide a vendor option which provides the following properties:

1.	Each response to a DHCP Request can contain zero or more of these option fields.
2.	The option will contain the following information:
		Vendor number
		Vendor's option number
		Prefix
		Next hop gateway address (must be an on-link or link-local address)
		Metric (a 32 bit number used to determine preference of competing routes)

Owen

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 4 Mar 2013 21:37:40 +0000

Owen,

> purists that have, thus far, managed to keep it out of the IETF specs are

Did you look at this one?
https://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-05

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Owen DeLong
> Sent: Monday, March 04, 2013 4:17 PM
> To: Gert Doering
> Cc: IPv6 Ops WG
> I'm in the "make both protocols complete and interoperable such that
> operators can choose the features that best meet their needs" camp.
> 
> lightweight protocol.  I think RA has arrived at a reasonably complete state
> in its current form. (implementations notwithstanding, as they are not IETF's
> issue).
> 
> purists that have, thus far, managed to keep it out of the IETF specs are
> likely to force an alternative solution to get adopted as a de facto standard
> which will eventually then be documented after the fact by IETF.
> 
> >>> So what is it that you're missing?  "Sane implementations" is not
> >>> really something the IETF can provide.
> >>
> > camp wants "everything that's needed to configure a host" in RA, and
> > the other camp thinks DHCP is good enough for everything and thinks
> > having to run RA as well is evil, and should not be done.  Or such.
> >
> > I think people from both camps should be drowned somewhere, for
> > refusing to acknowledge that networks in the real world out of their
> > ivory towers

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Mar 2013 13:58:07 -0800

My concern is that you are requiring the host to ask for routing information before
it is supplied. I think that in many cases, the DHCP administrators would prefer
to "force feed" this information to the clients and expect the clients to abide by it.

Otherwise, it looks like pretty much exactly what I was wanting. I hope it moves
forward.

Owen

---

From: David Farmer <[email-masked]>
Date: Mon, 04 Mar 2013 18:07:18 -0600

> 		that it is easier than ever before to obtain IPv6 addressing in very generous quantities.

I mostly agree with Owen on this, I don't believe the content networks 
were particularly advocates of PI, at least not any more than a number 
of other groups.  That said, I believe content networks generally 
supported PI, but so did many others.  So, primarily crediting content 
networks for PI is an over statement of their role.

A side note; Owen, you got the wrong U of M, again, I work for the 
Maroon and Gold not the Blue and Maze.  We generally work well with the 
Michigan guys, except one Saturday a year when we battle for the little 
brown jug.

Now if we could only create the kind of collaborative and creative 
rivalries that exist between the institutions involved in college 
football, around IPv6 adoption, we'd have no problem.  No Gopher asks 
why we have try to beat the Wolverines each year, even though we've only 
won the little brown jug twice in the last two decades, its just a given.
:)

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Mar 2013 16:16:52 -0800

On 03/04/2013 04:07 PM, David Farmer wrote:
> I don't believe the content networks were particularly advocates of PI,
> at least not any more than a number of other groups.  That said, I
> believe content networks generally supported PI, but so did many
> others.  So, primarily crediting content networks for PI is an over
> statement of their role.

Fair enough. My point remains however. As-designed IPv6 was PA only. It 
took an enormous hue and cry to get that changed. And yes, the policy 
change happened at the RIRs, but not till AFTER the IETF signed off, 
which did not occur till AFTER various large network operators made it 
clear that they would never deploy v6 till PI space was available.

Doug

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Mar 2013 16:30:05 -0800

Owen,

Aside from our fundamental disagreements on whether or not NPTv6 is ever 
acceptable, your last 2 messages highlight another fundamental 
disagreement which I think is equally, if not more damaging to the cause 
of widespread IPv6 deployment.

A lot of your points of argument rely on "I think $this will/may happen 
in the future." While I certainly agree that we need to create our 
designs with doing our best not to limit future opportunities in mind, 
we also need to take present realities into account. Most particularly, 
the present reality is that users don't want to be told, "You're doing 
it wrong, if you want to deploy IPv6 you have to make this list of 
changes to your network model." In fact, they don't like that so much 
that they have tuned out that advice for the last 15 years, and have 
continued to happily use IPv4 behind their NATs.

It's fine to talk about the good old days, and how much better the world 
would be if there was no NAT. But the operational reality is that that 
the majority of the life of the Internet (measured in years, users, 
bits/year, or any other measurement you want to consider) has been in 
the NAT era. Those good old days were a statistical blip, that occurred 
a long time ago. Not only are they not coming back, the users don't want 
them back.

That leaves it up to us to do design work for the modern era, taking 
BOTH present reality and the hope for a brighter future into account. 
Focusing exclusively on one or the other is an error.

Doug

---

From: Owen DeLong <[email-masked]>
Date: Mon, 4 Mar 2013 16:52:56 -0800

On Mar 4, 2013, at 4:16 PM, Doug Barton <[email-masked]> wrote:

> Fair enough. My point remains however. As-designed IPv6 was PA only. It took an enormous hue and cry to get that changed. And yes, the policy change happened at the RIRs, but not till AFTER the IETF signed off, which did not occur till AFTER various large network operators made it clear that they would never deploy v6 till PI space was available.
> 

It must be wonderful to be able to modify history to suit your argument.

The IETF did NOT sign off on PI for IPv6 before the RIR policies were already implemented and dispensing it.

I don't know if the IETF ever officially signed off on it or not, but I do know that at least the first RIR policy was decided and implemented without any regard to IETF action on the subject.

Owen

---

From: David Farmer <[email-masked]>
Date: Mon, 04 Mar 2013 18:54:58 -0600

On 3/4/13 18:16 , Doug Barton wrote:
> change happened at the RIRs,

Agreed.

> but not till AFTER the IETF signed off,

I don't recall any RFC or other consensus from the IETF that called for 
PI, there may have been a consensus that GUA-PI was a better idea than 
ULA-C, that is the closest to a consensus for PI I can think of.  I'd 
love to be wrong on that as I still have people grumble at me about the 
ARIN policy I authored.  Being able to provide a quote that there was a 
IETF consensus for PI would still be helpful to me personally if there 
is one to point to.

> clear that they would never deploy v6 till PI space was available.

Many of the largest network operators supported the PA-only model and 
mostly did not support PI.  Some relented as it became obvious that the 
lack of IPv6 PI was a huge drag on IPv6 adoption, especially as IPv4 
run-out actually started to loom big on the horizon.

---

From: Ray Hunter <[email-masked]>
Date: Tue, 05 Mar 2013 08:56:46 +0100

Owen DeLong wrote:
> <snip> 
BYOD is a game changer. As are highly mobile devices. As is cloud
computing. As is cross-enterprise collaboration. It's not just one thing.

The notion that an enterprise is a monolithic entity; where all the
users, data, and applications are on the "inside", and all the bad stuff
is on the outside, is outdated.

BYOD means a loss of control of devices. How are you going to distribute
a ULA source address selection policy to someone's iDevice if you use
more than one /48 ULA?

Highly mobile devices are challenging the split name space. How are you
going to run IPv6 DNS not spilt, whilst IPv4 DNS remains split?
It's not just dual-stack DNS server reachability, you're probably going
to have to serve different content too, depending on location, and flush
caching as nodes move. It's probably going to be much easier just to run
IPv6-only for highly mobile devices (if we ever get them).

Cross-enterprise collaboration is stretching applications, and cloud
computing is stretching authentication.
SAML can be easily proxied from ULA to GUA, but other authentication
methods and apps can't.

This isn't just theory or foil ware: the switch is happening very
rapidly in my customers AFAICS.

So I think that even if you are thinking of using NPT, you would still
be wise to deploy GUA PI space in a large enterprise (and no ULA at
all), just in case the border ever does need to become more transparent.
PI space is readily available and cheap in enterprise terms. ULA is not
a pre-req for NPT. That's RFC1918 thinking.

IMHO ULA is currently limited by practical considerations to on-site
communication (in the event a non PI GUA disappears, or for stand-alone
networks), and a single /48.

regards,
RayH
<snip>

---

From: Doug Barton <[email-masked]>
Date: Tue, 05 Mar 2013 00:15:10 -0800

On 03/04/2013 04:54 PM, David Farmer wrote:
> ULA-C, that is the closest to a consensus for PI I can think of.

That was part of it. The other part was the conversation (repeated at 
all the different RIR meetings I attended) that went something like this:

people:	We need PI space for IPv6
RIR:	We have no guidance from the IETF on allocations to individuals, 
only to ISPs.
IETF:	Yeah, and that's how it's going to stay.

At the time (2003-2005 time frame) there was still a very vocal 
contingent that was saying that mip6 was going to be the answer to the 
traditional multihoming problem, and didn't want any attention diverted 
from that goal. Also see below on other road blocks.

Eventually the pressure to permit PI space became overwhelming, cooler 
heads prevailed, and the right conversations were had with the right 
people to make it all happen. FWIW I never got the sense that the RIRs 
were against it necessarily, they just didn't want to cheese off the 
militant no-PI folks in the IETF.

> I'd

There was not a specific document that said, "Ok, PI space is fine, go 
for it." In fact given the climate at the time that wasn't even 
possible. "Grudging acknowledgement" was the only possible outcome, and 
yes, people like you took heat for not only acknowledging reality, but 
acting in the best interests of long-term IPv6 deployment. Thank you. :)

> run-out actually started to loom big on the horizon.

Sorry I wasn't clear. When I say network operators I do not mean ISPs. 
Obviously they were all in favor of the "PA-only" model, since it 
amounted to a near lock-in for the customers that purchased IPv6 from 
them. In fact, when talking to the CTOs of a lot of the large 
enterprises, not getting locked in to a given ISP was their chief 
concern. Renumbering was a close second, but they did not want to give 
up the bargaining advantage that IPv4 PI gave them.

A less charitable person than myself would argue that it was the big 
ISPs that were one of the key driving forces of the PA-only model, but I 
digress. :)

Doug

---

From: Doug Barton <[email-masked]>
Date: Tue, 05 Mar 2013 00:19:30 -0800

On 03/04/2013 11:56 PM, Ray Hunter wrote:
> BYOD is a game changer.

Agreed. We're seeing this as a key driving force in the DNS/DHCP/IPAM 
space as well.

[snipping some of your other excellent points]

> a pre-req for NPT. That's RFC1918 thinking.

Just to be clear, I'm not saying that ULA is a pre-req for NPT, and for 
large enterprises GUA + NPT may very well be a valid solution. My point 
is that there is nothing about ULA, NPT, or the combination thereof that 
is inherently evil. :)

Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 05 Mar 2013 08:45:07 +0000

On a point of historical fact:

On 05/03/2013 00:52, Owen DeLong wrote:
...

> I don't know if the IETF ever officially signed off on it or not, but I do know that at least the first RIR policy was decided and implemented without any regard to IETF action on the subject.

The IETF gave control over address assignment policy to IANA on March 1st, 2000 [RFC2860, clause 4.3].

   Brian

---

From: Doug Barton <[email-masked]>
Date: Tue, 05 Mar 2013 01:04:36 -0800

> The IETF gave control over address assignment policy to IANA on March 1st, 2000 [RFC2860, clause 4.3].

Yes, and speaking as the person who was the IANA manager at the time the 
PI debate hit full volume, there was no set of asbestos long-johns thick 
enough for me to have put "Thou shalt have IPv6 PI" in writing. :)

I was happy to have played a small role in brokering conversations that 
ultimately helped the right things to happen, and ultimately very happy 
that the right things _did_ happen, but IANA's official role in that 
space was and is largely secretarial.

Doug

---

From: Ray Hunter <[email-masked]>
Date: Tue, 05 Mar 2013 10:57:57 +0100

Doug Barton wrote:
>>> There's lots of desktop collaboration that occurs outside of the
>>> enterprise world. Further, with the ever increasing level of BYOD,
>>> multiple connectivities, etc. I think that our authentication and
>>> authorization models for network traffic are going to change
>>> significantly in the future, especially when you consider things
>>> that are possible with MIP6. I think you'll see more end-to-end
>>> ESP/AH used rather than straight firewalls and that you will see
>>> direct untranslated traversal through the firewall of packets which
>>> are part of valid existing security associations or which are
>>> intended to set up such security associations.
> >
>> BYOD is a game changer.
>
> Just to be clear, I'm not saying that ULA is a pre-req for NPT, and
> for large enterprises GUA + NPT may very well be a valid solution. My
> point is that there is nothing about ULA, NPT, or the combination
> thereof that is inherently evil. :)
>
> Doug
>
>
I have a slightly different take. There is stuff now traversing the
enterprise border in both directions that we never ever expected to when
the original protocols and code were developed. Have you tried deploying
an enterprise phone system hosted on the public Internet as a cloud service?

The point I make is that we don't have proper solutions today in
IPv4/RFC1918/NAPT/Split DNS for many of the challenges I listed, never
mind IPv6/NPT.

Any engineering effort required for translation traversal in these
services will be completely new, not just a delta.

A deployment that relies 100% on ULA and/or NPT will likely limit your
IT architecture (unnecessarily).

I would therefore highly recommend enterprises keeping their options
open (via GUA PI), so that they can have at least one fully-transparent
highly-available two-way gateway to/from the enterprise. IPv6 could then
become a business enabler, rather than an additional cost with no-benefit.

regards,
RayH

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Mar 2013 02:49:33 -0800

On Mar 5, 2013, at 00:15 , Doug Barton <[email-masked]> wrote:

> That was part of it. The other part was the conversation (repeated at all the different RIR meetings I attended) that went something like this:
> 
> RIR:	We have no guidance from the IETF on allocations to individuals, only to ISPs.

Right... And it did, indeed, stay that way. So, the RIR(s), or, more accurately, some individuals in the RIR communities, took it upon themselves to craft guidance from the RIR policy development processes to cover that lack.

> At the time (2003-2005 time frame) there was still a very vocal contingent that was saying that mip6 was going to be the answer to the traditional multihoming problem, and didn't want any attention diverted from that goal. Also see below on other road blocks.

Actually, IIRC, there was more of a push for SHA^hIM6 at the time. There were also a contingent pushing for a (much earlier and far less fathomable) version of LISP.

According to actual historical records:

https://www.arin.net/policy/proposals/2005_1.html

The first RIR policy allowing for PI IPv6 was adopted by the ARIN board on 27 July, 2006 and implemented on 30 August, 2006.

The final version of this policy was a merger between three competing policies that had been written by myself, Andrew Dul, and Kevin Loch. The three policies were very similar and mine was the first one into the hopper in February, 2005.

> Eventually the pressure to permit PI space became overwhelming, cooler heads prevailed, and the right conversations were had with the right people to make it all happen. FWIW I never got the sense that the RIRs were against it necessarily, they just didn't want to cheese off the militant no-PI folks in the IETF.

I don't remember being exactly what one would refer to as a "cooler head" in 2005, and I think your characterization of what happened is still glaringly inaccurate.

1.	The pressure to permit PI space came from a grass roots movement in the ARIN community, as does the pressure for ANY ARIN policy, ever.
2.	I remember the discussions actually being quite passionate. Most of the "cooler heads" were on the no-PI side from what I remember.
3.	It wasn't a matter of right conversations with right people, it was a matter of a set of policies working their way through the ARIN policy process
	until they converged as a single policy acceptable to all 3 authors and able to achieve broad support of the community.
4.	There is no policy opinion from "the RIRs". They are neutral on policy matters and ARIN staff is expressly prohibited from expressing opinions on
	policy. The RIR had no policy to support PI in IPv6 and no advice from IETF to do so without policy. There was also nothing from IETF to prevent
	the RIRs from developing policy absent guidance in either direction from IETF. There were certainly those in the RIR crowd that were opposed
	to the idea. Frankly, when I proposed the policy, I never expected it to gain consensus. I did it in order to force the mega-corp ISPs to go on the
	record beating up the little guys (which they basically did). However, in the RIR world, a bunch of Davids really do trump a few Golliaths and
	the policy achieved consensus.

It wasn't a back room deal or a series of secret conversations. It was all done through a transparent public process open to anyone who chose to participate.

> There was not a specific document that said, "Ok, PI space is fine, go for it." In fact given the climate at the time that wasn't even possible. "Grudging acknowledgement" was the only possible outcome, and yes, people like you took heat for not only acknowledging reality, but acting in the best interests of long-term IPv6 deployment. Thank you. :)

An interesting characterization of "deafening silence". Yes, lots of individuals that were active participants in various IPv6 working groups were quite vocal on both sides of the subject, but the IETF as a body NEVER really said anything one way or the other.

> Sorry I wasn't clear. When I say network operators I do not mean ISPs. Obviously they were all in favor of the "PA-only" model, since it amounted to a near lock-in for the customers that purchased IPv6 from them. In fact, when talking to the CTOs of a lot of the large enterprises, not getting locked in to a given ISP was their chief concern. Renumbering was a close second, but they did not want to give up the bargaining advantage that IPv4 PI gave them.

Actually, neither of your statements is accurate.

1.	Many ISPs supported the PI proposal. (This surprised me at the time as much as it will apparently surprise you now).
2.	When crafting the original IPv6 PI policy we made a lot of efforts to make sure that it made PI accessible to as many organizations as possible and was not exclusively a tool for very large enterprises.
3.	Most of the overwhelming pressure for PI IPv6 actually came from small and medium sized organizations, not the large enterprises, Not that they were silent or didn't support it, just that they were few in number compared to the others.  In the ARIN policy process, a person from $MEGACORP has the same weight as a person from $CORNER_STORE and 2 people from $MEGACORP have less weight than a person from $CORNER_STORE and a person from $GAS_STATION.

> A less charitable person than myself would argue that it was the big ISPs that were one of the key driving forces of the PA-only model, but I digress. :)

I think that the "phear the size of the bgp table" contingent (sort of the IPv4 equivalent of the congressional deficit hawks) were actually the largest voice driving the PA-only model. Yes, many of them represented large ISPs (especially the ones that are now collectively known as something starting with V), but that wasn't so much to push for customer lock-in (which was more of a beneficial side-effect coveted by sales and marketing), but because the engineers really were in fear of their routers being unable to process and/or store a complete table. I talked to a lot of the engineers at the time. I actually held the same assumption and didn't completely believe them at the time. However, looking back, I realize that engineers really don't care about things like customer lock-in and they really do care about things like failing routers.

So... The axiom "Never attribute to malice what can be adequately explained otherwise." would seem to apply in this case.

Owen

---

From: Gert Doering <[email-masked]>
Date: Tue, 5 Mar 2013 11:53:11 +0100

Hi,

> militant no-PI folks in the IETF.

"The RIRs" had no business to have *any* opinion on this.  They are 
secretaries to provide addresses to their communities if those decide 
that they want them sliced in a certain way.

The RIRs' *communities* - who make the policies - have indeed had long
discussions between the "no PI, only over our dead bodies!" and 
"without PI, no IPv6 will happen, ever!" camps...

Gert Doering
        -- still carrying scars from the IPv6 PI debate in RIPE land
-- 
have you enabled IPv6 on something today...?

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 5 Mar 2013 08:03:33 -0800

Doug,

You seem very interested in this topic. Your interests would be well served
in writing an I-D to document your position and supporting facts. I believe
the list has outlived it's utility for this topic of PI space and and Nat
and npt.

CB
 On Mar 5, 2013 1:04 AM, "Doug Barton" <[email-masked]> wrote:

>>> I don't know if the IETF ever officially signed off on it or not, but I
>>> do know that at least the first RIR policy was decided and implemented
>>> without any regard to IETF action on the subject.
>>>
>>
> that the right things _did_ happen, but IANA's official role in that space
> was and is largely secretarial.
>
> Doug
>
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Doug Barton <[email-masked]>
Date: Tue, 05 Mar 2013 08:31:43 -0800

> Right... And it did, indeed, stay that way. So, the RIR(s), or, more accurately, some individuals in the RIR communities, took it upon themselves to craft guidance from the RIR policy development p…

On this topic I think we've reached the "blind men describing an 
elephant" phase, so I'll let what I have said already stand on its own 
merit.

Doug

---

From: joel jaeggli <[email-masked]>
Date: Tue, 05 Mar 2013 09:10:23 -0800

> I don't know if the IETF ever officially signed off on it or not, but I do know that at least the first RIR policy was decided and implemented without any regard to IETF action on the subject.
As a historical point, some of the very first /32 prefix assignments 
were to organizations I would characterize as "non-ISP" . From the 
outset the stated model (if one were assuming pi-only meant ISP) didn't 
match deployment. There are some other questions one can ask about the 
policy in place at that time. e.g. what's an LIR, and whats a plan for 
making 200 /48 assignments within two years since lots of organizations 
make subassignments, and anyone can have a plan.

What we got out of the experience is unsurprisingly the world we already 
lived in. That network operators (not ISPs) go out and secure the 
resources the need to run the networks that they have. Policy in the 
RIRs is accountable to the stakeholders and so forth.