Subject: [v6ops] ULA discussion #1 ULA+NAT

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 4 Mar 2013 12:20:52 +0000

Hi, Dear all

(Note:
Thanks for your comments, those would help the authors a lot. I split and summarize some topics from the discussion, for ease of further discussion, hope we can make some consensus. Any specific discussion please going to the relevant thread, many thanks.)

For ULA+NPTv6, as I understand according to the discussion, we considering it because we want to get independence address space, then coming the compare of NPTv6 vs PI. (Please correct me if I mistakenly understood it)

we mainly have two views:
A: ULA+NPTv6 should be "Not recommended" in this document. Since we need to promote E2E transparence in IPv6. NPTv6 broke the transparence and made more overall cost by adjust the network/applications to fit the NAT environment. Contrastively, acquiring a PI would not cost too much, and easy to deploy with BGP.
B: "Not recommended" is way too much, we need fairly stating the pros and cons in the document. Since NPTv6 is a reasonable requirement of the real end-users. Configuring BGP for PI would not feet all the users, especially the small enterprises and home users. And needs no cost on RIR fees. Moreover, no limited PI might potentially cause serious BGP4 scaling issue, considering the multihoming requirement in IPv6 might explode.

Please supplement if I missed some points, and hope more people could comment on this topic. 

Thanks a lot.

Cheers,
Bing

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 04 Mar 2013 08:04:01 -0500

Bing/group,

Not that I am advocating for this option (which I am not), but is there
not technically a third option which is present ULA+NPTv6 without
providing a recommendation?  I only note this for completeness of options.
 It's possible to not provide a specific recommendation.

I am tempted, as are many, to supply a recommendation of "not
recommended".  But one concern I do have in the back of my mind is that if
we do recommend something specific here, then the issue of consistency
will come into play.  I don't think this is the only draft which notes the
use of NPTv6 and/or it's use along side ULA (not sure if this combo was
specifically noted, but I know NPT shows up).  So this recommendation, if
made, would need to be sync'ed with those drafts (or not?  I am not the
expert here).

One may also argue that much of the contention is around NPTv6 and not
specifically ULA (I think there are different arguments for and against
both).  So the issue is, does a draft discussing ULA use cases, one of
which includes NPTv6, need to be the one recommending it's use or not?
Also, NPTv6 can be used without ULAs.

Also, when I re-looked at RFC6296 (NPTv6) it already has discussion on use
with ULAs along with some discussion.  The RFC then has further references
over to RFC5902 (IAB thoughts on IPv6 Network Address Translation) which
then in turn has references to RFC4924 (Reflections of Internet
Transparency).  Perhaps those references, and extended references is
sufficient in this case?

Since RFC6296 is experimental, there is also an option to point to RFC5902
directly as it supplies discussion around the matter of translation for
IPv6 from an architectural view.

Sorry for looking like I am play both sides, but wanted to make sure we
had all our cards on the table.

Regards,

Victor Kuarsingh

On 2013-03-04 7:20 AM, "Liubing (Leo)" <[email-masked]> wrote:

>Hi, Dear all
>
>(Note:
>Thanks for your comments, those would help the authors a lot. I split and
>summarize some topics from the discussion, for ease of further
>discussion, hope we can make some consensus. Any specific discussion
>please going to the relevant thread, many thanks.)
>
>For ULA+NPTv6, as I understand according to the discussion, we
>considering it because we want to get independence address space, then
>coming the compare of NPTv6 vs PI. (Please correct me if I mistakenly
>understood it)
>
>A: ULA+NPTv6 should be "Not recommended" in this document. Since we need
>to promote E2E transparence in IPv6. NPTv6 broke the transparence and
>made more overall cost by adjust the network/applications to fit the NAT
>environment. Contrastively, acquiring a PI would not cost too much, and
>easy to deploy with BGP.
>B: "Not recommended" is way too much, we need fairly stating the pros and
>cons in the document. Since NPTv6 is a reasonable requirement of the real
>end-users. Configuring BGP for PI would not feet all the users,
>especially the small enterprises and home users. And needs no cost on RIR
>fees. Moreover, no limited PI might potentially cause serious BGP4
>scaling issue, considering the multihoming requirement in IPv6 might
>explode.
>
>_______________________________________________
>v6ops mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 4 Mar 2013 13:12:41 +0000

Hi, Victor

> Also, NPTv6 can be used without ULAs.

[Bing] This is also a confusing question for me. 

> Transparency).  Perhaps those references, and extended references is

[Bing] I think it's a good point. Thanks for the information.

---

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

Hi,

> B: "Not recommended" is way too much, we need fairly stating the pros and cons in the document. Since NPTv6 is a reasonable requirement of the real end-users. Configuring BGP for PI would not feet…

This.

(Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space from the
provider, potentially having multiple prefixes from multiple providers
active at the same time.  Which currently has more drawbacks than benefits,
but has the potential to be more lightweight and at the same time more
powerful than both BGP+PI and ULA+NPTv6 for "end user networks")

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: Owen DeLong <[email-masked]>
Date: Mon, 4 Mar 2013 12:25:39 -0800

I'm fine if we don't mention NPT in the draft.

If we are going to mention NPT, then I will strenuously object unless the draft also contains language specifying that any form of address translation is not recommended.

Owen

---

From: james woodyatt <[email-masked]>
Date: Mon, 04 Mar 2013 14:12:50 -0800

On Mar 4, 2013, at 06:33 , Gert Doering <[email-masked]> wrote:
> 
> (Actually there's 3 options - BGP+PI, ULA+NPTv6, and PA space 

Actually, there's a fourth: ULA+NAT66 (not NPTv6).

As I have said elsewhere and I will repeat here, this option is the only one that guarantees that SOHO and HOMENET sites will always have a /48 with 16 bits of subnet identifier space from which to choose random numbers that are statistically unlikely to collide in reasonably sized sites in the foreseeable future.

Yes, it comes at a terrible price, but my view is that it's not that much worse than the price of NPTv6 and the guaranteed /48 prefix is more than worth the additional cost in transparency.

--
james woodyatt <[email-masked]>
core os networking

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 4 Mar 2013 23:20:29 +0000

> As I have said elsewhere and I will repeat here, this option is the only one
> that guarantees that SOHO and HOMENET sites will always have a /48 with 16
> bits of subnet identifier space from which to choose random numbers that
> are statistically unlikely to collide in reasonably sized sites in the foreseeable
> future.
> 
> Yes, it comes at a terrible price, but my view is that it's not that much worse
> than the price of NPTv6 and the guaranteed /48 prefix is more than worth
> the additional cost in transparency.

I have to admit to having been curious about the lack of mention of this 4th option in this ULA discussion. I'd be very interested in better understanding the "terrible price" of ULA+NAT66 vs. the "cost" of ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the information would be useful. If the price of getting the information is that it has to have some sort of recommendation tacked on to it, that doesn't bother me at all.
Barbara

---

From: joel jaeggli <[email-masked]>
Date: Mon, 04 Mar 2013 15:28:50 -0800

> I have to admit to having been curious about the lack of mention of this 4th option in this ULA discussion. I'd be very interested in better understanding the "terrible price" of ULA+NAT66 vs. the…
It's not like we're aren't taking a stab at it. 6renum homenet and v6ops 
ops all dance around what is essentially single homing to multiple 
providers in some drafts.

individual devices (e.g. cellphones, laptops with broadbad radios(or 
wifi+ethernet or split vpn), some cars and so forth) do this today do 
this by virtue of having more than  active network interface on 
disparate providers.

---

From: David Farmer <[email-masked]>
Date: Mon, 04 Mar 2013 20:23:17 -0600

> If we are going to mention NPT, then I will strenuously object unless the draft also contains language specifying that any form of address translation is not recommended.

Ok, here is a couple quotes from RFC 6296, section 1, Introduction;

    For reasons discussed in [RFC2993] and Section 5, the IETF does not
    recommend the use of Network Address Translation technology for IPv6.
    Where translation is implemented, however, this specification
    provides a mechanism that has fewer architectural problems than
    merely implementing a traditional stateful Network Address Translator
    in an IPv6 environment.

Later in RFC 6296, section 4.1, Prefix Configuration and Generation;

    NPTv6 Translators MUST support manual configuration of internal and
    external prefixes and MUST NOT place any restrictions on those
    prefixes except that they be valid IPv6 unicast prefixes as described
    in [RFC4291].  They MAY also support random generation of ULA
    addresses on command.  Since the most common place anticipated for
    the implementation of an NPTv6 Translator is a Customer Premises
    Equipment (CPE) router, the reader is urged to consider the
    requirements of [RFC6204].

So, I interpret that as saying the IETF consensus is that the use of 
address translation is NOT RECOMMENDED for IPv6, but that NTPv6 is a 
valid use case for ULA.  Unless we wish to revisit the IETF consensus 
that address translation is NOT RECOMMENDED for IPv6, and I don't 
believe this draft is the proper way to revisit that consensus.

Therefore, if NPTv6 are mentioned as recommended use cases for ULA in 
the draft then something to the effect of the following should be 
included as well;

    While NPTv6 is a recommended use cases for ULA, for reasons
    discussed in [RFC2993] and Section 5, the IETF does not recommend
    the use of Network Address Translation technology for IPv6.

I'll note, the current version of draft mentions NTPv6 only in the 
context of section 2, ULA Usage Analysis, and not in section 3, 
Recommended ULA Use Cases.  Therefore, as the current draft stands we 
don't need to include anything about the recommendation against NAT for 
IPv6, as it is not currently making any recommendation regarding NPTv6, 
it is only discussing it in the context of analysis.  I only think this 
is needed if NTPv6 is added to section 3.

I'm not opposed to including NTPv6 in section 3 if something like the 
above is included.

Please note: I actually support broader use of NAT in IPv6, but if NPTv6 
is a recommended use case of ULA in this draft and the recommendation 
against the use of NAT is not also included, it will only bog down the 
publication of what I think is a useful and important draft.  This draft 
is not the right way to readdress the consensus against the use of NAT 
with IPv6.

-- 
================================================
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: Victor Kuarsingh <[email-masked]>
Date: Mon, 04 Mar 2013 22:11:52 -0500

On 2013-03-04 6:20 PM, "STARK, BARBARA H" <[email-masked]> wrote:

>I have to admit to having been curious about the lack of mention of this
>4th option in this ULA discussion. I'd be very interested in better
>understanding the "terrible price" of ULA+NAT66 vs. the "cost" of
>ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the
>information would be useful. If the price of getting the information is
>that it has to have some sort of recommendation tacked on to it, that
>doesn't bother me at all.
>Barbara

Barbara,

I have been thinking about this quite a bit recently given all the
comments on the various threads related to what started as a ULA use case
document.

>From my vantage point, I get the sense that many have different
assessments of what the costs are (in value) based on various viewpoints.
I.e. Cost to network operator (routing/scale/complexity/tooling/etc), cost
to customer, cost to software developers who need to code around NATs,
cost to device vendors etc.

What may be possible in the more immediate timeframe would be a document
that expresses the cost areas of the major options ( PA+DHCP/Routing,
PI+BGP/Other, ULA+NPTv6, ULA+NAT66 etc).  Not sure if this is valuable to
anyone.  If it is, it may be worth a try to draft something (may be met
with stiff opposition).

Another side observation I have is that there also seems to be some
positions which are related to a "one-size-fits-all" addressing approach.
This may not be a reasonable position.  As an example, the original
addressing (PA) model was complemented by PI - which seems to imply that
more then one model was needed (at least).  This is in effect a divergence
from the original single model. I think, as much as it pains me to admit
it, that there may be more models required to address the overall
requirement set for all networks. I am also not sure if an open
conversation related to what are in fact the requirements for customers
and businesses is needed.  Of course this is a slipper slope since it may
quickly diverge away from a technical conversation into one fuelled by
opinion.

(waiting for attack :)

Regards,

Victor K

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 4 Mar 2013 20:23:43 -0800

> quickly diverge away from a technical conversation into one fuelled by

wait no longer.

NAT / NPT6 breaks stuff and should not be used in any going-forward design.

For example, say i have a simple SIP or WebRTC connection.  It will
use SDP (or similar)  to communicate to the remote peer the address
and ports to send me media... if the application is unaware of it's
address, it wont work (sans band-aids like ICE, STUN, TURN ...) I
think my address is FD09::1, so send it here from across the
internet... hmm.. does not work...   Granted, the world has STUN and
TURN and ICE, but somebody asked about cost.  There you have it, go
price out some of that.

Take it from a major CGN operator, don't do NAT.

What problem are we trying to solve here?  If SOHO customers want to
run BGP, tell them to call he.net, nobody else is interested in
providing a free service like this... and at the prices they charge, i
am sure they can maintain a lock on the market and nobody will mind.
If customers want NPTv6 or NAT66, there are boxes that do that, they
can go crazy and tech-support themselves since they are so smart and
justified in choosing this solution, or they can call tech-support of
the CPE vendor who sold them that.

Thanks!

CB

ps.  Oh, yeah... add to the list of things that break to include RTSP,
PPTP, IPsec AH, SIP, H323 (grasping at straws...), FTP, ... not a real
who's who... but WebRTC might be a real zinger soon.

---

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

On 03/04/2013 06:23 PM, David Farmer wrote:
>> If we are going to mention NPT, then I will strenuously object unless
>> the draft also contains language specifying that any form of address
>> translation is not recommended.
>

The quote from Section 1 talks about NAT not being recommended, and then 
details the differences between traditional NAT and NPTv6. It also 
references other documents that discuss the tradeoffs, and Section 5 
mentions some of them as well. For anyone involved in this discussion 
who hasn't actually read 6296, I highly recommend it. Personally I think 
it's very fair in discussing when NPT is useful, and when it isn't.

So again, I'm not saying that a new document should say, "Hey, everyone, 
go do ULA + NPTv6, it's awesome!" Let's just be fair about it.

Doug

---

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

> NAT / NPT6 breaks stuff and should not be used in any going-forward

Totally naive and unrealistic.

> TURN and ICE, but somebody asked about cost.  There you have it, go

So given that we already have those solutions, what are the marginal 
costs or applying them to IPv6?

Your arguments seem predicated on the need to recreate these solutions 
from scratch. But obviously we don't need to do that. My argument is 
that the marginal costs are very small, so small that they are 
effectively statistical noise. I haven't seen any arguments to refute 
that, only the same "NAT means we have to solve these problems!" 
argument which doesn't take reality into account.

So please, refute my argument. Show me where I'm wrong.

> Take it from a major CGN operator, don't do NAT.

"Don't do that" is not a realistic argument in today's world. It's been 
ignored for 15 years already, and will continue to be ignored.

> ps.  Oh, yeah... add to the list of things that break to include
> RTSP, PPTP, IPsec AH, SIP, H323 (grasping at straws...), FTP, ... not
> a real who's who... but WebRTC might be a real zinger soon.

The default for FTP has been passive mode for over a decade, and very 
few users even know that there used to be a different way of doing it. 
As discussed above, those other protocols all have NAT-traversal 
solutions, so as you asked in the bit that I snipped, "What problem are 
we trying to solve here?"

Doug

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Mar 2013 16:38:07 +0900

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

> So given that we already have those solutions, what are the marginal costs
> or applying them to IPv6?
>

For starters, that would involve substantial implementation effort. NAT
traversal mechanisms are among the hardest pieces of code to port to IPv6,
because their code is so IPv4-specific.

Trust me, I've seen it happen. For example, adding IPv6 support to
libjingle was a fair amount of work. Even then, we didn't support NAT or
NPT for IPv6, we only supported rendezvous. So we did a lot of work and it
will still not perform well if someone puts it behind a NAT / NPT.

Your arguments seem predicated on the need to recreate these solutions from
> scratch. But obviously we don't need to do that. My argument is that the
> marginal costs are very small, so small that they are effectively
> statistical noise. I haven't seen any arguments to refute that, only the
> same "NAT means we have to solve these problems!" argument which doesn't
> take reality into account.
>

I listed a few reasons at:

http://lists.cluenet.de/pipermail/ipv6-ops/2013-February/008411.html

I don't think you ever replied to that.

---

From: Doug Barton <[email-masked]>
Date: Mon, 04 Mar 2013 23:55:37 -0800

On 03/04/2013 11:38 PM, Lorenzo Colitti wrote:
> On Tue, Mar 5, 2013 at 4:14 PM, Doug Barton <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> traversal mechanisms are among the hardest pieces of code to port to
> IPv6, because their code is so IPv4-specific.
>
> NPT for IPv6, we only supported rendezvous. So we did a lot of work and
> it will still not perform well if someone puts it behind a NAT / NPT.
>
>     Your arguments seem predicated on the need to recreate these
>     solutions from scratch. But obviously we don't need to do that. My
>     argument is that the marginal costs are very small, so small that
>     they are effectively statistical noise. I haven't seen any arguments
>     to refute that, only the same "NAT means we have to solve these
>     problems!" argument which doesn't take reality into account.
>

No, I didn't, because your conclusion wasn't rational, and didn't take 
into account anything I had already said as part of that lengthy thread.

You're arguing about costs to developers who are going to build or 
update solutions that already exist for IPv4 so that they can be used 
for IPv6. The point I've made ad nauseum is that THOSE COSTS ARE GOING 
TO BE PAID NO MATTER WHAT. There is no world where there will not be 
NAT/NPT/etc. Your syllogism about "insufficient incentive" for app 
developers to support NPTv6 is completely unrealistic (not to mention 
your Skype example was a complete non sequitur).

People will use ULA + NPTv6 (they already are), and other IPv6 options 
that have similar requirements. Therefore all rational app developers 
who want their app to work robustly with IPv6 and need to permit 
connections back in from the outside will use a traversal solution. Just 
like in IPv4, initial implementations of those solutions will be 
written, they will be debugged, and _just like in IPv4_ they will 
eventually become standardized and robust.

Does life suck for people (like you) who have to do that early work? 
Sure it does. Is it a "cost" that has to be paid by someone other than 
the people deploying NPT? Absolutely. But those aren't the relevant 
questions to the manager trying to decide how best to deploy IPv6 on 
their inside network. In fact, to the extent that this theoretical 
manager even understands the questions, she doesn't care about the 
answers. She just wants a solution that works, and in the majority of 
cases ULA + NPTv6 is going to work just fine, and has way more benefits 
than costs _to the organization deploying it_.

Your complaining that these costs of NPT are being borne by those other 
than the ones deploying it amount to saying, "That's not fair!" I'm not 
arguing whether you're right or not. I'm arguing that right or wrong, 
it's not relevant.

Doug

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Mar 2013 17:20:57 +0900

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

> You're arguing about costs to developers who are going to build or update
> solutions that already exist for IPv4 so that they can be used for IPv6.
> The point I've made ad nauseum is that THOSE COSTS ARE GOING TO BE PAID NO
> MATTER WHAT.
>

Wait - you asked about the costs. (Specifically, you wrote "given that we
already have those solutions, what are the marginal costs or applying them
to IPv6?"). I replied pointing out some of the costs that have to be borne.
And those are real costs, because software engineering is expensive.

Then you say those costs are going to be paid no matter what. But they
won't. It depends on what gets deployed. For example, in a case where all
the IPv6 users in the world except one are using global addresses, then no
developer will develop NAT66/NPT66 traversal techniques, because there is
no market for them. If that happens, then the organizations that deploy
NPT66 will bear support costs of because their apps won't work.

I think it's safe to say that since no commercial IPv6 deployments today
use NPT66, the vast majority (>99%?) of IPv6 users today does not obtain
their Internet connection through an NPT66 box. That doesn't seem like an
attractive use case to justify developers investing time into NAT66/NTP66
traversal techniques.

Also, it does seem that "the costs are going to get paid no matter what, so
there are no costs, therefore we should deploy networks that require
translation" is a bit of a circular argument.

---

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

Lorenzo,

Either you don't understand what I've written several times now, or you 
are intentionally twisting my words to make my argument seem 
unreasonable. Regardless of which one of those is true, I have run out 
of new and different ways to repeat the same points, and I'm sure the 
other members of the list are tired of me trying. :)

Doug

On 03/05/2013 12:20 AM, Lorenzo Colitti wrote:
> On Tue, Mar 5, 2013 at 4:55 PM, Doug Barton <[email-masked]
>     update solutions that already exist for IPv4 so that they can be
>     used for IPv6. The point I've made ad nauseum is that THOSE COSTS
>     ARE GOING TO BE PAID NO MATTER WHAT.
>
>
> Wait - you asked about the costs. (Specifically, you wrote "given that
> we already have those solutions, what are the marginal costs or applying
> them to IPv6?"). I replied pointing out some of the costs that have to
> be borne. And those are real costs, because software engineering is
> expensive.
>
> won't. It depends on what gets deployed. For example, in a case where
> all the IPv6 users in the world except one are using global addresses,
> then no developer will develop NAT66/NPT66 traversal techniques, because
> there is no market for them. If that happens, then the organizations
> that deploy NPT66 will bear support costs of because their apps won't work.
>
> their Internet connection through an NPT66 box. That doesn't seem like
> an attractive use case to justify developers investing time into
> NAT66/NTP66 traversal techniques.
>
> Also, it does seem that "the costs are going to get paid no matter what,
> so there are no costs, therefore we should deploy networks that require

---

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

On 04/03/2013 23:20, STARK, BARBARA H wrote:
> I have to admit to having been curious about the lack of mention of this 4th option in this ULA discussion. 

Really? We had this conversation when NPTv6 was a draft, and RFC 6296
explains the advantages over NAT66.

     Brian

> I'd be very interested in better understanding the "terrible price" of ULA+NAT66 vs. the "cost" of ULA+NPTv6 vs. "RIR+ISP+other costs" of BGP+PI or PA space. I think the information would be useful. If the price of getting the information is that it has to have some sort of recommendation tacked on to it, that doesn't bother me at all.
> Barbara

---

From: Philipp Kern <[email-masked]>
Date: Tue, 5 Mar 2013 09:36:29 +0100

On Tue, Mar 05, 2013 at 12:25:06AM -0800, Doug Barton wrote:
> Either you don't understand what I've written several times now, or
> you are intentionally twisting my words to make my argument seem
> unreasonable. Regardless of which one of those is true, I have run
> out of new and different ways to repeat the same points, and I'm
> sure the other members of the list are tired of me trying. :)

It seems to me that Lorenzo's point is that the vast majority of *current*
deployments are not using ULA + NPTv6. You say it's already used, but a
lot of features are used somewhere, even if not widely. Hence Lorenzo
claims that the development cost is not paid for supporting that fringe
use case, because the installed base is too tiny. After all in commercial
deployments you care not about supporting each and every use case but
the ones that are relevant and make money.

You claim that the cost will be paid regardless, he claims that it won't
be.

The technical manager of the company who opts for ULA + NPTv6 needs to
be aware if there are others doing it to be supported by applications
and content providers (whatever content that is, might even be p2p).
Or if the mass is not relevant, possibly opt for something else.

Sort of like the same situation we had with IPv6. There had to be
relevance, with a similar chicken and egg problem, too.

Kind regards
Philipp Kern

---

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

On 03/05/2013 12:36 AM, Philipp Kern wrote:
> deployments are not using ULA + NPTv6.

The vast majority of current deployments aren't using IPv6, period. Of 
the tiny percentage that are, some percentage of them are using a 
NAT-a-like strategy. Many won't deploy IPv6 at all unless they have 
similar capabilities to what they are already using in IPv4 NAT.

Of the possible NAT-a-likes for IPv6, 6296 is by far the least painful.

> You say it's already used, but a

NAT-a-likes will be deployed for IPv6, of that there is no question. So 
yes, I'm saying that this development cost will have to be paid, no 
matter how much some people don't like it.

> You claim that the cost will be paid regardless, he claims that it won't

Lorenzo's argument is that if we complain about NAT'ish options for IPv6 
loud and long, not enough end-user networks will deploy them to make the 
development costs of traversal solutions worthwhile for applications in 
the special case of "needs to allow connections in from the outside 
world." My argument is that not only is that view hopelessly naive, it 
ignores the reality that most of those costs have already been paid, so 
the marginal cost of adding IPv6 support is minimal.

> relevance, with a similar chicken and egg problem, too.

True enough, but oddly Lorenzo's counter-argument (without a hint of 
irony) was, "I already implemented an IPv6 traversal solution for my 
product, so I know how hard it is." He seems to ignore the fact that his 
counter-argument actually proves my point. :)

Doug

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Mar 2013 01:32:54 -0800

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

> So given that we already have those solutions, what are the marginal costs or applying them to IPv6?
> 
> Your arguments seem predicated on the need to recreate these solutions from scratch. But obviously we don't need to do that. My argument is that the marginal costs are very small, so small that they are effectively statistical noise. I haven't seen any arguments to refute that, only the same "NAT means we have to solve these problems!" argument which doesn't take reality into account.

You keep ignoring this, but as I have stated, each of those has an ONGOING cost in development even in IPv4. Each time you release a new version you need to test for regressions and other things related to the NAT traversal stuff. NAT traversal interacts with lots of things in very "interesting" and only semi-predictable ways. Have you ever actually developed an application that depended on NAT traversal technologies to function? Have you ever tried to test it against all the different NAT traversal implementations that are in the wild in order to have it work from behind the plethora of home gateways that are out there? Have you noticed that every time {Linksys,Belkin,Netgear,D-Link,etc.} launches a new series of home gateways you get to test (and debug) all over again?

> So please, refute my argument. Show me where I'm wrong.

You're wrong in the following ways:

1.	You assume this is a do it once fire and forget problem. It is not.
2.	You grossly underestimate just how much it costs EACH TIME.
3.	You further underestimate just how much stuff is actually broken by NAT in environments where that breakage is not intended.
4.	You assume that because the enterprises with which you are familiar want to use NAT in a particular way, everyone should
	want to have those exact same capabilities and that there is no need to support a world without NAT.

> "Don't do that" is not a realistic argument in today's world. It's been ignored for 15 years already, and will continue to be ignored.

Only in IPv4.  Guess what... Many things are different in IPv6. That's a big part of what makes it better than IPv4.

> The default for FTP has been passive mode for over a decade, and very few users even know that there used to be a different way of doing it. As discussed above, those other protocols all have NAT-traversal solutions, so as you asked in the bit that I snipped, "What problem are we trying to solve here?"

Actually, in most cases, those things do not have NAT-traversal solutions. Instead, the NAT boxes have implemented ALGs or something that functions much like an ALG to allow them to function in spite of the fact that NAT-traversal doesn't work for them. This further complicates the code in each of the NAT boxes and creates more opportunities for bad interactions in software in the various home gateways and more opportunities for serious security vulnerabilities to go undetected in the additional complexity of the code involved.

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 5 Mar 2013 18:57:11 +0900

On Tue, Mar 5, 2013 at 5:56 PM, Doug Barton <[email-masked]> wrote:

> The vast majority of current deployments aren't using IPv6, period. Of the
> tiny percentage that are, some percentage of them are using a NAT-a-like
> strategy.
>

Saying "some percentage" provides no information that can be used to make a
decision. After all, some percentage of people survive jumping out of
airplanes without parachutes, and some percentage of those survive without
injuries.

Where are these NAT-a-like deployments, and how many users do they have?
How do those numbers compare with the number of users that have global IPv6
addresses (which is order of 10M)?

> Many won't deploy IPv6 at all unless they have similar capabilities to
> what they are already using in IPv4 NAT.
>

Is this statement based on actual experience? And what is the number
compared to those who have deployed IPv6 with global addresses? I know
several enterprise deployments that use global IPv6 addresses but NAT for
IPv4, so it's not like they don't exist.

> NAT-a-likes will be deployed for IPv6, of that there is no question.
>

But why is there no question? It's obvious that you are convinced of this
outcome, but you will likely be more convincing to others if you make a
more detailed argument.

True enough, but oddly Lorenzo's counter-argument (without a hint of irony)
> was, "I already implemented an IPv6 traversal solution for my product, so I
> know how hard it is." He seems to ignore the fact that his counter-argument
> actually proves my point. :)
>

We did not implement traversal. We spent a long time bringing IPv6 support
to a library that was made very complicated by the need to implement robust
NAT traversal. As I said before, the library still does not do traversal
for IPv6. Implementing that would have made it an even larger effort, and
we had no evidence that any substantial percentage of the userbase has
NATed IPv6 connectivity.

---

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

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

> The vast majority of current deployments aren't using IPv6, period. Of the tiny percentage that are, some percentage of them are using a NAT-a-like strategy. Many won't deploy IPv6 at all unless they have similar capabilities to what they are already using in IPv4 NAT.
> 

Sigh... The vast majority of current IPv6 deployments aren't using NPT, NAT66, or any other form of IPv6 address translation.

So, of the (~10%) of implementations that have some form of IPv6 deployment, maybe 0.00001% of them are using some NAT-a-like strategy.

If I'm the software product manager looking at that market, guess which feature hits the very bottom of the "we'll probably never get to that" list of feature requests?

> Of the possible NAT-a-likes for IPv6, 6296 is by far the least painful.

Yes... I think everyone agrees that in a world of blind people, the one-eyed man is king.

However, most of us respond to the question "Shall I poke one of your eyes out or both?" with a resounding "NONE... What the heck??!"

> NAT-a-likes will be deployed for IPv6, of that there is no question. So yes, I'm saying that this development cost will have to be paid, no matter how much some people don't like it.

Yes. But will they get deployed widely enough for anyone other than yourself and the managers foolish enough to make that choice without considering the possible consequences to care?

If not, then guess what... The development costs don't get paid and the people who depended on NPTv6 in their networks are kind of SOL. (Unless, of course, they find some way to fund all that development effort among themselves.)

With any luck, NPTv6 will be the internet equivalent of the "Bone Fone". Something everyone has heard of, but few have actually even experienced and they aren't actually made or supported any more. I know you insist this won't be the case, but there are lots of us that still hold out hope for a brighter future than you envision.

> Lorenzo's argument is that if we complain about NAT'ish options for IPv6 loud and long, not enough end-user networks will deploy them to make the development costs of traversal solutions worthwhile for applications in the special case of "needs to allow connections in from the outside world." My argument is that not only is that view hopelessly naive, it ignores the reality that most of those costs have already been paid, so the marginal cost of adding IPv6 support is minimal.

No, Lorenzo's (and my) argument is that NAT technologies in IPv6 aren't getting wide deployment today (even as a percentage of IPv6 deployments) and that there's no reason to expect that trend will change. Further, if that trend doesn't change, then it's unlikely that there will be enough of an installed base to drive development. You keep referring to "applications that need to allow connections in from the outside world" as a "special case". However, I would argue that Apache, Sendmail, BIND, and a host of other applications that are in widespread use today are really not special cases. I would argue that the current provider/subscriber model of the internet is, in fact, an artifact or peculiarity that is largely due to the widespread deployment of NAT and that a return to a more peer-to-peer style of machine-to-machine communication is, in fact, very likely in the future.

Networks are for connecting people at the end of the day. All of this machine to machine communication is at its roots in the service of serving human communication. Humans don't operate with firewalls and outbound-only communications filters and we don't filter all of our communications with each other through a third-party rendezvous human. I don't know why you cling so dearly to that model or why you can't accept that it will eventually become an anachronism, an artifact of a temporary period in history fostered by a need for address conservation.

> True enough, but oddly Lorenzo's counter-argument (without a hint of irony) was, "I already implemented an IPv6 traversal solution for my product, so I know how hard it is." He seems to ignore the fact that his counter-argument actually proves my point. :)

You really should try reading what he wrote before you put words in his mouth. He said that "porting the library to IPv6 at all was hard enough, without including NAT traversal for IPv6." He specifically stated that they DID NOT do the work to include traversal in the library, so I think his counter-argument works quite well.

The fact that you assume they must have done so in spite of his blatant statement to the contrary, OTOH, proves our point.

Owen

---

From: Doug Barton <[email-masked]>
Date: Tue, 05 Mar 2013 20:35:12 -0800

On 03/05/2013 01:57 AM, Lorenzo Colitti wrote:
> On Tue, Mar 5, 2013 at 5:56 PM, Doug Barton <[email-masked]
>     The vast majority of current deployments aren't using IPv6, period.
>     Of the tiny percentage that are, some percentage of them are using a
>     NAT-a-like strategy.
>
>
> Saying "some percentage" provides no information that can be used to
> make a decision.

You show me your statistics first. :)

Seriously though, resorting to the "You don't have numbers" tactic is 
expected, if not disappointing. More importantly, see below.

>     Many won't deploy IPv6 at all unless they have similar capabilities
>     to what they are already using in IPv4 NAT.
>
>
> Is this statement based on actual experience?

Yes, both my own in dealing with enterprise DNS/DHCP customers, and in 
the many years of people coming to the IETF and saying exactly this. 
There have been many people saying the same thing for well over a 
decade. The problem is that this message hasn't been heard by the IPv6 
protocol folks, so the network operators for the most part don't bother 
anymore. It comes up on the various lists I'm on periodically, and the 
same few people are still giving out the same unrealistic advice.

The people who actually run end-user networks want feature parity with 
IPv4. That doesn't mean that everything needs to be done exactly the 
same way ... NPTv6 vs traditional NAT in v4 is an obvious example of 
something that can and should be done better in v6. But continuing to 
shout at people, "You're doing it wrong!" "You shouldn't want that!" is 
not a message that is going to be heard, or accepted.

> But why is there no question? It's obvious that you are convinced of
> this outcome, but you will likely be more convincing to others if you
> make a more detailed argument.

Neither I, nor the many many network operators who have brought the same 
message to the IETF so many times over the last decade can provide any 
more details than have already been provided ... it's up to y'all to 
hear and accept it, or not.

The problem is that if you(pl.) don't get it, you'll continue making the 
same bad decisions, giving out the same bad advice, and most 
importantly, continue doing damage to IPv6 deployment.

> We did not implement traversal.

Sorry I misunderstood ... so many posts, so little time. :)

Doug

---

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

On 03/05/2013 02:24 AM, Owen DeLong wrote:
> No, Lorenzo's (and my) argument is that NAT technologies in IPv6 aren't getting wide deployment today (even as a percentage of IPv6 deployments) and that there's no reason to expect that trend will change. Further, if that trend doesn't change, then it's unlikely that there will be enough of an installed base to drive development.

Owen,

A light-bulb went on for me when I read this, which I think illustrates 
our difference of opinion. (The way I understand it) you and Lorenzo are 
looking at the small installed base of v6 now, seeing that there are 
very few NAT-a-like technologies already deployed in that group, and 
coming to the conclusion that people who deploy IPv6 are not interested 
in deploying NAT. You therefore conclude that there is hope for a future 
without NAT if you just keep shouting loud enough about how bad it is.

That line of thought has several flaws. The most obvious is that at this 
point (leaving aside content networks) the people on the end-user 
networks that have IPv6 are almost all early adopters. They didn't get 
it by accident, and in some cases had to work pretty hard to set it up 
and get it working. It's not surprising that there are not a lot of 
NAT'ish technologies deployed among that group.

More subtly (and this is the crux of our disagreement I think) my 
perspective is that a big part of the reason that there is so little 
end-user deployment now is the lack of features relative to IPv4. So not 
only does the current installed base not represent a statistically valid 
sample due to the inherent volunteer bias, the very organizations that 
would be representing a significant percentage, if not the majority of 
IPv6 end users, are self-selected out of the pool.

Meanwhile, for those that don't follow NANOG and might believe that I'm 
the only one holding a similar opinion, please check out this excellent 
response:

http://mailman.nanog.org/pipermail/nanog/2013-March/056619.html

Doug

---

From: Owen DeLong <[email-masked]>
Date: Tue, 5 Mar 2013 21:18:21 -0800

On Mar 5, 2013, at 8:56 PM, Doug Barton <[email-masked]> wrote:

> A light-bulb went on for me when I read this, which I think illustrates our difference of opinion. (The way I understand it) you and Lorenzo are looking at the small installed base of v6 now, seeing that there are very few NAT-a-like technologies already deployed in that group, and coming to the conclusion that people who deploy IPv6 are not interested in deploying NAT. You therefore conclude that there is hope for a future without NAT if you just keep shouting loud enough about how bad it is.

No. I wouldn't say that is a completely accurate characterization.

I won't attempt to speak for Lorenzo (he and I don't always agree, either), but for my part, I will say this.

The fact that so many IPv6 deployments exist just fine in the real world without "NAT-alikes" is proof that IPv6 can be deployed just fine without NAT.

The fact that NAT is so damaging to the internet in general means that I have a strong preference for an undamaged internet unencumbered by NAT.

Absent some truly compelling reason to add NAT to the mix (and none has yet been presented), I see no reason to accept its overwhelming costs, tradeoffs, and limitations.

IMHO, the organizations that are holding off on deploying IPv6 until they can have NAT will eventually be a self-resolving problem without NAT. Each will come to their own conclusion and do one of the following:

	1.	Realize that NAT is, actually, unnecessary and join the rest of the world in IPv6.
	2.	Deploy some form of hacked-together NAT-alike, realize that the ISVs are not supporting
		their world view, that their applications are breaking, and eventually scrap it.
	3.	Fade into irrelevance from an internet perspective as they are able to reach fewer and fewer
		internet participants over time.

Now, the other possibility, if we do enable NAT on IPv6 as you are advocating and the ISVs do choose to (unfortunately) support it is that we get back on the expensive and detrimental merry-go-round that is NAT,
waste more millions of dollars in development money to make the IPv6 internet just as degraded as the current IPv4 internet (or more so) and ensure that future generations are stuck with the subscriber/provider model built in at the basic level of the developer assumptions as they continue to produce code for the lowest common denominator of networks (that being the ones stuck behind NAT).

> That line of thought has several flaws. The most obvious is that at this point (leaving aside content networks) the people on the end-user networks that have IPv6 are almost all early adopters. They didn't get it by accident, and in some cases had to work pretty hard to set it up and get it working. It's not surprising that there are not a lot of NAT'ish technologies deployed among that group.

Actually, a lot of the residential subscribers on the internet and many of the mobile devices at this point did, in fact, get it quite by accident, so to speak. Comcast, Verizon, and Verizon Wireless, and AT&T have all deployed IPv6 on many unsuspecting subscribers mostly without incident. Last I heard from Jon, about 3% of all of Comcast's customers now have native IPv6.

> More subtly (and this is the crux of our disagreement I think) my perspective is that a big part of the reason that there is so little end-user deployment now is the lack of features relative to IPv4. So not only does the current installed base not represent a statistically valid sample due to the inherent volunteer bias, the very organizations that would be representing a significant percentage, if not the majority of IPv6 end users, are self-selected out of the pool.

I disagree. I talk to a lot of end-user network operators pretty regularly as part of my job. The number one reason I hear from them has nothing to do with NAT. In fact about 75% of them regard getting rid of NAT as a feature, not a bug. The main reason boils down to a combination of inertia and drag. Inertia in that IT professionals with a working IPv4 network are loathe to make a change to implement IPv6 unless they see a strong immediate need to do so. This is exacerbated by management that doesn't want to spend money on anything that doesn't have a return unless it's going to prevent the building from burning down in the next hour. Drag in terms of the fact that the transition costs money. Even if you already have all the hardware and software and don't need to pay for any upgrades, there's still a lot of man-hours involved in the process for any sizable network.

> Meanwhile, for those that don't follow NANOG and might believe that I'm the only one holding a similar opinion, please check out this excellent response:
> 

ROFLMAO… Do you have any idea who Matthew is?

He doesn't work in an end-user network… If you look at my rebuttal, you'll get a strong clue to where he's at and why he espouses such views at the bottom.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Mar 2013 08:49:06 +0000

>> No, Lorenzo's (and my) argument is that NAT technologies in IPv6
>> aren't getting wide deployment today (even as a percentage of IPv6
>> deployments) and that there's no reason to expect that trend will
>> change. Further, if that trend doesn't change, then it's unlikely that
>> there will be enough of an installed base to drive development.

s/IPv6/IPv4/ and this is something I might have written in 1994.

I'm a well known NAT hater and I dislike NPTv6 too, but I think
we have to be realistic. Those who want address isolation *will*
deploy NPTv6. Some will even insist on NAPT66.

It's perfectly appropriate to describe the ULA+NPTv6 scenario.
We can't recommend it, because NPTv6 is Experimental. Can we move on?

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Wed, 6 Mar 2013 01:59:02 -0800

> deploy NPTv6. Some will even insist on NAPT66.

I don't doubt this in the least.

The important questions are not whether that will happen or not. The
important questions are:

	1.	Will enough sites do this to drive ISVs to support it?
	2.	What can we do to reduce the number of sites that hinder
		themselves in this way to help ensure a negative answer to 1?

> We can't recommend it, because NPTv6 is Experimental. Can we move on?

I don't just want to not recommend it. I want to document that we recommend
against it. If we can do that, then yes, I'm willing to move on.

Owen

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 6 Mar 2013 12:00:56 +0100

> against it. If we can do that, then yes, I'm willing to move on.

I also think there's an education problem in the NAT space. Many people I've met
start with NAT requirements, then I go through that every interface has multiple 
addresses, that you can set aside part of the public address space for internal use to 
avoid future renumbering and conflicts, that you even have ULAs if really needed.
After that we go through NAT's "security" aspects and how we can replicate those
in a firewall.  The "multiple addresses on every interface" is quite often an eye-
opener, something they have totally missed. And something that I keep forgetting
in my daily work sometimes...

After that talk there's usually no more discussion of NAT. 

But of course, if people have used NAT forever and that's part of their TCP/IP
toolset, it's hard to relearn. And they end up requiring NAT all over again.

But in the end, there will always be people strongly requiring NAT. We just have 
to live with that. 

I agree with Owen that should not recommend it at all and spend more time
- and documentation - to explain the alternatives.

/O

---

From: David Farmer <[email-masked]>
Date: Wed, 06 Mar 2013 08:43:41 -0600

>> On Mar 6, 2013, at 00:49 , Brian E Carpenter <[email-masked]> wrote:
....
> - and documentation - to explain the alternatives.

Brian said we can't recommend it, I'll add we (the IETF) won't recommend 
it, but that's not what Owen is saying.  Owen is saying we can't discuss 
NAT without the equivalent of putting a surgeon general's waring on the 
top of the document that says NAT causes birth defects.  Or with less 
hyperbole, Owen is saying not recommending it, is not sufficient, he is 
saying we can't discuss it without recommend against it.

My question to Owen and Doug is where do you think this argument is 
going?  I'm getting sick and tired of hearing this debate on one mailing 
list or another every 3 to 6 months.  You guys are not going to shout 
the other down, so stop trying.  How do we find useful and practical 
compromise out of this discussion?

Like Brian I hate NAT as much as the next guy, but even I use it every 
day, and I hate myself for it, but I'm human and full of contradictions.

If IPv6 fails we have no hope of NAT ever going away. And I'm afraid 
that if we insist on a NAT free IPv6, that IPv6 will fail to be adopted 
by the masses of Internet users.  So, Doug stop putting lipstick on a 
PIG, NAT IS EVIL!! Owen get over it, NAT in IPv6 is a NECESSARY EVIL!!

For IPv6 to succeed and have any hope of the end-to-end principle to 
triumph in the end, IPv6 needs at least NPTv6 and probably even NAT66.

---

From: Bill Jouris <[email-masked]>
Date: Wed, 6 Mar 2013 06:59:41 -0800 (PST)

Which brings the question down to this:
To what extent do we discourage, but allow, NAT to continue, vs
to what extent do we simply refuse to accomodate it at all?

That is, do we want to insist on our ideal of what a perfect IPv6 network should look like?  Or are we willing to accomodate, to some extent, the real world that most of the people building and maintaining network work in?

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Wed, 3/6/13, Olle E. Johansson <[email-masked]> wrote:

From: Olle E. Johansson <[email-masked]>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To: "Owen DeLong" <[email-masked]>
Cc: [email-masked]
Date: Wednesday, March 6, 2013, 3:00 AM

/O

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2013 15:28:18 +0000

On Mar 6, 2013, at 9:43 AM, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:
My question to Owen and Doug is where do you think this argument is going?  I'm getting sick and tired of hearing this debate on one mailing list or another every 3 to 6 months.  You guys are not going to shout the other down, so stop trying.  How do we find useful and practical compromise out of this discussion?

Compromise isn't really the goal.   Rough consensus is the goal.   It's perfectly okay to declare rough consensus when there are a few people arguing against the consensus.

What I would ask you is this: why is it so important to you that there _not_ be a recommendation against NAT/NPT?   I get that you think NAT/NPT will happen, but that's pure speculation at this point.   Are you saying that you _prefer_ NAT/NPT?   If so, why?   If not, why not write a standard that says what we _want_?   What's the downside?

To be clear here, I don't mean to ask you to explain to me again about all the people who don't understand IPv6 and how they will react if they can't have NAT.   I mean to ask you, what _technically_ will go wrong if we recommend against NAT/NPT?   What is your use case where NAT/NPT is _required_ not by personal preference but because there is no other way to solve the problem?

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 06 Mar 2013 10:45:35 -0500

I don't feel very strongly if we do or do not put a recommendation in this
document related to NPTv6 or NAT in general.  I think it's important that
the con's be explained/document or references provided to other documents
which outline those cons.  I think many NAT supporters (and/or users) are
quick to note the benefits (feel dirty using benefits and NAT in the same
sentence) without considering the serious drawbacks.  I think these
drawbacks were highlighted well by folks like Lorenzo and Owen (breaking
E2E, cost of development to do NAT work-a-rounds, cost to business to make
it work, etc). 

If we do put a recommendation in, we just need to be consistent as other
documents which already discuss NPTv6 and ULA.

After that.. I am good.

My 0.02.

Regards,

Victor K

From:  Bill Jouris <[email-masked]>
Date:  Wed, 6 Mar 2013 06:59:41 -0800 (PST)
To:  "Olle E. Johansson" <[email-masked]>
Cc:  <[email-masked]>
Subject:  Re: [v6ops] ULA discussion #1 ULA+NAT

That is, do we want to insist on our ideal of what a perfect IPv6 network
should look like?  Or are we willing to accomodate, to some extent, the real
world that most of the people building and maintaining network work in?

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Wed, 3/6/13, Olle E. Johansson <[email-masked]> wrote:
> 6 mar 2013 kl. 10:59 skrev Owen DeLong <[email-masked]
> </mc/compose?to=[email-masked]> >:
> 
>> > 
>> > On Mar 6, 2013, at 00:49 , Brian E Carpenter <[email-masked]
>> </mc/compose?to=[email-masked]> > wrote:
>> > 
> [email-masked] </mc/compose?to=[email-masked]>
_______________________________________________ v6ops mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: David Farmer <[email-masked]>
Date: Wed, 06 Mar 2013 10:53:58 -0600

On 3/6/13 09:28 , Ted Lemon wrote:
>> going?  I'm getting sick and tired of hearing this debate on one
>> mailing list or another every 3 to 6 months.  You guys are not going
>> to shout the other down, so stop trying.  How do we find useful and
>> practical compromise out of this discussion?
>
> Compromise isn't really the goal.   Rough consensus is the goal.   It's
> perfectly okay to declare rough consensus when there are a few people
> arguing against the consensus.

Yes, rough consensus is the goal, but I believe some amount of 
compromise is usually necessary to reach rough consensus.  And, if we 
really had rough consensus on this issue and there were only a few 
people arguing against it; I doubt we would be seeing this argument pop 
up on so many different mailing list so frequently.

> What I would ask you is this: why is it so important to you that there
> _not_ be a recommendation against NAT/NPT?   I get that you think
> NAT/NPT will happen, but that's pure speculation at this point.   Are
> you saying that you _prefer_ NAT/NPT?   If so, why?   If not, why not
> write a standard that says what we _want_?   What's the downside?
>
> To be clear here, I don't mean to ask you to explain to me again about
> all the people who don't understand IPv6 and how they will react if they
> can't have NAT.   I mean to ask you, what _technically_ will go wrong if
> we recommend against NAT/NPT?   What is your use case where NAT/NPT is
> _required_ not by personal preference but because there is no other way
> to solve the problem?

These are good questions.

This document is not about NPT or NAT it is about ULA and how it should 
be used.  That said, I don't think you can fully discuss ULA without at 
least talking about its use in NPT, its in RFC 6296 (NPTv6) after all. 
But, the current draft is not recommend ULA for NPT it is only 
recognized as valid, but not recommended, use case for ULA.

RFC 6296 (NPTv6) makes it perfectly clear NAT is not recommended by the 
IETF, and this draft references it.  As NPT is not the primary subject 
of the draft and only discussion of NPT in the context of analyzing the 
use cases of ULA, and it not even a recommended use of ULA use case by 
the draft.  As such adding an explicit recommendation against the use of 
NAT seems irrelevant and a distraction to the primary discussion and the 
real subject of the draft.  It seems only about NAT haters piling on and 
insisting "NAT is EVIL" be included any time NAT is even talked about.

As I said before, if the draft were to recommend the use of ULA with 
NPTv6 then it would be necessary to make it clear that its actually not 
recommending NAT but only the use of ULA with NPTv6 when it is used. 
But this is necessary and valid, if and only if the draft were 
recommending the use of ULA with NPTv6, which it is not.

So, you asked whats the harm here?  Well a necessary discussion of the 
proper uses of ULA is being completely overshadowed by a relatively 
minor but valid part of the discussion, NPT.

If we want to have another "no holds barred" discussion of NAT fine, but 
that's not this draft and we need to stop trying to turn it into that.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2013 17:01:22 +0000

On Mar 6, 2013, at 11:53 AM, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:
So, you asked whats the harm here?  Well a necessary discussion of the proper uses of ULA is being completely overshadowed by a relatively minor but valid part of the discussion, NPT.

No, I asked you what the use case is that _requires_ NPT/NAT.   If there is no such use case, then we can logically conclude that there is no harm in recommending against NPT/NAT.   So if you can't come up with a use case, why are we arguing about this?

---

From: Bill Jouris <[email-masked]>
Date: Wed, 6 Mar 2013 09:18:03 -0800 (PST)

Putting in the cons of anything that we are not mandating is a good idea.  And if we are going to decide to discourage something (which looks like where we may be heading on this), putting in the reasons why not to do it is essential.  (Not least to avoid in the future some of the kinds of discussion we have had here lately about why certain decisions were take in the past.)

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Wed, 3/6/13, Victor Kuarsingh <[email-masked]> wrote:

From: Victor Kuarsingh <[email-masked]>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To: [email-masked]
Date: Wednesday, March 6, 2013, 7:45 AM

I don't feel very strongly if we do or do not put a recommendation in this document related to NPTv6 or NAT in general.  I think it's important that the con's be explained/document or references provided to other documents which outline those cons.  I think many NAT supporters (and/or users) are quick to note the benefits (feel dirty using benefits and NAT in the same sentence) without considering the serious drawbacks.  I think these drawbacks were highlighted well by folks like Lorenzo and Owen (breaking E2E, cost of development to do NAT work-a-rounds, cost to business to make it work, etc). 
If we do put a recommendation in, we just need to be consistent as other documents which already discuss NPTv6 and ULA. 
After that.. I am good.
My 0.02.
Regards,
Victor K

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

From: Olle E. Johansson <[email-masked]>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To: "Owen
 DeLong" <[email-masked]>
Cc: [email-masked]
Date: Wednesday, March 6, 2013, 3:00 AM

But of course, if people have used NAT forever
 and that's part of their TCP/IP
toolset, it's hard to relearn. And they end up requiring NAT all over again.

/O

---

From: Bill Jouris <[email-masked]>
Date: Wed, 6 Mar 2013 09:33:05 -0800 (PST)

Actually, no.  The fact that so many IPv6 deployments currently exist just fine without NAT is only a demonstration that those who can deploy without NAT have been doing so.  After all, if someone cannot deploy without NAT (or even just has reason to think that they need it), they would obviously not be among those who have deployed so far.

Not to say that NAT is really necessary every place that thinks that they need it.  Just that we do not yet have empirical proof that they are wrong.

Bill Jouris
Inside Products, Inc.
www.insidethestack.com
831-659-8360
925-855-9512 (direct)

--- On Tue, 3/5/13, Owen DeLong <[email-masked]> wrote:

From: Owen DeLong <[email-masked]>
Subject: Re: [v6ops] ULA discussion #1 ULA+NAT
To: "Doug Barton" <[email-masked]>
Cc: [email-masked]
Date: Tuesday, March 5, 2013, 9:18 PM

...
...

Owen

---

From: David Farmer <[email-masked]>
Date: Wed, 06 Mar 2013 11:34:04 -0600

On 3/6/13 11:01 , Ted Lemon wrote:
> No, I asked you what the use case is that _requires_ NPT/NAT.   If there
> is no such use case, then we can logically conclude that there is no
> harm in recommending against NPT/NAT.   So if you can't come up with a
> use case, why are we arguing about this?

There is an example provided in the draft, read it.  Rereading the 
draft, section 2.2.2.1, ULA-only Deployment, seems to imply that 
ULA-only Deployment is a special use case of ULA and not the generally 
intended deployment model.  I would support making a more explicit 
recommendation against the use of ULA-only Deployment model, especially 
for general purpose connectivity.  I remain opposed to an explicit 
recommendation against NAT or NPT as neither are truly the subject of 
the draft.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 10:52:10 -0800

> You show me your statistics first. :)

They're at http://www.worldipv6launch.org/measurements . You'll see a
number of large and very large ISPs with significant IPv6 usage numbers. To
my knowledge none of them use NAT66 or NPT66. If you add up the numbers you
get to tens of millions of users - Verizon Wireless alone declares 94M
customers, and if 17% of that has IPv6, then we're talking about 15M
customers.

> expected, if not disappointing. More importantly, see below.

I can see how it would be disappointing if we had no numbers. Fortunately
we do. :-)

> Yes, both my own in dealing with enterprise DNS/DHCP customers, and in the
> many years of people coming to the IETF and saying exactly this. There have
> been many people saying the same thing for well over a decade. The problem
> is that this message hasn't been heard by the IPv6 protocol folks, so the
> network operators for the most part don't bother anymore. It comes up on
> the various lists I'm on periodically, and the same few people are still
> giving out the same unrealistic advice.
>

One funny think I've learned about IPv6 deployment is that people love to
say "we can't deploy IPv6 because of X". But in my experience, what usually
happens when X is provided the same people move on to saying "we can't
deploy IPv6 because of Y", where Y != X. So X is really not the real
reason, it's just a red herring. What they are *actually* saying is "we see
no need to deploy IPv6 at the moment". I would bet that most of the people
you're talking to don't see a particular reason to deploy IPv6.

> same bad decisions, giving out the same bad advice, and most importantly,
> continue doing damage to IPv6 deployment.

Got it. But see, I don't think we're doing damage. IPv6 *is* growing
exponentially, and at this point enterprise deployment or lack thereof
won't change the numbers much. In my view, better to get real IPv6 with
global addressing deployed, and then the enterprises can choose to deploy
that or not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 10:55:32 -0800

> s/IPv6/IPv4/ and this is something I might have written in 1994.

You're forgetting the huge commercial pressures towards NAT in IPv4. In
IPv4, NAT meant "my roommate/wife/child/dog and I can use the Internet at
the same time without paying twice". Those commercial pressures do not
exist today in IPv6, because every ISP I have ever heard of provides a /64.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 11:03:19 -0800

On Wed, Mar 6, 2013 at 6:43 AM, David Farmer <[email-masked]> wrote:

> If IPv6 fails we have no hope of NAT ever going away. And I'm afraid that
> if we insist on a NAT free IPv6, that IPv6 will fail to be adopted by the
> masses of Internet users.
>

But... but.. then your argument doesn't fit the data available.

Because the data at http://www.worldipv6launch.org/measurements/ shows that
IPv6 *IS* being adopted by the masses of Internet users. Aren't AT&T,
Comcast and Verizon Wireless (to name some of the ones in your country)
some of the largest mass market ISPs in the world? Yes, the enterprise is
not going along as eagerly as the ISPs, but the enterprise wasn't leading
the charge towards deploying IPv4 either.

IPv6 deployment ain't broke. Don't fix it.

---

From: Arturo Servin <[email-masked]>
Date: Wed, 06 Mar 2013 18:39:18 -0200

Perhaps if you count Universities as enterprises may be we could see an
increase in traffic. But I do not really know.

Regards,
as

On 06/03/2013 16:52, Lorenzo Colitti wrote:
> global addressing deployed, and then the enterprises can choose to
> deploy that or not.

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 12:44:45 -0800

On 03/06/2013 10:52 AM, Lorenzo Colitti wrote:
> On Tue, Mar 5, 2013 at 8:35 PM, Doug Barton <[email-masked]
> number of large and very large ISPs with significant IPv6 usage numbers.
> To my knowledge none of them use NAT66 or NPT66. If you add up the
> numbers you get to tens of millions of users - Verizon Wireless alone
> declares 94M customers, and if 17% of that has IPv6, then we're talking
> about 15M customers.

And what does any of that have to do with the topic at hand? Obviously 
ISPs don't need NAT-a-like solutions for v6, and for the most part 
neither do their customers since most only have a few devices behind the 
ISP-provided CPE.

The topic we are discussing is the small - medium enterprise, in case 
you've forgotten.

> One funny think I've learned about IPv6 deployment is that people love
> to say "we can't deploy IPv6 because of X". But in my experience, what
> usually happens when X is provided the same people move on to saying "we
> can't deploy IPv6 because of Y", where Y != X. So X is really not the
> real reason, it's just a red herring. What they are *actually* saying is
> "we see no need to deploy IPv6 at the moment". I would bet that most of
> the people you're talking to don't see a particular reason to deploy IPv6.

First, the big enterprises and ISPs demanded PI space, and once they got 
it, they started deploying (per your statistics above). Second, some of 
those cycles were quite justified in the sense that the protocol of 10 
years ago wasn't quite ready for prime time, and needed to have some 
things fixed.

But more importantly, the same people have been saying for over a decade 
that they will not deploy IPv6 until they get full-featured DHCP, and a 
robust NAT-a-like solution. (I'll save you the time of responding with 
"robust NAT is an oxymoron.") The first still hasn't been delivered, and 
although I think 6296 is a good answer to the second, the IPv6 
cognescenti are still complaining about it.

And, even if those problems are solved, we hear from a non-trivial 
number of operators who have actually taken the time to dig into a 
potential IPv6 deployment that their next "can't deploy IPv6 because of 
X" problem is the concern about rogue RAs, and we still don't have a 
robust solution for that, and don't get me started on ND abuse ...

Doug

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 12:53:37 -0800

On Wed, Mar 6, 2013 at 12:44 PM, Doug Barton <[email-masked]> wrote:

>
>> They're at http://www.worldipv6launch.**org/measurements<http://www.worldipv6launch.org/measurements>. You'll see a
> ISPs don't need NAT-a-like solutions for v6, and for the most part neither
> do their customers since most only have a few devices behind the
> ISP-provided CPE.
>

No it wasn't. I was replying to your statement that "The vast majority of
current deployments aren't using IPv6, period. Of the tiny percentage that
are, some percentage of them are using a NAT-a-like strategy." The data we
have do not support that assertion.

And, even if those problems are solved, we hear from a non-trivial number
> of operators who have actually taken the time to dig into a potential IPv6
> deployment that their next "can't deploy IPv6 because of X" problem is the
> concern about rogue RAs, and we still don't have a robust solution for
> that, and don't get me started on ND abuse ...
>

And yet, > 90% of the users on Google's enterprise network have IPv6. We
don't use NAT66 or NPT66, we have solutions for rogue RAs. I suppose that's
a case of the people who say it can't be done not interrupting the ones who
are doing it. And yes, we do use NAT for IPv4 (sometimes multiple layers of
it).

I'll grant you this is possible because the network has PI space; we still
need to find a solution for multihoming using PA space. The recent homenet
and routing area drafts on source-based routing can, I think, solve that
problem.

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 13:02:32 -0800

On 03/06/2013 12:53 PM, Lorenzo Colitti wrote:
> On Wed, Mar 6, 2013 at 12:44 PM, Doug Barton <[email-masked]
>     The topic we are discussing is the small - medium enterprise, in
>     case you've forgotten.
>
>
> No it wasn't.

I've been talking about that all along, and I think I've been extremely 
clear about it. Small - medium enterprises are pretty much the only 
place where a NPTv6 + ULA solution makes sense. Home and SOHO users 
don't need it, and large enterprises multihome. If you were really 
confused about the topic I have been discussing all along then it might 
explain some of the disconnect.

> don't use NAT66 or NPT66,

Google is not a small - medium enterprise the last time I checked, and 
as you pointed out, you're using PI.

> we have solutions for rogue RAs.

Did you bring enough to share with the group? :)

Doug

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 13:06:56 -0800

> Did you bring enough to share with the group? :)

I think we're using the ones recommended by the IETF...

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 13:11:52 -0800

On 03/06/2013 01:06 PM, Lorenzo Colitti wrote:
> On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton <[email-masked]

So perhaps you would consider writing up a draft to describe your 
deployment experience, how robust the solutions are under actual 
testing, etc. I keep hearing from people that this problem isn't solved 
yet. If you have solid evidence to the contrary it would be most welcome.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2013 21:24:02 +0000

On Mar 6, 2013, at 4:02 PM, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:
Small - medium enterprises are pretty much the only place where a NPTv6 + ULA solution makes sense.

Why does it make sense in this case?   Please don't say "because operators of networks can't be bothered to learn IPv6," or something equivalent.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Mar 2013 13:27:22 -0800

On Wed, Mar 6, 2013 at 1:11 PM, Doug Barton <[email-masked]> wrote:

> deployment experience, how robust the solutions are under actual testing,
> etc. I keep hearing from people that this problem isn't solved yet. If you
> have solid evidence to the contrary it would be most welcome.
>

Please read and comment on
http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6 .
KK is one of the authors and one of the people behind Google's enterprise
IPv6 deployment.

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 13:43:51 -0800

On 03/06/2013 07:28 AM, Ted Lemon wrote:
>> going?

Owen wants an explicit recommendation _against_ NPT, I suggested that a 
rational, fair discussion of the pros and cons of each possible solution 
would be a lot more useful to the intended audience. Then let them 
decide on their own.

To answer Ted's question, the harm isn't technical, and it's naive to 
think that we're only dealing with technical issues here. To the extent 
that people will actually read the document what I want to avoid is a 
scenario like, "Wow, this combination of ULA + NPTv6 really sounds like 
it would meet my needs, but the IETF recommends against it. So now what 
do I do?"

The other harm is by continuing the ivory tower "NAT causes birth 
defects!" line we make the IETF increasingly anachronistic every day, 
since we are demonstrating rather clearly that we're entirely deaf to 
the needs of real world network operators.

>> I'm getting sick and tired of hearing this debate on one
>> to shout the other down, so stop trying.

I'm not trying to shout Owen or Lorenzo down, what I want to do 
(especially on the non-IETF lists) is demonstrate that there is another 
perspective, no matter how much some folks like to state that their view 
is the only right one.

>> How do we find useful and practical compromise out of this discussion?

I welcome input on finding a solution to this difficult problem. :)

> arguing against the consensus.

Fair enough ... what's disturbing me at this point however is the number 
of people who have written to me privately to say that they support my 
viewpoint, but are afraid to speak up on the list. That makes it hard to 
judge consensus.

My other concern is that while "consensus," rough or not, is a great 
goal, having what we produce align with reality and meet the needs of 
operators looking to deploy IPv6 is a more important one. It doesn't 
matter that we all agree on something if we're all wrong.

> _not_ be a recommendation against NAT/NPT?

Answered above.

> I get that you think
> NAT/NPT will happen, but that's pure speculation at this point.

Answered previously. :)

> Are you saying that you _prefer_ NAT/NPT?

Certainly not. I think it makes sense for a majority of organizations in 
one particular category, the small - medium enterprise. But even for 
many of them, as others have pointed out, PI space announced by their 
ISP would be _preferable_, it may just not be realistic.

> If so, why?   If not, why not

Because what we want doesn't matter a hill of beans. Also, see above.

> can't have NAT.

Even phrasing the issue this way seems to imply a fairly insulting bias 
against people who have looked at the needs of their enterprise and come 
to the conclusion that something like NPTv6 + ULA is the right answer. 
The fact that you still see the problem as, "They just don't understand 
IPv6" is a partial answer to David's question about why I keep repeating 
myself about how these people think.

> I mean to ask you, what _technically_ will go wrong if

Again, that's the wrong way to look at the question, but I think I've 
repeated myself enough on this by now. :)

Doug

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 13:50:54 -0800

On 03/06/2013 01:24 PM, Ted Lemon wrote:
> Why does it make sense in this case?

I've already covered this ad nauseum in previous posts on this thread, 
feel free to review them for the details.

Short answer, "enterprises hate renumbering." As in, really really hate 
it. A lot. Totally. NPT gives them the ability to be provider agnostic 
without having to worry about renumbering their inside network, or 
dealing with the trouble and expense of PI space.

Doug

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 13:52:37 -0800

On 03/06/2013 01:27 PM, Lorenzo Colitti wrote:
> On Wed, Mar 6, 2013 at 1:11 PM, Doug Barton <[email-masked]
>     testing, etc. I keep hearing from people that this problem isn't
>     solved yet. If you have solid evidence to the contrary it would be
>     most welcome.
>
>
> http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6
> . KK is one of the authors and one of the people behind Google's
> enterprise IPv6 deployment.

Awesome, thanks!

Doug

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Mar 2013 09:02:41 +1100

> explain some of the disconnect.

As far as I can tell the main problem SMB are solving with NAT is
the multi-homing with PA addresses.

Yet over in homenet they are looking at how to get source + destination
routing to work so that homes with multiple subnets can be multi
homed without any configuration.

You deprecate the PA RAs when the upstream link goes down and your
restore them when it comes back.  There a couple of stack that are
broken when this happens but they will get fixed/replaced.  Distributing
this sort of information is the bread and butter of the IETF.

With a little router smarts I don't even need a seperate protocol.
I know what upstream I got my PD through.  If the RAs on that
interface deprecate a PA RA I deprecate it on my down stream
interfaces.  When the PA RA is restored on that interface I do the
same thing on the others.

Now I'm sure some SMB don't like this sort of magic so providing
them with a explict protocol won't hurt.  I suspect anyone that as
worked with routing protocol design could deliver 5 different
solutions to how to do this in a day.  I've thought of a couple
just writing this piece of email.

So rather than saying NAT*6 + ULA is enevitable I suggest we look
as the problems that are trying to be solved with NAT*6 + ULA and
come up with alternatives.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Farmer <[email-masked]>
Date: Wed, 06 Mar 2013 16:08:19 -0600

On 3/6/13 13:03 , Lorenzo Colitti wrote:
> On Wed, Mar 6, 2013 at 6:43 AM, David Farmer <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     that if we insist on a NAT free IPv6, that IPv6 will fail to be
>     adopted by the masses of Internet users.
>
>
> Because the data at http://www.worldipv6launch.org/measurements/ shows
> that IPv6 *IS* being adopted by the masses of Internet users. Aren't
> AT&T, Comcast and Verizon Wireless (to name some of the ones in your
> country) some of the largest mass market ISPs in the world? Yes, the
> enterprise is not going along as eagerly as the ISPs, but the enterprise
> wasn't leading the charge towards deploying IPv4 either.
>

I know IPv6 can be deployed NAT free, hell I'm doing it.  I hope IPv6 
will be deployed mostly NAT free, the available data in my opinion 
suggest that could be true.  But, in my opinion there isn't enough 
available data to conclude that IPv6 will be deployed completely NAT 
free.

In rereading what I said, I'll agree I miss-stated what I'm afraid of, 
"the masses of Internet users" that is residential users will probably 
be NAT free for IPv6.  I should have said the masses of small to medium 
enterprise users.  I think the jury is still out on how most small to 
medium enterprises will deploy IPv6, and if it will be NAT free.

I'm worried that if we bully them and say "NO NAT for IPv6", they will 
say fine then "NO IPv6".  I hope not.  But I prefer the idea of saying 
"we suggest that your network will be better without NAT, but here is 
this thing NPTv6 that is a better way to do NAT if you really think you 
must do NAT for IPv6, but which every way you choose please implement IPv6."

Longer range I hope LISP or ILNP become viable solutions for small to 
medium enterprise users.  But honestly NAT is the least worst option for 
many small to medium enterprise users.  Could many of them do PI, sure. 
  Could many do PA and is renumber a little better in IPv6, sure.  But, 
as I said NAT is the least worst option for many of them, with the added 
benefit from their perspective that IPv6 with NPTv6 is more or less the 
same thing they are doing for IPv4.

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 14:14:37 -0800

> the multi-homing with PA addresses.

I've already made clear that IME what you describe is a factor for some, 
but renumbering is a very important factor for nearly all.

Doug

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Mar 2013 14:15:00 -0800

Hi,

On Mar 6, 2013, at 1:43 PM, Doug Barton <[email-masked]> wrote:
> Fair enough ... what's disturbing me at this point however is the number of people who have written to me privately to say that they support my viewpoint, but are afraid to speak up on the list. That makes it hard to judge consensus.

Not afraid, just bored beyond all recognition of Yet Another NAT Food Fight.

FWIW, I'm in Doug's camp on this.

I long ago gave up on architectural purity. The market will decide whether ULA+NAT is useful or an abomination. The idea that putting yet another statement that NAT IS EVIL!!1!! out there will have the same effect as all the other NAT IS EVIL!!1!! statements in the past: nothing positive.  Documenting the pros and cons in an unbiased, non-religious, data-backed way would be ideal, but does not appear to be possible in the IETF.  So it goes.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 07 Mar 2013 10:03:59 +1100

> but renumbering is a very important factor for nearly all.

If I'm NATed and change my provider I need to reconfigure (renumber)
my firewall.  If I'm NATted and change my provider I need to
reconfigure (renumber) in my DNS.

The ONLY difference is that I don't change one of my addresses on
a interface.

I'm making the assumption that SMB is getting "permanent" static
PA rather than slightly less permanent PA delivered to residential
customers.

You don't have to put PA addresses into the internal DNS.  You can
only put ULA addresses there.  You will only use ULA addreses to
communicate internally if you do that.

I really believe the renumbering issue has been blown all out of
proportion as people continue to apply IPv4 think to the issue.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2013 23:31:01 +0000

On Mar 6, 2013, at 4:43 PM, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:
To answer Ted's question, the harm isn't technical, and it's naive to think that we're only dealing with technical issues here. To the extent that people will actually read the document what I want to avoid is a scenario like, "Wow, this combination of ULA + NPTv6 really sounds like it would meet my needs, but the IETF recommends against it. So now what do I do?"

No, you didn't answer my question.   You just made another non-falsifiable assertion about the PR effects of advising against a course of action that everybody who has argued the technical merits has agreed is the right course of action.   I conclude that you actually do not have a use case to support your claims, and that you just have a strong opinion.

The IETF doesn't care about your opinion.   We care about the technical merits of your argument.   And we care about rough consensus and running code.  If that means we are dinosaurs, and that we are doomed, maybe that's okay.   But I really don't think this particular argument is the one that will doom us.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Mar 2013 23:32:18 +0000

On Mar 6, 2013, at 4:50 PM, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:
 or dealing with the trouble and expense of PI space.

Do you have any figures on that that you can offer?

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Mar 2013 15:42:21 -0800

Ted,

On Mar 6, 2013, at 3:32 PM, Ted Lemon <[email-masked]> wrote:
> On Mar 6, 2013, at 4:50 PM, Doug Barton <[email-masked]> wrote:

Trouble:

Obviously a subjective evaluation.  I'd recommend getting a PI block for yourself, after all, according to some on this list, it is painless and the cost inconsequential.

Expense:

http://www.afrinic.net/en/services/rs/membership-fees
http://www.apnic.net/services/become-a-member/how-much-does-it-cost
https://www.arin.net/fees/fee_schedule.html
http://www.lacnic.net/en/web/lacnic/membresia-costo
http://www.ripe.net/lir-services/member-support/become-a-member/membership-fees/membership-fees

Regards,
-drc

---

From: David Farmer <[email-masked]>
Date: Wed, 06 Mar 2013 17:52:10 -0600

> enterprise IPv6 deployment.

So here is what that draft has to say on the subject;

3.1.  Connectivity

    ....

    The use of ULAs may provide additional flexibility when an enterprise
    is using PA space, by providing an independent local prefix for
    internal use, while using the PA prefix externally in conjunction
    with NPTv6 [RFC6296].  Many enterprises today are used to using IPv4
    host-based NAT, and indeed may choose to use this model even when
    global IPv4 address space is available.  NPTv6 instead performs
    stateless prefix-based NAT, mapping from an external global prefix to
    (usually) an internal ULA prefix.  Such mappings can be used with
    multiple prefixes in multihoming scenarios, rather than using both
    ISP's global prefixes internally, with hosts receiving an IPv6
    address from each prefix (and then needing to ensure the correct
    source address is used to route traffic out of the correct egress).
    While NPTv6 can provide for simplified renumbering in certain
    scenarios, as described in [I-D.ietf-6renum-enterprise], it must be
    noted that many of the well-known issues with NAT still apply, in
    particular handling IPv6 addresses embedded in payloads.

    ....

3.5.  Network Prefix Translation for IPv6

    Network Prefix Translation for IPv6, or NPTv6 as described in
    [RFC6296] provides a framework to utilize prefix ranges within the
    internal network which are separate (address-independent) from the
    assigned prefix from the upstream provider or registry.  As mentioned
    above, while NPTv6 has potential use-cases in IPv6 networks, the
    implications of its deployment need to be fully understood,
    particularly where any applications might embed IPv6 addresses in
    their payloads.

    Use of NTPv6 can be chosen independently from how addresses are
    assigned and routed within the internal network and how prefixes are
    routed towards the Internet (included both PA and PI address
    assignment options).

This seems like a very reasonable treatment of the issue, to me. But, I 
don't see any explicit recommendation against the use of NPT or NAT 
other than by reference to RFC 6296.  Please explain why it is necessary 
for this draft about the use of ULA to include an explicit 
recommendation against the use of NPT or NAT?

I'd be happy with the inclusion of something like above "the 
implications of its deployment need to be fully understood", especially 
given that RFC 6296 has an Experimental Status.  But that is much 
different than an explicit recommendation against the use of NPT or NAT.

---

From: David Farmer <[email-masked]>
Date: Wed, 06 Mar 2013 20:10:49 -0600

> yet. If you have solid evidence to the contrary it would be most welcome.

We have a basic IPv6 inbound ACL on every wired access port blocking RAs 
and DHCP server responses for IPv4 and IPv6.  By the way, IPv6 ACL 
support was a requirement when we selected our current switches in 2004. 
  We also announce the RA from our routers with high priority.  The 
later is necessary because our enterprise wireless solution doesn't 
support IPv6 ACLs yet.  These techniques are discussed in RFC 6104.

IPv6 ACLs or an automated RA-Guard, RFC 6105, block most rouge RAs 
caused by basic malicious activity or simple misconfiguration.  Setting 
your routers RAs to high priority can deal with rogue RAs caused by 
simple misconfiguration in most cases. 
Draft-ietf-v6ops-ra-guard-implementation addresses some ways malicious 
activity can evade basic Rouge RA mitigation.  That said the we haven't 
seen malicious activity in the wild.  But, until we implemented the 
above techniques rogue RAs from simple misconfiguration were a huge 
issue.  The above techniques have made our IPv6 network very stable.

There is one additional technique we have used, that is filtering IPv6 
traffic all together with a 86DD Ether-Type filter.  This is a drastic 
solution, but is necessary in one part of our network.  We have IPv6 
enabled on our 802.1x/WPA2-enterprise authenticated wireless network, 
but the authentication portal for our web-portal authenticated wireless 
network doesn't support redirection of IPv6 traffic.  Therefore, we 
filter all IPv6 traffic on the web-portal authenticated wireless network 
to prevent rogue RAs and make our entire network AAAA record safe.  Bad 
or rogue IPv6 is worse than no IPv6.  We are working with our enterprise 
wireless vendor to support IPv6 on their authentication portal and I 
believe it is a committed feature for a future release.

Hope that helps.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Mar 2013 02:17:05 +0000

Hi, David

> intended deployment model. 
[Bing] ULA-only is recommended in isolated networks especially when multiple subnets are required, I think it might be the most solid use case of ULA so far. Please see section 2.2.1 and 3.1, the texts are not explicit of "ULA-only", maybe I need to revise it in the next ver.
For connected networks, I agree with you ULA-only is not the generally intended deployment model.

> I would support making a more explicit
> for general purpose connectivity.  
[Bing] In my understanding, using ULA-only in a connected network, is not determined from the ULA perspective, but from the perspective of whether they decide to use NAT things to gain address independence without acquiring PI, or Proxy things to gain central security control of the outgoing traffic. If they've decided to do such things, then ULA is a very proper choice.

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Mar 2013 02:25:42 +0000

Hi, David

> recognized as valid, but not recommended, use case for ULA.

[Bing] Agreed. Thank you for helping me clarify it.
 
> minor but valid part of the discussion, NPT.

[Bing] I think the discussion of NAT in this thread is meaningful, it helped us understand more in this topic.
But for the specific ULA draft, I agree with you, it seems a little bit overshadowing.

All the best,
Bing

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 02:51:14 +0000

On Mar 6, 2013, at 6:42 PM, David Conrad <[email-masked]<mailto:[email-masked]>> wrote:
Obviously a subjective evaluation.  I'd recommend getting a PI block for yourself, after all, according to some on this list, it is painless and the cost inconsequential.

Based on the links you sent, it seems like the answer to "how expensive is a PI" is "not very."

---

From: Owen DeLong <[email-masked]>
Date: Wed, 6 Mar 2013 19:35:12 -0800

> And, even if those problems are solved, we hear from a non-trivial number of operators who have actually taken the time to dig into a potential IPv6 deployment that their next "can't deploy IPv6 because of X" problem is the concern about rogue RAs, and we still don't have a robust solution for that, and don't get me started on ND abuse

If you want to claim your focused on the SME, then let's look at these problems from an SME perspective.

1.	At its worst, rogue RAs and ND abuse are no worse than ARP attacks and rogue DHCP servers in IPv4.
	The available solutions today are roughly equally robust.

2.	Rogue RAs come in two flavors. Accidental and Malicious.

	I am not aware of any case where Accidental rogue RAs are likely to be HIGH priority.
	Setting your valid RAs to high priority will automatically override the accidental ones.

	In the case of Malicious rogue RAs, the attacker has to be directly attached to your local
	link. In that case, the RAs really are low on your list of concerns compared to many of the
	other things Mr. attacker can be doing with that access.

As Lorenzo said, those of you that don't want to deploy IPv6 because "dunwanna" are very good at proposing all manner of legitimate problems that should be solved as "show-stoppers".  Yes, we've been doing a pretty good job playing whack-a-mole on the ones that should get solved through protocol updates and you're running out.

NAT-alike, Rogue-RA, and ND abuse are pretty much all you've got left in that arsenal.

NAT-alike isn't a protocol problem, it's an educational problem. Solving it in the protocol would be a (potentially) catastrophic mistake, IMHO.

Rogue-RA is a valid concern, but not really a show-stopper. 

ND abuse is also being worked and also not really a show-stopper in terms of impact and in terms of attacker requirements.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 6 Mar 2013 19:51:48 -0800

On Mar 6, 2013, at 1:43 PM, Doug Barton <[email-masked]> wrote:

> Owen wants an explicit recommendation _against_ NPT, I suggested that a rational, fair discussion of the pros and cons of each possible solution would be a lot more useful to the intended audience. Then let them decide on their own.
> 

I think that's EXACTLY the desired effect. That's not harm, that's beneficial.

That leads to the enterprise administrator doing more research into the problems caused by NAT/NPT and perhaps realizing that with large address space and other IPv6 features, there are, in fact, other ways to meet his needs that he might not have discovered if he'd just gone blindly down the "NAT worked in IPv4, let's do that in IPv6" road.

Again, not harm, benefit.

> The other harm is by continuing the ivory tower "NAT causes birth defects!" line we make the IETF increasingly anachronistic every day, since we are demonstrating rather clearly that we're entirely deaf to the needs of real world network operators.

I guess I'm confused… I'm pretty sure that Lorenzo and I are "real world network operators". NAT/NPT does real harm to network operations and not just on the networks where it is deployed. Do you actually operate a network? If not, why aren't any of these "real world network operators" on the list supporting your cause?

> I'm not trying to shout Owen or Lorenzo down, what I want to do (especially on the non-IETF lists) is demonstrate that there is another perspective, no matter how much some folks like to state that their view is the only right one.

There are many other perspectives. However, when it comes to developing standards that are used to document operational practices on the internet and make recommendations to network operators, it is my opinion that we should do everything in our power to discourage harmful practices.

I think that David's proposed language is weaker than what I would like to see, but I could tolerate it.

> Fair enough ... what's disturbing me at this point however is the number of people who have written to me privately to say that they support my viewpoint, but are afraid to speak up on the list. Th…

Decisions are made by those who show up. If they want their voices heard, they should speak up. I'm not sure what they are afraid of. They don't even have to read the replies if they don't want to, but failing to say anything means you should expect not to have your input considered since you didn't give any.

> My other concern is that while "consensus," rough or not, is a great goal, having what we produce align with reality and meet the needs of operators looking to deploy IPv6 is a more important one. It doesn't matter that we all agree on something if we're all wrong.

It's not like I asked for a statement that said "NPT is prohibited by IETF standards and any deployment of NAT in a network is not in compliance."

I just want a statement along the lines of:

"Deploying NAT or NPT in a connected IPv6 network is not recommended."

> Certainly not. I think it makes sense for a majority of organizations in one particular category, the small - medium enterprise. But even for many of them, as others have pointed out, PI space announced by their ISP would be _preferable_, it may just not be realistic.

Not realistic how? It's very easy to obtain PI space. It's relatively inexpensive (from an enterprise perspective).

> Even phrasing the issue this way seems to imply a fairly insulting bias against people who have looked at the needs of their enterprise and come to the conclusion that something like NPTv6 + ULA is the right answer. The fact that you still see the problem as, "They just don't understand IPv6" is a partial answer to David's question about why I keep repeating myself about how these people think.

Yes, you've repeatedly expressed that they don't want to fully understand IPv6 and want to do in IPv6 exactly what they've done in IPv4 regardless of who it hurts. I think his phrasing reflects what you have said rather accurately. If you meant to say something different, it's not evident in your writings.

Owen

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 7 Mar 2013 03:58:11 +0000

Hi, Ted

I mean to ask you, what _technically_ will go wrong if we recommend against NAT/NPT?   What is your use case where NAT/NPT is _required_ not by personal preference but because there is no other way to solve the problem?

[Bing] In section 2.6 of RFC5902:

"At present, the primary benefits one may receive from deploying NAT appear to be avoiding renumbering, facilitating multihoming without impacting routing scalability, and making edge consumer network configurations homogenous."

In section 4, it discussed solution space for renumbering and multihoming without NAT.  But they are not perfect, e.g. routing scalability issue of PI.
That is to say, we do have other way to solve the problems, but it may also bring us other issues. In my understanding, in RFC5902, the IETF just tend to encourage people working on the other ways by considering E2E transparency the higher priority.
So I think maybe it is not an all-or-none issue of recommending against NAT/NPT or not. It seems there is a controversial grey zone here, maybe just referring the relevant discussion in RFC5902 and RFC6296 is sufficient enough for this specific ULA draft.

Best regards,
Bing

---

From: Owen DeLong <[email-masked]>
Date: Wed, 6 Mar 2013 20:00:44 -0800

> 
> This seems like a very reasonable treatment of the issue, to me. But, I don't see any explicit recommendation against the use of NPT or NAT other than by reference to RFC 6296.  Please explain why it is necessary for this draft about the use of ULA to include an explicit recommendation against the use of NPT or NAT?
> 
> I'd be happy with the inclusion of something like above "the implications of its deployment need to be fully understood", especially given that RFC 6296 has an Experimental Status.  But that is much different than an explicit recommendation against the use of NPT or NAT.

Along those lines, how about the following statement:

"Use of NPT or NAT comes with a number of detrimental implications which should be fully considered and understood prior to any deployment of these technologies."

Owen

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 04:20:02 +0000

On Mar 6, 2013, at 10:58 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
In section 4, it discussed solution space for renumbering and multihoming without NAT.  But they are not perfect, e.g. routing scalability issue of PI.

Is this a practical concern, or a theoretical concern?   I know the original architecture called for perfect routing hierarchies so that the backbone would have only four or five aggregated routes on it, but is that really what we have now?   Is it really the case that PIs could not be routed?

I think that the answer to this is partly "no," and partly "we don't actually have much data."   So in my mind it's too soon to break a fundamental aspect of the Internet architecture.   It's certainly true that as time goes by, we may discover that ISPs are not willing to set up routing for PIs, and that small enterprise customers will have to choose between NAPT and renumbering.   But I haven't heard a single person make this case as a real problem that exists now, and even if it does exist in the future, it seems to me that it's something we'd like to _avoid_, not _enable_.

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 20:33:51 -0800

> 	The available solutions today are roughly equally robust.

Intentionally malicious rouge RAs set to high priority are quite a bit 
worse, because they redirect all traffic immediately, instead of the 
trickle you get with rogue DHCP.

Your point that the attacker needs to be inside the network already is 
valid of course, but it's not like that never happens.

Doug

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 06 Mar 2013 23:41:36 -0500

From:  Ted Lemon <[email-masked]>
Date:  Thu, 7 Mar 2013 04:20:02 +0000
To:  "Liubing (Leo)" <[email-masked]>
Cc:  "<[email-masked]>" <[email-masked]>
Subject:  Re: [v6ops] ULA discussion #1 ULA+NAT

On Mar 6, 2013, at 10:58 PM, Liubing (Leo) <[email-masked]> wrote:
> In section 4, it discussed solution space for renumbering and multihoming
> without NAT.  But they are not perfect, e.g. routing scalability issue of PI.
[VK].  Technically ULA+NAT w/PI has the same routing impact as Native w/PI.
The routing issues (which are theoretical as Ted noted below  for now) are
potentially diminished if there is a lot more ULA+NAT w/PA or just Native
w/PA.

Is this a practical concern, or a theoretical concern?   I know the original
architecture called for perfect routing hierarchies so that the backbone
would have only four or five aggregated routes on it, but is that really
what we have now?   Is it really the case that PIs could not be routed?

I think that the answer to this is partly "no," and partly "we don't
actually have much data."   So in my mind it's too soon to break a
fundamental aspect of the Internet architecture.   It's certainly true that
as time goes by, we may discover that ISPs are not willing to set up routing
for PIs, and that small enterprise customers will have to choose between
NAPT and renumbering.   But I haven't heard a single person make this case
as a real problem that exists now, and even if it does exist in the future,
it seems to me that it's something we'd like to _avoid_, not _enable_.

[VK]  It's hard to say what the future impact will be if PI becomes
widespread or the norm.  Not sure if this (mass PI usage) will be what sends
us to a seven figure global routing table.  Right now I am a bit more
concerned about how fragmented the IPv4 table may become.

Regards,

Victor K

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 20:43:10 -0800

On 03/06/2013 03:31 PM, Ted Lemon wrote:
>> think that we're only dealing with technical issues here. To the
>> extent that people will actually read the document what I want to
>> avoid is a scenario like, "Wow, this combination of ULA + NPTv6 really
>> sounds like it would meet my needs, but the IETF recommends against
>> it. So now what do I do?"
>
> No, you didn't answer my question.   You just made another
> non-falsifiable assertion about the PR effects of advising against a
> course of action that everybody who has argued the technical merits has
> agreed is the right course of action.

I think everyone (including me) agrees that an ideal world would not 
include NAT, or anything like it. So if you want to claim a "win" on the 
technical merits, go right ahead.

> I conclude that you actually do
> not have a use case to support your claims, and that you just have a
> strong opinion.

I've actually described the use case in tremendous detail, including the 
technical merits (and potential drawbacks) of the solution. Thus I 
conclude that you're not interested in listening to any opinions that 
contradict yours. (See what I did there?)

> The IETF doesn't care about your opinion.

More's the pity. :)

> We care about the technical
> merits of your argument.   And we care about rough consensus and running
> code.

But the problem is that you're choosing to limit your definition of 
"rough consensus" to the people who agree with you. You're shouting 
"You're ignorant!" "You're doing it wrong!" at the people who come to 
you and say that the things which you have achieved rough consensus on 
don't meet their needs, thus perpetuating your ability to get together 
and pat one another on the back while you rest comfortably in your echo 
chamber. If that's the life you want, go for it. I remember when the 
IETF was more than that.

> If that means we are dinosaurs, and that we are doomed, maybe
> that's okay.   But I really don't think this particular argument is the
> one that will doom us.

You're right of course, it's the attitude behind it that will doom you.

Doug (We don't live in an ideal world)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 04:44:58 +0000

On Mar 6, 2013, at 11:33 PM, Doug Barton <[email-masked]>
 wrote:
> Intentionally malicious rouge RAs set to high priority are quite a bit worse, because they redirect all traffic immediately, instead of the trickle you get with rogue DHCP.

ARP attacks can work pretty quickly (within 120 seconds).

> Your point that the attacker needs to be inside the network already is valid of course, but it's not like that never happens.

Yes, this is why you want to filter out malicious RAs on your switch.   Although there's some value in knowing that the hypothetical risk of a malefactor on the LAN has turned into the reality of a malefactor on the LAN.   I suspect this is why attacks of this sort are so rare.

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 20:45:13 -0800

> communicate internally if you do that.

Yes, that's certainly 1 valid use case, and I think the pros and cons of 
it should be included in the solution matrix.

Doug

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 20:52:43 -0800

On 03/06/2013 08:44 PM, Ted Lemon wrote:
> Yes, this is why you want to filter out malicious RAs on your switch.

Assuming you have switches of sufficient quality, sure. The flip side of 
that is the discussion that looks like this:

Tech: We need to upgrade all our switches so that we can safely deploy IPv6.
Manager: But the switches we have now work just fine, right?
Tech: Right, but ...
Manager: Are the new switches more expensive?
Tech: Yes, but ...
Manager: Does anything bad happen if we don't deploy IPv6?
Tech: No, but ...
Manager: Ok, I'll look at this new switch thing again when the switches 
we have need to be replaced.

> Although there's some value in knowing that the hypothetical risk of a malefactor on the LAN has turned into the reality of a malefactor on the LAN.   I suspect this is why attacks of this sort are so rare.

My point was not, "There are no solutions to these problems," although 
I'm glad to be learning more about the solutions that people have 
already deployed. My point is that when serious people investigated 
deploying IPv6 they found genuine deficits in the protocol. To then 
criticize those people (as Lorenzo did) by saying that they were never 
serious about deploying it in the first place is not accurate.

Doug

---

From: Doug Barton <[email-masked]>
Date: Wed, 06 Mar 2013 21:00:03 -0800

> "Use of NPT or NAT comes with a number of detrimental implications which should be fully considered and understood prior to any deployment of these technologies."

As long as this is accompanied by a fair discussion of the pros and cons 
of the various solutions, I'm fine with that, FWIW.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 05:19:43 +0000

On Mar 6, 2013, at 11:43 PM, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:
I've actually described the use case in tremendous detail, including the technical merits (and potential drawbacks) of the solution. Thus I conclude that you're not interested in listening to any opinions that contradict yours. (See what I did there?)

I didn't say you weren't listening.   I said you hadn't made your point.   So if this was an attempt to turn that around on me, please reconsider.

You're shouting "You're ignorant!" "You're doing it wrong!" at the people who come to you and say that the things which you have achieved rough consensus on don't meet their needs,

I'm not shouting at all.   And I don't determine consensus.   Maybe you meant "you, the IETF," though.   You still haven't explained why PI doesn't work for you.

On Mar 6, 2013, at 11:52 PM, Doug Barton <[email-masked]<mailto:[email-masked]>> wrote:
Manager: Does anything bad happen if we don't deploy IPv6?
Tech: No, but ...

This would be an example of someone who doesn't yet need to deploy IPv6.

My point is that when serious people investigated deploying IPv6 they found genuine deficits in the protocol. To then criticize those people (as Lorenzo did) by saying that they were never serious about deploying it in the first place is not accurate.

Yes, we have found genuine deficits in the protocol, just like we did when IPv4 started to see widespread deployment.   And just like when that happened, we are working to address those deficits, and have in fact addressed some of them.   It's a process.

It would be a mistake to push people into the process who don't need to be in it yet, and in order to get them into it, make engineering compromises that wind up being expensive in the long run.    For people who can have the conversation you reported between the manager and the tech, this really isn't the time for them to deploy; deploying will be more likely to get them to hate IPv6 than to successfully complete their IPv6 deployment.

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Mar 2013 21:30:53 -0800

On Mar 6, 2013, at 6:51 PM, Ted Lemon <[email-masked]> wrote:
> On Mar 6, 2013, at 6:42 PM, David Conrad <[email-masked]> wrote:

Clearly, Nominum is paying you too much :).

More seriously, this is another subjective evaluation. When doing that evaluation, it is probably useful to compare those costs (and don't forget to include the cost of legal review, getting someone to route your PI space, and the implications of yearly renewal) to the direct costs of using ULA+NAT to the purchaser. 

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 05:41:14 +0000

On Mar 7, 2013, at 12:30 AM, David Conrad <[email-masked]<mailto:[email-masked]>> wrote:
More seriously, this is another subjective evaluation. When doing that evaluation, it is probably useful to compare those costs (and don't forget to include the cost of legal review, getting someone to route your PI space, and the implications of yearly renewal) to the direct costs of using ULA+NAT to the purchaser.

Are you offering to supply text?   Don't forget to also cover the case where the small business just renumbers—we've heard that small businesses hate to do that, but it _is_ an option.

---

From: David Farmer <[email-masked]>
Date: Thu, 07 Mar 2013 00:40:50 -0600

On 3/6/13 23:19 , Ted Lemon wrote:

> You still haven't explained why PI doesn't work for you.

Lets look at the numbers, I did a little Googling; First what is an SME, 
best definition is an organization with less than 500 employees. And 
therefore, a large enterprise is an organization with 500 or more employees.

Within the US there are ~6M SMEs, obviously PI for all of them isn't 
going to make a workable route table. While were looking, Large 
enterprises within the US is about ~20K even extrapolating that over the 
globe and that's probably a workable route table.

But, about ~5.38M of the SMEs have less than 20 employees, business 
class or residential broadband probably covers most of these guys.  That 
leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are 100 to 
499 employees.

When you extrapolate that out globally, it seems clear that PI can't 
even reasonably cover all the medium sized guys, no matter where you 
draw the line.  So, it seems to me that there are probably a few million 
organizations globally for which PI isn't going to be practical and even 
IPv6's improved renumbering will be more that an annoying inconvenience.

Got my number here;
http://www.census.gov/econ/smallbus.html

---

From: Ray Hunter <[email-masked]>
Date: Thu, 07 Mar 2013 08:16:51 +0100

David Conrad wrote:
> Ted,
>
> On Mar 6, 2013, at 3:32 PM, Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
> Obviously a subjective evaluation.  I'd recommend getting a PI block
> for yourself, after all, according to some on this list, it is
> painless and the cost inconsequential.
>
> Expense:
>
Following IMHO

So there's clearly a market for a neutral (non transport provider
allied) organization to register some numbers on behalf of small medium
enterprises (per geography).

Maybe the ISP's could do this themselves per country as part of an SMB
service? Or the RIR's. I mean come on. The RIR's are just covering their
costs, and divide these by some formula across their membership. If a
huge number of SMB's bought PI space the fees would go down per SMB. The
tariffs are modifiable by the membership. This is a non-argument.

And as for portability of PI space across providers, and fear of routing
table explosion, I suggest the RIR's and LIR's look long and hard at
what happened in the mobile Telco World, where number portability was
thrust on them by the regulators / politicians. Telcos manage that
situation pretty well, even though there are potentially billions of
"host routes".  I know no-one wants compulsory provider tiering
hard-coded in the numbering scheme, but that does not exclude local
(voluntary) cooperation per geography.

An SMB doesn't strictly need an AS number, or to operate their own BGP,
or become an LIR, for them to be able to achieve portable numbering and
practical provider independence (which I 100% agree is the real issue
for businesses).

And that's even before we solve homenet and allow multi-homing with
multiple PA prefixes running simultaneously.

We should stop being so myopic on insisting on applying technical
solutions to a non-technical problem.

regards,
RayH

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Mar 2013 00:04:29 -0800

> Intentionally malicious rouge RAs set to high priority are quite a bit worse, because they redirect all traffic immediately, instead of the trickle you get with rogue DHCP.

Not really. They aren't guaranteed to win against other High Priority legitimate RAs, so, in fact...

> Your point that the attacker needs to be inside the network already is valid of course, but it's not like that never happens.

Sure, but my point is that when it does happen, having the wrong default gateway on a few hosts really drops low on the list of serious concerns.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Mar 2013 00:16:29 -0800

On Mar 6, 2013, at 20:52 , Doug Barton <[email-masked]> wrote:

> Assuming you have switches of sufficient quality, sure. The flip side of that is the discussion that looks like this:
> 
> Manager: Ok, I'll look at this new switch thing again when the switches we have need to be replaced.

Interesting... I've had that conversation a few times. It always went more like this:

Tech (me): We need to upgrade the switches or accept a certain amount of risk in our IPv6 deployment.
Manager: But the switches we have now work just fine, right?
Tech (me): No, they have a vulnerability to certain attacks over IPv6 that should be corrected.
Manager: How much will this cost?
Tech (me): Depends on how many of the switches can be upgraded in just software. (most of them)
	The few switches that can't be done software only (free) are switches that we have wanted to
	replace for some time now since they are becoming quite dated and lack improved management
	features that we have on the other switches.
Manager: What happens if we delay IPv6 instead?
Tech (me): Immediately, nothing. However, the further we push this down the road, the more likely it
	is that our eventual IPv6 deployment will be sudden, uncoordinated, and costly.
Manager: OK... Get me a budget number and I'll see what I can do.

> My point was not, "There are no solutions to these problems," although I'm glad to be learning more about the solutions that people have already deployed. My point is that when serious people investigated deploying IPv6 they found genuine deficits in the protocol. To then criticize those people (as Lorenzo did) by saying that they were never serious about deploying it in the first place is not accurate.

Actually, Lorenzo's point is spot on. The problem is you're not necessarily talking about the same people.

While the defects you cited are "genuine", they are also relatively low-risk in the real world. They present a different, but not larger attack surface when compared to known vulnerabilities in IPv4 that we have lived with for decades. There are, however, a LOT of people who haven't really looked at IPv6 and just keep looking for the next reason they don't have to. This is human nature, we resist change in a variety of ways.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Mar 2013 00:17:10 -0800

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

> As long as this is accompanied by a fair discussion of the pros and cons of the various solutions, I'm fine with that, FWIW.
> 

Hallelujah... Sounds like rough consensus to me. Nowhere did I oppose having a fair discussion of the pros and cons.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Mar 2013 00:22:27 -0800

On Mar 6, 2013, at 22:40 , David Farmer <[email-masked]> wrote:

> Lets look at the numbers, I did a little Googling; First what is an SME, best definition is an organization with less than 500 employees. And therefore, a large enterprise is an organization with 500 or more employees.
> 
> Within the US there are ~6M SMEs, obviously PI for all of them isn't going to make a workable route table. While were looking, Large enterprises within the US is about ~20K even extrapolating that over the globe and that's probably a workable route table.
> 
> But, about ~5.38M of the SMEs have less than 20 employees, business class or residential broadband probably covers most of these guys.  That leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are 100 to 499 employees.
> 
> When you extrapolate that out globally, it seems clear that PI can't even reasonably cover all the medium sized guys, no matter where you draw the line.  So, it seems to me that there are probably a few million organizations globally for which PI isn't going to be practical and even IPv6's improved renumbering will be more that an annoying inconvenience.

In fact a large portion of the 20-99 employee group is also pretty well served with the business class or residential broadband you mentioned.

The remaining 90K enterprises extrapolated globally works out to not much bigger than the current IPv4 routing table.

Given that there will be continued Moore's law advances in routing table capacity over the years between now and when they ALL want to multihome, I think we're actually OK there with PI.

Owen

---

From: Ray Hunter <[email-masked]>
Date: Thu, 07 Mar 2013 09:45:34 +0100

David Farmer wrote:
> Lets look at the numbers, I did a little Googling; First what is an
> SME, best definition is an organization with less than 500 employees.
> And therefore, a large enterprise is an organization with 500 or more
> employees.
>
How many SMEs are expected to want to significantly change geography and
simultaneously expect not to renumber when they change providers?
I suggest ~ 0. Because almost any such office move requires
reconfiguring IT and phased moves between sites.

I suggest the real requirement is that businesses want to be able to
easily change providers, whilst not physically relocating, and having
some simple solution to provider independence without having the
business crippled for more than a few hours; like not renumbering, or
flash renumbering, or dual provider operations, or something else
manageable.
 
> going to make a workable route table.

Why not?

These ~6M SMEs are presumably already connected to the Internet (and
routed today).

In the Netherlands they have the Polder Model: if the dyke breaks,
everyone drowns, so no one wants that to happen.

Same thing with the routing table. All ISP's are inter-dependent on
making the routing table work, otherwise the Internet collapses and they
have no service to sell. So even though they may compete (on last-mile
fees) why wouldn't they cooperate on ensuring the (PI) routing table
does not explode?

We have CIDR. We have BGP. We have so many addresses we don't know what
to do with them.
We're already working on dual PA operation, flash renumbering, flag
days, PI numbering etc.

What else is needed at IETF level? 

> While were looking, Large enterprises within the US is about ~20K even
> extrapolating that over the globe and that's probably a workable route
> table. 
> class or residential broadband probably covers most of these guys. 
> That leaves ~620K, of which ~530K are 20 to 99 employees, and ~90K are
> 100 to 499 employees.
>
When a business starts to need 1, 2 or 3 employees just to manage
firewalls and NAT devices from a total employee base of 20-499, guess what?
Those devices (and the excessive amount of people needed manage them)
are removed [based on personal experience]

IMHO the bases are covered.  
> draw the line.  So, it seems to me that there are probably a few
> million organizations globally for which PI isn't going to be
> practical and even IPv6's improved renumbering will be more that an
> annoying inconvenience.

---

From: Philipp Kern <[email-masked]>
Date: Thu, 7 Mar 2013 10:05:24 +0100

Doug,

am Wed, Mar 06, 2013 at 12:44:45PM -0800 hast du folgendes geschrieben:
> First, the big enterprises and ISPs demanded PI space, and once they
> got it, they started deploying (per your statistics above).

as a university we just became a LIR in RIPE land and got our /32. Granted, now
we're in the weird situation of being an IPv6-only LIR, because all our other
IPv4 space is unregistered legacy space. But it was still quite affordable and
we'd even still get a chunk of fresh IPv4 "for free".

Big enterprises and ISPs certainly could've got their own space through this
process.

Kind regards
Philipp Kern

---

From: Fernando Gont <[email-masked]>
Date: Thu, 07 Mar 2013 05:59:17 -0300

> I think we're using the ones recommended by the IETF... 

Please test them -- such implementations are likely broken (see
draft-ietf-6man-ra-guard-implementation. -- fwiw, ra6 of
<http://www.si6networks.com/tools/ipv6toolkit> is your friend.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Mar 2013 13:52:50 +0000

On Mar 7, 2013, at 1:40 AM, David Farmer <[email-masked]<mailto:[email-masked]>> wrote:
When you extrapolate that out globally, it seems clear that PI can't even reasonably cover all the medium sized guys, no matter where you draw the line.  So, it seems to me that there are probably a few million organizations globally for which PI isn't going to be practical and even IPv6's improved renumbering will be more that an annoying inconvenience.

I think the argument about the problem of getting PIs routed has some legs, but I'm not convinced that it won't be solved.   Still, if I were going to solve this problem for an SME, here is how I would solve it:

- I would deploy DHCPv6 throughout, along with RA that disables autonomous autoconfiguration.
- I would choose a PI, not a ULA, because PIs are guaranteed globally unique.   But you could use a ULA and get the same effect I'm proposing—it's just a really bad idea.   You only need a /48; if this practice becomes common I would expect a cooperative or competitive market to form to serve the need for /48 PIs.
- I would connect to one or more ISPs, with appropriate firewalls; I'll assume one for the rest of this diatribe.
- I would set up the DHCP server to issue a pair of addresses that have the same lower 80 bits; one on the PI, and one on the ISP /48.
- I would publish all my internal server names on the PI, not the ISP prefix.

Now I have a network where the address used externally is always the same as the address used internally in the bottom 48 bits.   ISP addresses are only used to communicate on the Internet.   PI addresses are all that is ever used to communicate internally.

Now my ISP connection is a commodity again.   If my ISP puts me over a barrel, I just switch to a different ISP; my hosts all renumber to the new ISP, but the PI address stays the same, so I'm not experiencing an internal renumbering.

---

From: David Farmer <[email-masked]>
Date: Thu, 07 Mar 2013 09:22:48 -0600

> In fact a large portion of the 20-99 employee group is also pretty well served with the business class or residential broadband you mentioned.

I agree, many if not most of theses Business-Class/Residential (BC/R) 
Broadband could cover many if not most of these.

> The remaining 90K enterprises extrapolated globally works out to not much bigger than the current IPv4 routing table.

This depends on the global multiplier and how many from the above that 
BC/R Broadband doesn't work for them.  I'm think it could be possible to 
push the two together.  However, I think the numbers make a strong 
argument that there probably needs to be another solution between BC/R 
Broadband (Classic-PA) and Classic-PI.  Personally, I like LISP or ILNP, 
because I believe it would serve many of the smaller guys better than 
BC/R Broadband.  There are other options too, I'm not opposed to what 
Ted suggested either.

However, lets be honest, must of these middle guys, and even many of the 
large guys, are using NAT today, and from their perspective it mostly 
works.  Is it perfect, no.  Is it good enough for many of them, yes, at 
least in their opinion.  You, Ted, me and many on the list disagree, but 
we don't write the check for them, they do.  Therefore, our opinion may 
count, but theirs counts more.

> Given that there will be continued Moore's law advances in routing table capacity over the years between now and when they ALL want to multihome, I think we're actually OK there with PI.

Like I said, I think there is a good argument that there is a gap.

---

From: Doug Barton <[email-masked]>
Date: Thu, 07 Mar 2013 08:33:09 -0800

On 03/07/2013 01:05 AM, Philipp Kern wrote:
| Doug,
|
| am Wed, Mar 06, 2013 at 12:44:45PM -0800 hast du folgendes geschrieben:
|> First, the big enterprises and ISPs demanded PI space, and once they
|> got it, they started deploying (per your statistics above).
|
| as a university we just became a LIR in RIPE land and got our /32.
Granted, now
| we're in the weird situation of being an IPv6-only LIR, because all
our other
| IPv4 space is unregistered legacy space. But it was still quite
affordable and
| we'd even still get a chunk of fresh IPv4 "for free".
|
| Big enterprises and ISPs certainly could've got their own space
through this
| process.

We already covered this in great detail. 10 years ago the landscape for
PI for non-ISPs was very different.

Doug

---

From: Philipp Kern <[email-masked]>
Date: Thu, 7 Mar 2013 17:37:28 +0100

> PI for non-ISPs was very different.

I'm talking about 2009, shortly before the introduction of PI in RIPE land. It
was not a deterrent at all and the financial burden, while significantly more
than PI, was also negligible. (Although I can understand if enterprises don't
want to go into the business of managing numbers themselves.)

I don't think that we were the only ones doing it that way.

Kind regards
Philipp Kern

---

From: Doug Barton <[email-masked]>
Date: Thu, 07 Mar 2013 10:21:06 -0800

On 03/07/2013 08:37 AM, Philipp Kern wrote:
> I'm talking about 2009

2009 > 2003 :)

---

From: David Farmer <[email-masked]>
Date: Thu, 07 Mar 2013 19:47:22 -0600

On 3/7/13 07:52 , Ted Lemon wrote:
> I think the argument about the problem of getting PIs routed has some
> legs, but I'm not convinced that it won't be solved.

I'm not convince that classic-PI couldn't solve the problem either, but 
I think there is a strong argument that their could be a gap.  While I 
think it might be possible for PI to cover the gap, I'm worried it might 
not.

> Still, if I were going to solve this problem for an SME, here is how
> I would solve it:
>
> - I would choose a PI, not a ULA, because PIs are guaranteed globally
> unique.   But you could use a ULA and get the same effect I'm
> proposing—it's just a really bad idea.   You only need a /48; if this
> practice becomes common I would expect a cooperative or competitive
> market to form to serve the need for /48 PIs.
> - I would connect to one or more ISPs, with appropriate firewalls; I'll
> assume one for the rest of this diatribe.
> - I would set up the DHCP server to issue a pair of addresses that have
> the same lower 80 bits; one on the PI, and one on the ISP /48.
> Now I have a network where the address used externally is always the
> same as the address used internally in the bottom 48 bits.   ISP
> addresses are only used to communicate on the Internet.   PI addresses
> are all that is ever used to communicate internally.
>
> Now my ISP connection is a commodity again.   If my ISP puts me over a
> barrel, I just switch to a different ISP; my hosts all renumber to the
> new ISP, but the PI address stays the same, so I'm not experiencing an
> internal renumbering.

I'd encourage you to write a draft proposing that model.  This is 
essentially non-connected PI + connected PA which is similar to the ULA 
+ GUA scenario in this draft.  This would be workable for SMEs 
especially the larger ones, but ULA + GUA still probably makes the most 
sense in the homenet scenario.

Maybe there should be a section in this draft quickly discussing 
alternatives to using ULA all together, like PI for non-connected 
networks, etc...  It shouldn't detail the full scenario like you just 
did.  But, point out that there are viable alternatives to using ULA 
that could be considered.  ARIN's end-user policy explicitly supports 
assignments for non-connected networks, I wrote it.  And there are 
advantages to this like real uniqueness not only statistical uniqueness, 
and fully functioning reverse DNS that won't have split DNS issues, just 
to name a few.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 7 Mar 2013 19:09:06 -0800

On Mar 7, 2013, at 5:47 PM, David Farmer <[email-masked]> wrote:

> I'm not convince that classic-PI couldn't solve the problem either, but I think there is a strong argument that their could be a gap.  While I think it might be possible for PI to cover the gap, I'm worried it might not.
> 

But why create a gap where one doesn't exist just because it might happen?

ULA+{NAT,NPT} comes with huge drawbacks. Worst of all, most of those drawbacks effect people outside of the ones implementing the ULA+{NAT,NPT} network which means the people doing the damage don't have to face most of the consequences of their actions and are, instead, able to inflict them on others.

As such, I strongly believe that we should do everything possible to make sure that such a solution is only implemented where absolutely necessary and with due consideration of the tradeoffs. Hopefully, if we do this well enough, ISVs will be able to start producing applications without NAT traversal in the medium-term future.

I think having a gap is pretty unlikely, actually. We already have routers that can handle a million prefixes and I expect that in less than 3 years, that will be approaching 2M or more.

> I'd encourage you to write a draft proposing that model.  This is essentially non-connected PI + connected PA which is similar to the ULA + GUA scenario in this draft.  This would be workable for SMEs especially the larger ones, but ULA + GUA still probably makes the most sense in the homenet scenario.

Why?

> Maybe there should be a section in this draft quickly discussing alternatives to using ULA all together, like PI for non-connected networks, etc...  It shouldn't detail the full scenario like you just did.  But, point out that there are viable alternatives to using ULA that could be considered.  ARIN's end-user policy explicitly supports assignments for non-connected networks, I wrote it.  And there are advantages to this like real uniqueness not only statistical uniqueness, and fully functioning reverse DNS that won't have split DNS issues, just to name a few.

I like this idea.

Owen

---

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

----- Original Message -----
> From: Doug Barton <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Cc: 
> Sent: Thursday, 7 March 2013 8:50 AM
> I've already covered this ad nauseum in previous posts on this thread, feel 
> free to review them for the details.
> 
> Short answer, "enterprises hate renumbering." 

How much experience do they have renumbering IPv6, using the preferred and valid lifetime mechanisms to phase in and phase out two (or more) GUA prefixes? Have they taken advantage of having a stable internal ULA address space so that only their external connectivity would be impacted by a GUA renumbering process? Or are you making these assertions about IPv6 practices purely based on IPv4 capabilities, experience and history?

Very few enterprises have deployed IPv6, so I don't think their experience with just IPv4 should be used to limit the guidance and advice on how to deploy IPv6. This is the trap of treating IPv6 as nothing more than IPv4 with bigger addresses.

>As in, really really 
> hate it. A lot. Totally. NPT gives them the ability to be provider agnostic 
> without having to worry about renumbering their inside network, or dealing with 
> the trouble and expense of PI space.
> 
> Doug

---

From: Doug Barton <[email-masked]>
Date: Fri, 08 Mar 2013 17:51:07 -0800

I've covered this ground already, so for those who read my previous 
posts, sorry for the spam, feel free to hit delete now.

On 03/08/2013 05:03 PM, Mark Smith wrote:
>> From: Doug Barton <[email-masked]> To: "[email-masked] WG"
>> <[email-masked]> Cc: Sent: Thursday, 7 March 2013 8:50 AM Subject:
>> Re: [v6ops] ULA discussion #1 ULA+NAT
>>
>> I've already covered this ad nauseum in previous posts on this
>> thread, feel free to review them for the details.
>>
> How much experience do they have renumbering IPv6

Totally irrelevant question, as the real pain points in renumbering are 
not the issues of getting new addresses on systems. Most end-user hosts, 
and a non-trivial number of servers, are configured dynamically nowadays.

> using the
> preferred and valid lifetime mechanisms to phase in and phase out two
> (or more) GUA prefixes?

I agree that on paper that sounds like a good plan, but I'd like to see 
more information from competent networking folks who have actually 
implemented it.

Meanwhile, given the incredibly low average skill level of even large 
enterprise network "engineers," and the low, or nonexistent level of 
such expertise in the SME world, I have little to no confidence that 
this is a viable strategy. I would love to be proven wrong though.

> Have they taken advantage of having a stable
> internal ULA address space so that only their external connectivity
> would be impacted by a GUA renumbering process?

I think this idea has merit as well, but it hits on the real pain points 
in renumbering: the meta issues surrounding firewalls, ACLs, bookmarks, 
hardware and software configuration, etc. No matter how much you tell 
people, "our policy is to use this inside network to access this set of 
resources" when that doesn't work, but the "outside" network does, 
people are going to go with what works. And then those things get 
hard-coded somewhere, and then they have to be supported "forever." I've 
seen this on IPv4 only networks lots of times, there is no reason to 
believe it would be any different with IPv6. People who range from 
minimally competent to actively dangerous with IPv4 now cannot be 
trusted to "do it right" with complex IPv6 configurations.

People in the IETF tend to poo-poo these kinds of things when I talk 
about them, insisting that no one could really be that stupid/careless. 
As I've pointed out in the past, people around here are way above 
average, so yeah, these kinds of problems would seem ridiculous to them. 
OTOH, I work with the "below average" crowd day in and day out, and I 
could tell you stories ...

> Or are you making
> these assertions about IPv6 practices purely based on IPv4
> capabilities, experience and history?

First of all, to the extent that this line of thought is being applied 
to me, I am really getting tired of the thinly-veiled insult. I know, 
use, deploy, and advocate for IPv6 myself; and have helped others do so 
as well. I speak from experience, not theory.

More to the point however, in regards to the way most SMEs are looking 
at this, they _are_ mired in IPv4-think to some extent, because that's 
what they know, and what they are familiar with. It's up to us to listen 
to their concerns, try and discern their real needs, and figure out ways 
to meet them. Shouting, "You're doing it wrong!" at them isn't really 
going to help the situation.

> Very few enterprises have deployed IPv6, so I don't think their
> experience with just IPv4 should be used to limit the guidance and
> advice on how to deploy IPv6. This is the trap of treating IPv6 as
> nothing more than IPv4 with bigger addresses.

... which I know that the IPv6 cognescenti really hates. :)  FWIW, *I* 
am not doing that, but what I *am* doing is listening, and sorting the 
wheat from the chaff. SMEs need a solution that gives them stable 
addressing for their inside network while allowing them to be provider 
independent. Out of all the possible solutions ULA + NPTv6 seems to be 
the safest and best in this space. Although like I said above, I'd like 
to see some real operational experience with a mix of ULA and GUA on the 
inside. I think for the overwhelming majority of SMEs their own PI space 
is a non-starter, so this is likely to be a situation where the 
least-unattractive option is the "best."

hth,

Doug

---

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

----- Original Message -----
> Sent: Saturday, 9 March 2013 12:51 PM
> I've covered this ground already, so for those who read my previous posts, 
> sorry for the spam, feel free to hit delete now.
> 
> Totally irrelevant question, as the real pain points in renumbering are not the 
> issues of getting new addresses on systems. Most end-user hosts, and a 
> non-trivial number of servers, are configured dynamically nowadays.
> 

I don't consider renumbering to just be a problem of getting new addresses onto systems. Renumbering a network is achieved when every IP address in every location in the network, including ACLs, DNS, hosts files etc., as well as on hosts interfaces, has been changed.

> I agree that on paper that sounds like a good plan, but I'd like to see more 
> information from competent networking folks who have actually implemented it.
> 

I haven't read them, but I think the following reports describe experiences using IPv6's renumbering capabilities:

"Cookbook for IPv6 Renumbering in SOHO and Backbone Networks."
http://www.6net.org/publications/deliverables/D3.6.1.pdf

"Cookbook for IPv6 Renumbering in ISP and Enterprise Networks."
http://www.6net.org/publications/deliverables/D3.6.2.pdf

One of the authors (Tim Chown) is a common participant here, so he might be able to provide further perspective if necessary.

> Meanwhile, given the incredibly low average skill level of even large enterprise 

> network "engineers," and the low, or nonexistent level of such 
> expertise in the SME world, I have little to no confidence that this is a viable 
> strategy. I would love to be proven wrong though.
> 
> I think this idea has merit as well, but it hits on the real pain points in 
> renumbering: the meta issues surrounding firewalls, ACLs, bookmarks, hardware 
> and software configuration, etc. No matter how much you tell people, "our 
> policy is to use this inside network to access this set of resources" when 
> that doesn't work, but the "outside" network does, people are 
> going to go with what works. And then those things get hard-coded somewhere, and 
> then they have to be supported "forever." I've seen this on IPv4 
> only networks lots of times, there is no reason to believe it would be any 
> different with IPv6. People who range from minimally competent to actively 
> dangerous with IPv4 now cannot be trusted to "do it right" with 
> complex IPv6 configurations.
> 

The specific goal of this ID is to provide advice on what people should do. If they don't "RTFM" and treat IPv6 as IPv4 with bigger addresses, then they'll create the same _avoidable_ problems for themselves with IPv6 that they haven't been able to avoid with IPv4.

It seems a bit silly to me to write advice documents for an audience who will ignore the advice anyway (which I think is the audience you're mostly describing). The intended audience would be people who are willing to be open minded about how best to deploy IPv6 and who are looking for advice.

It seems to be a common to say it is better to avoid giving good advice that is contrary to what close minded people will do. The thinking seems to be, the close minded people won't do what is best and advised, so therefore what is "best" should be lowered and redefined to what close minded people will be willing to do. That doesn't help them, because they think what they are doing is fine, and it doesn't help other people who are open minded, because they don't become aware of better methods they may benefit from.

> People in the IETF tend to poo-poo these kinds of things when I talk about them, 
> insisting that no one could really be that stupid/careless. As I've pointed 
> out in the past, people around here are way above average, so yeah, these kinds 
> of problems would seem ridiculous to them. OTOH, I work with the "below 
> average" crowd day in and day out, and I could tell you stories ...
> 

I too know people who work in enterprises, and have myself. I believe IPv6 should be at least as easy to use and deploy as IPX and Appletalk were in the 1990s (20 years ago!). IPv4 was harder to learn and deploy than those, so advice and descriptions of IPv4's practices shouldn't be propagated into IPv6. Documents giving advice on IPv6 deployment should leverage where possible all of IPv6's capabilities that IPv4 doesn't have. The bar for IPv6 usability should set at or should be higher than the usability of IPX and Appletalk, not equal to IPv4s.

> First of all, to the extent that this line of thought is being applied to me, I 
> am really getting tired of the thinly-veiled insult.

I'm not intending to insult. Sorry if that is how it was taken. What I am doing is questioning whether IPv6 practices should be constrained by and to what have been common IPv4 practices. 

> I know, use, deploy, and 
> advocate for IPv6 myself; and have helped others do so as well. I speak from 
> experience, not theory.
> 

Exactly. So I don't think you have answered my questions. So what is your and/or your enterprise customers _experience_ with renumbering IPv6 using the IPv6 mechanisms available?

I don't think the evidence that enterprises don't like renumbering IPv4 networks is also evidence that they won't like renumbering IPv6 networks, when they have no experience doing it.

<snip>

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Mar 2013 08:25:39 +0000

> One of the authors (Tim Chown) is a common participant here, so he might be able to provide further perspective if necessary.

Erm, he's been giving that perspective quite regularly as co-chair of
6renum, whose output can be found at
http://datatracker.ietf.org/wg/6renum/

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Sat, 9 Mar 2013 03:41:17 -0800

On Mar 8, 2013, at 17:51 , Doug Barton <[email-masked]> wrote:

> I've covered this ground already, so for those who read my previous posts, sorry for the spam, feel free to hit delete now.
> 
> Totally irrelevant question, as the real pain points in renumbering are not the issues of getting new addresses on systems. Most end-user hosts, and a non-trivial number of servers, are configured dynamically nowadays.
> 

As I see it, the real pain points are:

	1.	Things about your address configuration that require customer coordination.

	2.	Your addresses in configuration files you don't control. (Remote VPN boxes, etc.)

	3.	Firewall rulesets, etc.

Of these, in the SME world, 1 is virtually non-existent. 2 is rare and when it does exist, we're
usually talking about 1 or two instances in the average SME. Hardly a show-stoper.

As to 3, this is much simpler in IPv6 because you can literally duplicate the rules and do a
global search and replace on them to produce the rules for the new addresses. In IPv4, that
was rarely so simple because you would have 192.0.2.64/26 from one provider whereas
the next provider would give you 209.67.126.192/26.

Remember, in IPv6, you're just replacing the first 12 hex digits. Everything else can stay
the same.

> I agree that on paper that sounds like a good plan, but I'd like to see more information from competent networking folks who have actually implemented it.
> 

What would you like to see? I've already told you that I've done it multiple times. As I stated, if you plan for it in the network deployment, it's pretty easy. If you don't, then it's hard once.

> Meanwhile, given the incredibly low average skill level of even large enterprise network "engineers," and the low, or nonexistent level of such expertise in the SME world, I have little to no confidence that this is a viable strategy. I would love to be proven wrong though.

It really isn't that hard. The truly hardest part is getting someone involved in the planning stage that understands the concepts well enough to plan properly.
(Or have someone come fix it during the first iteration).

Beyond that, it really boils down to this:

1.	Turn on the new addresses and test them.
2.	Stop advertising the old addresses in the RAs. (If you want to accelerate the process, you
	can immediately set the desired lifetime to 0 and wait a little while before pulling out the RAs.)
3.	Turn off the old addresses in DHCP (if applicable)
4.	Wait for the valid lifetimer to expire.
5.	Deprecate the old addresses from your routers.

> I think this idea has merit as well, but it hits on the real pain points in renumbering: the meta issues surrounding firewalls, ACLs, bookmarks, hardware and software configuration, etc. No matter how much you tell people, "our policy is to use this inside network to access this set of resources" when that doesn't work, but the "outside" network does, people are going to go with what works. And then those things get hard-coded somewhere, and then they have to be supported "forever." I've seen this on IPv4 only networks lots of times, there is no reason to believe it would be any different with IPv6. People who range from minimally competent to actively dangerous with IPv4 now cannot be trusted to "do it right" with complex IPv6 configurations.

Not sure what you mean by bookmarks. Bookmarks in web browsers should be using names, not numbers.

Why would the inside network not work at a time when the outside does? Makes no sense in IPv6.

> People in the IETF tend to poo-poo these kinds of things when I talk about them, insisting that no one could really be that stupid/careless. As I've pointed out in the past, people around here are way above average, so yeah, these kinds of problems would seem ridiculous to them. OTOH, I work with the "below average" crowd day in and day out, and I could tell you stories ...

Yes, I'm familiar with this crowd. Bottom line, no matter what we do, that crowd is going to suffer. You just can't sell guns to people who are willing to shoot themselves in the foot and expect them to somehow come out of the process without any pain. Frankly, ULA+NPT/NAT will _NOT_ reduce their pain in these instances. It will reduce their level of reactionary discomfort with learning something new, but it will not reduce their opportunities to make all of the mistakes you are expecting to cause problems with the other solutions and they will hurt just as bad.

> First of all, to the extent that this line of thought is being applied to me, I am really getting tired of the thinly-veiled insult. I know, use, deploy, and advocate for IPv6 myself; and have helped others do so as well. I speak from experience, not theory.

It's just that so much of what you say seems to reflect a real ignorance of the many of the tools available in IPv6. Experience does not always equate to a complete understanding of the toolset available. I have lots of IPv6 experience too. I'm still learning new things about it pretty regularly.

> More to the point however, in regards to the way most SMEs are looking at this, they _are_ mired in IPv4-think to some extent, because that's what they know, and what they are familiar with. It's up to us to listen to their concerns, try and discern their real needs, and figure out ways to meet them. Shouting, "You're doing it wrong!" at them isn't really going to help the situation.

Right... But the solution to that is education. What you call shouting is actually an attempt to share knowledge and provide better alternatives that lead to less pain. If you have a better path to proper education, I'm all ears. If you just want to keep shouting "We want to do it the way we have been doing it and we won't accept any other answer" on their behalf, then that isn't going to help the situation either.

> ... which I know that the IPv6 cognescenti really hates. :)  FWIW, *I* am not doing that, but what I *am* doing is listening, and sorting the wheat from the chaff. SMEs need a solution that gives them stable addressing for their inside network while allowing them to be provider independent. Out of all the possible solutions ULA + NPTv6 seems to be the safest and best in this space. Although like I said above, I'd like to see some real operational experience with a mix of ULA and GUA on the inside. I think for the overwhelming majority of SMEs their own PI space is a non-starter, so this is likely to be a situation where the least-unattractive option is the "best."

GUA is a fine solution in that space. I know you don't like it for whatever reason, but it really is a vastly superior solution to NPT.

ULA+PA is a better solution than ULA+NPT.  NPTv6 is experimental at best and not very likely to be widely supported by ISVs. As such, I can hardly consider it even remotely "safe" for enterprise deployment at this point.

If you have GUA on the inside, what do you need ULA for?

You keep saying that their own PI space is a non-starter, but you haven't done anything to back that up with any rational reason.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Mar 2013 13:47:08 +0000

On 09/03/2013 11:41, Owen DeLong wrote:
...
> Remember, in IPv6, you're just replacing the first 12 hex digits. Everything else can stay

Huh? That only applies if you have exactly one /48 prefix replaced
by another. The general case is significantly more complex.

Again, see the 6renum documents, although they are only scoped
for enterprise networks.

   Brian

---

From: Owen DeLong <[email-masked]>
Date: Sat, 9 Mar 2013 06:09:54 -0800

> by another. The general case is significantly more complex.

We're talking about renumbering the SMB to change ISPs.

How would the general case for that NOT be replacing the /48 from the previous
provider with a /48 from a new provider?

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sat, 9 Mar 2013 14:14:35 +0000

> provider with a /48 from a new provider?

The only case where there might be trouble is where the provider only offers a /56, but the previous provider offered a /48, and the SME expanded into the high bits of the /48 but doesn't actually need that many bits.   But in any case where NPT would work, the renumbering that we are talking about would be a simple prefix replacement, so that concern doesn't contradict the original argument.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Mar 2013 16:23:33 +0000

> The only case where there might be trouble is where the provider only offers a /56, but the previous provider offered a /48, and the SME expanded into the high bits of the /48 but doesn't actually…

NPTv6 can deal with various lengths of prefix, so I don't quite
see that last point. The benefits of a standard prefix length
would (IMNSHO) have been considerable, but that ship has sailed.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Sat, 9 Mar 2013 16:52:18 +0000

> would (IMNSHO) have been considerable, but that ship has sailed.

I suppose so, but the config file would be a lot more complicated, and the assertion that's been made here is that NPT is _easier_, not just that it's _possible_.

---

From: Doug Barton <[email-masked]>
Date: Sat, 09 Mar 2013 11:44:49 -0800

> I suppose so, but the config file would be a lot more complicated, and the assertion that's been made here is that NPT is _easier_, not just that it's _possible_.

The assertion I made is that ULA + NPT meets the needs of most SMEs 
better than the other options. I agree that if an organization fully 
utilized a /48 and then were only offered a larger prefix from a new ISP 
it would make things more difficult for them to transition to that ISP. 
However, the same would be true if they were using the PA space directly.

This issue would be a good thing to put in the list of "cons" for both 
the NPT and direct PA solutions.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Sat, 9 Mar 2013 20:28:02 +0000

On Mar 9, 2013, at 2:44 PM, Doug Barton <[email-masked]> wrote:
> The assertion I made is that ULA + NPT meets the needs of most SMEs better than the other options. I agree that if an organization fully utilized a /48 and then were only offered a larger prefix from a new ISP it would make things more difficult for them to transition to that ISP. However, the same would be true if they were using the PA space directly.

Yes, but additionally, if the organization uses the /48 sparsely, even if they can _fit_ into a /56, they are still going to have to do a lot of work to make that happen, whether it's renumbering or a really hairy NPT table.   There's probably some advice worth giving about not doing this, however this discussion ultimately ends...

---

From: Owen DeLong <[email-masked]>
Date: Sat, 9 Mar 2013 23:50:10 -0800

> would (IMNSHO) have been considerable, but that ship has sailed.

Actually, even the providers that are brain-damaged enough to think they don't want to give /48s to residential are all still planning on /48 for SMB to the best of my knowledge.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 9 Mar 2013 23:52:42 -0800

> Yes, but additionally, if the organization uses the /48 sparsely, even if they can _fit_ into a /56, they are still going to have to do a lot of work to make that happen, whether it's renumbering o…

If they can fit into the /56, the additional renumbering effort mostly amounts to more iterations of global search and replace because you may need to d each /64 instead of the whole /48 in one shot. However, this really shouldn't be an issue for an SME as I think ISPs are still planning on /48s for business. It's just residential that they want to shaft for unknown reasons, to the best of my knowledge.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sun, 10 Mar 2013 12:20:16 +0000

> If they can fit into the /56, the additional renumbering effort mostly amounts to more iterations of global search and replace because you may need to d each /64 instead of the whole /48 in one sho…

Yup.

---

From: Tom Perrine <[email-masked]>
Date: Sun, 10 Mar 2013 12:12:31 -0700

>> If they can fit into the /56, the additional renumbering effort mostly amounts to more iterations of global search and replace because you may need to d each /64 instead of the whole /48 in one sh…

I suspect that this is a way to differentiate the lowest level of service from a premium level of service, in order to push home users to move to a higher-cost option.

Much like US cable providers push residential users to "business class" 
in order to get static IP assignments.

---

From: Joel Wirāmu Pauling <[email-masked]>
Date: Mon, 11 Mar 2013 09:06:28 +1300

On 10/03/2013 5:23 AM, "Brian E Carpenter" <[email-masked]>
wrote:
> > The only case where there might be trouble is where the provider only
offers a /56, but the previous provider offered a /48, and the SME expanded
into the high bits of the /48 but doesn't actually need that many bits.
But in any case where NPT would work, the renumbering that we are talking
about would be a simple prefix replacement

IIRC isn't there a recommendation that v6 delegations should be hooked into
DNS and IPAM.

Shouldn't the renumbering complexity be dealt with outside of general
recommendations for numbering?

---

From: Doug Barton <[email-masked]>
Date: Sun, 10 Mar 2013 13:28:06 -0700

On 03/10/2013 01:06 PM, Joel Wirāmu Pauling wrote:
> IIRC isn't there a recommendation that v6 delegations should be hooked
> into DNS and IPAM.

Ideally, sure. But not all sites, especially the small - medium 
businesses that we're discussing for non-PI solutions, are able to 
afford such a tool, or have staff with sufficient time/training to use 
one effectively.

> recommendations for numbering?

Please read the numerous posts on this thread already where it is 
generally agreed that simply putting numbers onto hosts is the tip of 
the iceberg when it comes to renumbering.

Doug

---

From: Philipp Kern <[email-masked]>
Date: Sun, 10 Mar 2013 22:49:54 +0100

Doug,

am Sun, Mar 10, 2013 at 01:28:06PM -0700 hast du folgendes geschrieben:
> generally agreed that simply putting numbers onto hosts is the tip
> of the iceberg when it comes to renumbering.

from my experience putting numbers somewhere on hosts is the most time
consuming tasks and the ones that might require a flag day. Firewall rules and
RAs are easily taken care of. But static addressing and manual ACLs (e.g.
apache or postgresql) without keeping track where an address got written down
are really what's making renumbering hard.

Kind regards
Philipp Kern

---

From: Gert Doering <[email-masked]>
Date: Mon, 11 Mar 2013 14:05:48 +0100

Hi,

On Thu, Mar 07, 2013 at 08:16:51AM +0100, Ray Hunter wrote:
> "host routes".  

If you can life with "changing to a different provider will take a few
days to move the address" and "occasionally the number will be completely
lost afterwards", then yes, this model would surely "scale"...

(Network roaming is more like mobile IPv6 as it doesn't change the
"home network" for your number, but instead tunnel back and forth)

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Mar 2013 14:32:26 -0700

On Mar 10, 2013, at 12:12 PM, Tom Perrine <[email-masked]> wrote:

> Much like US cable providers push residential users to "business class" in order to get static IP assignments.
> 

Conduct which I certainly don't think should be encouraged in an IETF document.

Owen

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 27 Mar 2013 18:25:29 +0100

I think one could write down that packet headers containing an address 
prefixed by fd00:: must not be rewritten other than maybe decrementing 
the HopLimit.

(in similar way that it's written that a link-local address can't
go out of a link).

Alex

Le 04/03/2013 13:20, Liubing (Leo) a écrit :
> Hi, Dear all
>
> (Note: Thanks for your comments, those would help the authors a lot.
> I split and summarize some topics from the discussion, for ease of
> further discussion, hope we can make some consensus. Any specific
> discussion please going to the relevant thread, many thanks.)
>
> considering it because we want to get independence address space,
> then coming the compare of NPTv6 vs PI. (Please correct me if I
> mistakenly understood it)
>
> we mainly have two views: A: ULA+NPTv6 should be "Not recommended" in
> this document. Since we need to promote E2E transparence in IPv6.
> NPTv6 broke the transparence and made more overall cost by adjust the
> network/applications to fit the NAT environment. Contrastively,
> acquiring a PI would not cost too much, and easy to deploy with BGP.
> B: "Not recommended" is way too much, we need fairly stating the pros
> and cons in the document. Since NPTv6 is a reasonable requirement of
> the real end-users. Configuring BGP for PI would not feet all the
> users, especially the small enterprises and home users. And needs no
> cost on RIR fees. Moreover, no limited PI might potentially cause
> serious BGP4 scaling issue, considering the multihoming requirement
> in IPv6 might explode.
>
> Cheers, Bing