Subject: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

From: "Howard, Lee" <[email-masked]>
Date: Mon, 2 Nov 2015 09:17:04 +0000

This document hasn¹t had any revisions or discussion in a while.
Is there anyone interested in working on it?

If we do not hear any interest, we will abandon this draft.

Thanks,
Lee

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 2 Nov 2015 18:58:07 +0900

Hello,

I would like to continue working on this draft.

I am not sure what is needed to continue working on this draft?  Is it
ready to go as is?

The ULAs I consider are (1) in the core of enterprise PA+ULA network
slowly migrating to IPv6 and (2) in vehicles at manufacturing time.

In an enterprise network, I wonder whether ULAs coexist well with IPv4
on a same VLAN, or must they be each on its own VLAN?  Such as to leave
IPv4 continue exist well.  I think a recommendation on this is very
valuable, at least to me.

Also, I wonder whether simply adding ULAs on interfaces of a well-known
router means that it will automatically turn on NAT66? (or not?)   Will
the packets addressed to them from a PA-part of the enterprise network
be dropped by default?

More generally - what is the precise knob which blocks ULA-addressed
packets from leaking to the Internet?  Is this a matter of a routing
protocol knob, like e.g. BGP having a definition of an area around ULAs?
  Or is it a matter of on/off knob which allows/disallows reaching a ULA
in the network attached to a particular interface?  Or does it only
depend of a trivial static route being present or absent in the forward
information base?

For ULAs in a vehicle, it is a bit early to describe the problems and
the needed advice, but I speculate there will be a need for this.  We
have several drafts and implementations on this topic.

Alex

Le 02/11/2015 18:17, Howard, Lee a écrit :
> This document hasn¹t had any revisions or discussion in a while. Is
> there anyone interested in working on it?
>
> Thanks, Lee
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or
> subject to copyright belonging to Time Warner Cable. This E-mail is
> intended solely for the use of the individual or entity to which it
> is addressed. If you are not the intended recipient of this E-mail,
> you are hereby notified that any dissemination, distribution,
> copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
>
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 2 Nov 2015 15:50:40 +0000

Hi Dear Alex and all,

Speaking as a co-author.
I wasn't in the v6ops session this afternoon. And I'm sorry for the silence of the draft for a while, but I do wish to continue working on it.

There was indeed lots of controversial discussion on it, but many of them (even most of them) was just not directly regarding to the draft itself (mostly the IPv6 NAT debate). For the draft, we heard few negative comments, but much more positive comments that were in favor of advancing it. Unfortunately, we didn't get the chance to WGLC, and we also didn't get some essential feedback of how to improve it. So the draft was kind of stuck there. No doubt it should be my responsibility to approach it, but the WG's feedback is also very important/helpful for us.

And thanks for Alex' response, you're more than welcome to contribute on this draft. We can have some detailed discussion later to figure out how to make an update.

For people who are in favor of advancing this draft, I expect very much you could state your opinion on this. 
Many thanks to you all.

Best regards,
Bing

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, November 02, 2015 6:58 PM
To: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Hello,

I am not sure what is needed to continue working on this draft?  Is it ready to go as is?

The ULAs I consider are (1) in the core of enterprise PA+ULA network slowly migrating to IPv6 and (2) in vehicles at manufacturing time.

In an enterprise network, I wonder whether ULAs coexist well with IPv4 on a same VLAN, or must they be each on its own VLAN?  Such as to leave
IPv4 continue exist well.  I think a recommendation on this is very valuable, at least to me.

Also, I wonder whether simply adding ULAs on interfaces of a well-known
router means that it will automatically turn on NAT66? (or not?)   Will
the packets addressed to them from a PA-part of the enterprise network be dropped by default?

More generally - what is the precise knob which blocks ULA-addressed packets from leaking to the Internet?  Is this a matter of a routing protocol knob, like e.g. BGP having a definition of an area around ULAs?
  Or is it a matter of on/off knob which allows/disallows reaching a ULA in the network attached to a particular interface?  Or does it only depend of a trivial static route being present or absent in the forward information base?

For ULAs in a vehicle, it is a bit early to describe the problems and the needed advice, but I speculate there will be a need for this.  We have several drafts and implementations on this topic.

Alex

Le 02/11/2015 18:17, Howard, Lee a écrit :
> proprietary information, which is privileged, confidential, or subject 
> to copyright belonging to Time Warner Cable. This E-mail is intended 
> solely for the use of the individual or entity to which it is 
> addressed. If you are not the intended recipient of this E-mail, you 
> are hereby notified that any dissemination, distribution, copying, or 
> action taken in relation to the contents of and attachments to this 
> E-mail is strictly prohibited and may be unlawful. If you have 
> received this E-mail in error, please notify the sender immediately 
> and permanently delete the original and any copy of this E-mail and 
> any printout.
>

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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Mon, 2 Nov 2015 16:02:40 +0000

And pardon for my iteration again: this draft is NOT making any formal recommendations, but some considerations to refer if you're going to use ULAs.

Best regards,
Bing

-----Original Message-----
From: Liubing (Leo) 
Sent: Tuesday, November 03, 2015 12:51 AM
To: 'Alexandre Petrescu'; [email-masked]
Subject: RE: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Hi Dear Alex and all,

Speaking as a co-author.

Best regards,
Bing

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Monday, November 02, 2015 6:58 PM
To: [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

Hello,

Alex

---

From: joel jaeggli <[email-masked]>
Date: Tue, 3 Nov 2015 06:40:36 +0900

On 11/3/15 1:02 AM, Liubing (Leo) wrote:
> And pardon for my iteration again: this draft is NOT making any
> formal recommendations, but some considerations to refer if you're
> going to use ULAs.

Were it completely neutral with respect to advice there would be little
reason for it to exist.

The sense that I got from the last time this was discussed, and perhaps
this call is there may not be stomach to take this forward as the
product of the working group.

> Best regards, Bing
> 
> -----Original Message----- From: Liubing (Leo) Sent: Tuesday,
> November 03, 2015 12:51 AM To: 'Alexandre Petrescu'; [email-masked] 
> Speaking as a co-author. I wasn't in the v6ops session this
> afternoon. And I'm sorry for the silence of the draft for a while,
> but I do wish to continue working on it.
> 
> There was indeed lots of controversial discussion on it, but many of
> them (even most of them) was just not directly regarding to the draft
> itself (mostly the IPv6 NAT debate). For the draft, we heard few
> negative comments, but much more positive comments that were in favor
> of advancing it. Unfortunately, we didn't get the chance to WGLC, and
> we also didn't get some essential feedback of how to improve it. So
> the draft was kind of stuck there. No doubt it should be my
> responsibility to approach it, but the WG's feedback is also very
> important/helpful for us.
> 
> And thanks for Alex' response, you're more than welcome to contribute
> on this draft. We can have some detailed discussion later to figure
> out how to make an update.
> 
> For people who are in favor of advancing this draft, I expect very
> much you could state your opinion on this. Many thanks to you all.
> 
> Best regards, Bing
> 
> 
> -----Original Message----- From: v6ops
> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu Sent:
> Monday, November 02, 2015 6:58 PM To: [email-masked] Subject: Re:
> [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or
> abandon?
> 
> Hello,
> 
> In an enterprise network, I wonder whether ULAs coexist well with
> IPv4 on a same VLAN, or must they be each on its own VLAN?  Such as
> to leave IPv4 continue exist well.  I think a recommendation on this
> is very valuable, at least to me.
> 
> Also, I wonder whether simply adding ULAs on interfaces of a
> well-known router means that it will automatically turn on NAT66? (or
> not?)   Will the packets addressed to them from a PA-part of the
> enterprise network be dropped by default?
> 
> protocol knob, like e.g. BGP having a definition of an area around
> ULAs? Or is it a matter of on/off knob which allows/disallows
> reaching a ULA in the network attached to a particular interface?  Or
> does it only depend of a trivial static route being present or absent
> in the forward information base?
> 
>> This E-mail and any of its attachments may contain Time Warner
>> Cable proprietary information, which is privileged, confidential,
>> or subject to copyright belonging to Time Warner Cable. This E-mail
>> is intended solely for the use of the individual or entity to which
>> it is addressed. If you are not the intended recipient of this
>> E-mail, you are hereby notified that any dissemination,
>> distribution, copying, or action taken in relation to the contents
>> of and attachments to this E-mail is strictly prohibited and may be

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 11:48:43 +1300

> Were it completely neutral with respect to advice there would be little

We have this feature in IPv6. It seems a bit odd that there's nothing
beyond the bare bones in RFC 4193 that talks about it. "Here are the
things you need to think about" seems like useful content to me.

> product of the working group.

Well, there was when the WG adopted it. What I don't think has anything
like consensus is any statement that it's a good or bad choice to use
ULAs.

So I'd like to see this continue, purely as an FYI document.

   Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 2 Nov 2015 17:02:01 -0600

> things you need to think about" seems like useful content to me.

+1 We need a document that discussed the pluses and minuses of ULA, 
there are many misconceptions about them and a lot of the world is 
starting to actually deploy IPv6. ULA needs to be acknowledged as part 
of the IPv6 tool box, and tell people how to use the tool.  Or, we need 
to find the consensus to make it go ULA a way.

> So I'd like to see this continue, purely as an FYI document.

Yes, Please

-- 
================================================
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: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 2 Nov 2015 23:37:36 +0000

> On Nov 3, 2015, at 8:02 AM, David Farmer <[email-masked]> wrote:
> 
> +1 We need a document that discussed the pluses and minuses of ULA, there are many misconceptions about them and a lot of the world is starting to actually deploy IPv6. ULA needs to be acknowledged as part of the IPv6 tool box, and tell people how to use the tool. Or, we need to find the consensus to make it go ULA a way.

</chair>

Concur. The confusion actually showed up in the discussion of "Design Choices" yesterday, in the statement made in that draft that "RFC 1918 and ULA addresses are different, but are used in the same way."

Both types of addresses can be used in a network that doesn't attach to the Internet, or for purposes (such as modems in a Cable Modem network) that need to be reachable for the purposes of the network itself but specifically not reachable from outside of it. That was what Viktor told me was meant by "used in the same way".

However, RFC 1918 addresses, by and large, are used behind NATs and translated at a border, while that is not a capability widely supported in v6ops. That's an important difference, likely to be an early thought in the mind of an IPv4 operator wanting to mirror his/her IPv4 design in IPv6. It's something that would want to be redesigned.

That difference should be said somewhere, and the issues pro and con discussed.

---

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 3 Nov 2015 09:20:32 +0900

WG,

My input is that we should continue this work.  Given ULAs are already 
in use, having a document which outlines those use cases is, in my mind, 
operationally beneficial.

Perhaps we should be more clear that we would not be recommending the 
use of ULAs, but keep to a unbiased document which outlines how they 
have been used (just a use case discussion).  We can also include 
objective technical points as to the pros/cons related to each use case.

It was also noted in another email (based on WG v6ops discussion 
yesterday), that one such valid example was Cable Modem management IPs 
assigned ULA based addressing.  This is a valid technical use case.

I am willing to help if required on this document.

regards,

Victor K

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 3 Nov 2015 00:49:02 +0000

I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, and
Brian Carpenter. Can I ask each of you to do a review of the current
document, and send comments to the mailing list?  That will give the
authors
and the WG something to work from.

Following that, we can discuss whether we need additional discussion at a
meeting, or WGLC.

Thanks,

Lee

On 11/3/15, 9:20 AM, "Victor Kuarsingh" <[email-masked]> wrote:

>>solely for the use of the individual or entity to which it is addressed.
>>If you are not the intended recipient of this E-mail, you are hereby
>>notified that any dissemination, distribution, copying, or action taken
>>in relation to the contents of and attachments to this E-mail is
>>strictly prohibited and may be unlawful. If you have received this
>>E-mail in error, please notify the sender immediately and permanently
>>delete the original and any copy of this E-mail and any printout.
>>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 3 Nov 2015 04:50:45 +0000

Hi Lee,

Thanks for the note. Their reviews will definitely help.

Btw, if it is possible, can you help to change the draft identity from "draft-ietf-v6ops-ula-usage-recommendations" to " draft-ietf-v6ops-ula-usage-considerations"? I think it is good to align with the draft's title, and more important, it could avoid unnecessary confusion of this work's intent. 
Many thanks for your help.

Best regards,
Bing

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Howard, Lee
Sent: Tuesday, November 03, 2015 9:49 AM
To: Victor Kuarsingh; 'IPv6 Operations'
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

I see interest from Victor Kuarsingh, David Farmer, Alexandre Petrescu, and Brian Carpenter. Can I ask each of you to do a review of the current document, and send comments to the mailing list?  That will give the authors and the WG something to work from.

Following that, we can discuss whether we need additional discussion at a meeting, or WGLC.

Thanks,

Lee

On 11/3/15, 9:20 AM, "Victor Kuarsingh" <[email-masked]> wrote:

>in use, having a document which outlines those use cases is, in my 
>mind, operationally beneficial.
>
>>notified that any dissemination, distribution, copying, or action 
>>taken in relation to the contents of and attachments to this E-mail is

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 13:55:26 +0900

My recollection is that we never got around to publishing this document
because we never managed to agree on what to say in the recommendations. I
think that because the working group does not actually have consensus on
what ULAs should be used for.

Generalizing and handwaving a bit, I think that the major disagreement is
between:

   1. Some proponents of ULAs are suggesting that ULAs (are being | can be
   | should be) used in similar ways to RFC 1918, including using them behind
   NPT66 or in the absence of global addresses, and say that the document
   should list those as use cases.
   2. A fair number of WG members are vehemently opposed to such uses, and
   say that WG documents should explicitly call out such practices as
   harmful. We heard a few of those members at the mike yesterday during the
   discussion of the design choices draft.

For as long as that disagreement exists, it will be hard to make a
recommendation, which is likely to make it hard to get consensus on this
draft. We can go through that disagreement again, but I don't personally
think the outcome will be any different from the one we had last time
around.

I happen to be in camp #2 and would be happy to support this draft if it
said that ULA-only deployments, NPT66 and NAT66 are harmful and should be
avoided. But I'm sure a fair number of people disagree with me.

On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee <[email-masked]> wrote:

> proprietary information, which is privileged, confidential, or subject to
> copyright belonging to Time Warner Cable. This E-mail is intended solely
> for the use of the individual or entity to which it is addressed. If you
> are not the intended recipient of this E-mail, you are hereby notified that
> any dissemination, distribution, copying, or action taken in relation to
> the contents of and attachments to this E-mail is strictly prohibited and
> may be unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any copy of
> this E-mail and any printout.

---

From: Ca By <[email-masked]>
Date: Mon, 2 Nov 2015 21:10:35 -0800

On Monday, November 2, 2015, Lorenzo Colitti <[email-masked]> wrote:

>    1. Some proponents of ULAs are suggesting that ULAs (are being | can
>    be | should be) used in similar ways to RFC 1918, including using them
>    behind NPT66 or in the absence of global addresses, and say that the
>    document should list those as use cases.
>    2. A fair number of WG members are vehemently opposed to such uses,
>    and say that WG documents should explicitly call out such practices as

ULA discussion is the same as the extension header discussion which is the
same as the multi-homing story and dhcpv6.

> On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> On 11/3/15, 9:20 AM, "Victor Kuarsingh" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>> >WG,
>> >
>> >> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 3 Nov 2015 05:33:19 +0000

Hi Lorenzo and all,

Thanks for your feedback.

> For as long as that disagreement exists, it will be hard to make a recommendation,
> which is likely to make it hard to get consensus on this draft.
> We can go through that disagreement again, but I don't personally think
> the outcome will be any different from the one we had last time around.
[Bing] I basically agree with this claim. But that is actually why we changed the document’s purpose from recommendations to considerations, that it only discusses pros and cons of those possible scenarios, and NOT make any formal recommendation.
But maybe because the draft’s short name was not changed accordingly, it has been still “draft-ietf-v6ops-ula-recommendations”, which made people misunderstand the purpose of the draft.

I’ve requested to the chairs to change the draft’s short name to “draft-ietf-v6ops-ula-considerations”, I hope it is doable.

Best regards,
Bing

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, November 03, 2015 1:55 PM
To: Howard, Lee
Cc: IPv6 Operations
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

My recollection is that we never got around to publishing this document because we never managed to agree on what to say in the recommendations. I think that because the working group does not actually have consensus on what ULAs should be used for.

Generalizing and handwaving a bit, I think that the major disagreement is between:

  1.  Some proponents of ULAs are suggesting that ULAs (are being | can be | should be) used in similar ways to RFC 1918, including using them behind NPT66 or in the absence of global addresses, and say that the document should list those as use cases.
  2.  A fair number of WG members are vehemently opposed to such uses, and say that WG documents should explicitly call out such practices as harmful. We heard a few of those members at the mike yesterday during the discussion of the design choices draft.
For as long as that disagreement exists, it will be hard to make a recommendation, which is likely to make it hard to get consensus on this draft. We can go through that disagreement again, but I don't personally think the outcome will be any different from the one we had last time around.

I happen to be in camp #2 and would be happy to support this draft if it said that ULA-only deployments, NPT66 and NAT66 are harmful and should be avoided. But I'm sure a fair number of people disagree with me.

On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Lee

On 11/3/15, 9:20 AM, "Victor Kuarsingh" <[email-masked]<mailto:[email-masked]>> wrote:

>> [email-masked]<mailto:[email-masked]>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Nov 2015 15:00:02 +0900

On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) <[email-masked]>
wrote:

> [Bing] I basically agree with this claim. But that is actually why we
> changed the document’s purpose from recommendations to considerations, that
> it only discusses pros and cons of those possible scenarios, and NOT make
> any formal recommendation.
>

>From the discussion of the deployment considerations draft in the v6ops
session yesterday, several WG members (I remember at least James Woodyatt,
Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough to
list these deployment models with their pros and cons. Instead, these
deployment models should be listed separately as "deployment models that
are considered harmful".

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Nov 2015 17:17:23 +1100

In message <[email-masked]>
>    discussion of the design choices draft.

A lot of this is to do with how addresses are provisioned.  If they
are provising manually (PA or PI) then you can get away without ULA
as your internal addressing is not going to evaperate on you when
you become disconnected.

If your addresses are provisioned automatically then ULA is *critical*
to providing internal stability when the PA prefix goes away.  No,
we should not be encouraging ignoring lease times.

We should also demonstrate that ULA in conjuction with other GUA
is not harmful.  One way to do that would be generate a ULA prefix
in BA and only provide DNS using addresses from the the ULA prefix.
Even better would be to get a second GUA prefix and migrate the
network from one to the other over the course of the week.  Bring
up the second GUA on Tuesday and withdraw the first prefix on
Thursday.

Mark

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

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 3 Nov 2015 06:18:45 +0000

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 3, 2015 at 2:00 AM
To: "Liubing (Leo)" <[email-masked]<mailto:[email-masked]>>
Cc: Lee Howard <[email-masked]<mailto:[email-masked]>>, 'IPv6 Operations' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) <[email-masked]<mailto:[email-masked]>> wrote:
[Bing] I basically agree with this claim. But that is actually why we changed the document's purpose from recommendations to considerations, that it only discusses pros and cons of those possible scenarios, and NOT make any formal recommendation.

>From the discussion of the deployment considerations draft in the v6ops session yesterday, several WG members (I remember at least James Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed that it is not enough to list these deployment models with their pros and cons. Instead, these deployment models should be listed separately as "deployment models that are considered harmful".

Trying to find a way forward with the document. . .

You specifically want to recommend against ULA plus NPT66 or NAT66, right?
The relevant sections in the current document say (in part):

        Although NPTv6 works differently from

         traditional stateful NAT/NAPT (which is discouraged in
         [RFC5902<https://tools.ietf.org/html/rfc5902>]), it introduces similar additional complexity to
         applications, which may cause applications to break.

         Thus this document does not recommend the use of ULA+NPTv6.

...

        Although NPTv6 is a mechanism that has fewer architectural
      problems than a traditional stateful Network Address Translator in
      an IPv6 environment [RFC6296<https://tools.ietf.org/html/rfc6296>], it still breaks end-to-end
      transparency and hence in general is not recommended by the IETF.

...

There's also a full section called, "
Do Not Treat ULA Equal to RFC1918<https://tools.ietf.org/html/rfc1918>.
"

And so on. It seems pretty clear. Is this language insufficiently strong for you? What words would you use instead?

Thanks,

Lee

---

From: David Farmer <[email-masked]>
Date: Tue, 3 Nov 2015 00:42:17 -0600

On 11/3/15 00:00 , Lorenzo Colitti wrote:
>     [Bing] I basically agree with this claim. But that is actually why
>     we changed the document’s purpose from recommendations to
>     considerations, that it only discusses pros and cons of those
>     possible scenarios, and NOT make any formal recommendation.
>
>
> session yesterday, several WG members (I remember at least James
> Woodyatt, Dave Thaler, Igor Gashinsky, and myself) believed that it is
> not enough to list these deployment models with their pros and cons.
> Instead, these deployment models should be listed separately as
> "deployment models that are considered harmful".

To clarify, are you saying Connected Networks with ULA-Only (NPTv6 & 
ALP) section 4.2.1 deployment models are harmful?

I agree with this, with the caveat we have to acknowledge these exist in 
order to call them harmful.  I've heard in the past that some what them 
removed completely.  I prefer to keep them and call them harmful.

Or are you saying all ULA deployment models are harmful?  If you are 
saying this I need to better understand what you mean and way you think 
this.

Thanks.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 3 Nov 2015 08:33:43 -0500

> On Nov 2, 2015, at 6:02 PM, David Farmer <[email-masked]> wrote:
> 

I strongly support making ULA go away.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 3 Nov 2015 08:37:15 -0500

+1 to everything Lorenzo says below.

> On Nov 2, 2015, at 11:55 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> Some proponents of ULAs are suggesting that ULAs (are being | can be | should be) used in similar ways to RFC 1918, including using them behind NPT66 or in the absence of global addresses, and say that the document should list those as use cases.
> A fair number of WG members are vehemently opposed to such uses, and say that WG documents should explicitly call out such practices as harmful. We heard a few of those members at the mike yesterday during the discussion of the design choices draft.
> On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee <[email-masked] <mailto:[email-masked]>> wrote:
> On 11/3/15, 9:20 AM, "Victor Kuarsingh" <[email-masked] <mailto:[email-masked]>> wrote:
> 
> >WG,
> >
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> >
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Ca By <[email-masked]>
Date: Tue, 3 Nov 2015 05:41:40 -0800

On Tuesday, November 3, 2015, Owen DeLong <[email-masked]> wrote:

>
> > On Nov 2, 2015, at 6:02 PM, David Farmer <[email-masked] <javascript:;>>
> wrote:
> >
> there are many misconceptions about them and a lot of the world is starting
> to actually deploy IPv6. ULA needs to be acknowledged as part of the IPv6
> tool box, and tell people how to use the tool.  Or, we need to find the
> consensus to make it go ULA a way.
>

Disagree.

I doubt consensus can be reached and it is a waste to try our hand at this
again.

I happily use ULAs and will continue doing so. You don't like ULA?  Don't
use them.

CB

> > David Farmer               Email: [email-masked] <javascript:;>
> > [email-masked] <javascript:;>
> [email-masked] <javascript:;>

---

From: Owen DeLong <[email-masked]>
Date: Tue, 3 Nov 2015 08:42:36 -0500

> On Nov 3, 2015, at 1:18 AM, Howard, Lee <[email-masked]> wrote:
> 
> 
> 
> From: Lorenzo Colitti <[email-masked] <mailto:[email-masked]>>
> To: "Liubing (Leo)" <[email-masked] <mailto:[email-masked]>>
> Cc: Lee Howard <[email-masked] <mailto:[email-masked]>>, 'IPv6 Operations' <[email-masked] <mailto:[email-masked]>>
>> On Tue, Nov 3, 2015 at 2:33 PM, Liubing (Leo) <[email-masked] <mailto:[email-masked]>> wrote:
>          [RFC5902 <https://tools.ietf.org/html/rfc5902>]), it introduces similar additional complexity to
> …
>       an IPv6 environment [RFC6296 <https://tools.ietf.org/html/rfc6296>], it still breaks end-to-end
> …
> There’s also a full section called, " Do Not Treat ULA Equal to RFC1918 <https://tools.ietf.org/html/rfc1918>. ”
> 

I won’t presume to speek for Lorenzo, but from my perspective, yes, the language is too weak.

Specifically, “Does not recommend” and “Is not recommended” are too passive. We should be
recommending against them rather than merely standing on the sidelines watching the harm
occur.

Such as “Thus, use of ULA+NPTv6 and/or other address translation mechanisms is generally considered harmful and should be avoided.”

Owen

---

From: David Farmer <[email-masked]>
Date: Tue, 3 Nov 2015 09:11:45 -0600

> I strongly support making ULA go away.

Owen,

If you are serious about wanting ULA to go away please help develop a 
consensus for that by providing real arguments supporting such a 
conclusion.

Thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 4 Nov 2015 08:24:46 +1300

> deployment models should be listed separately as "deployment models that

The problem is that we had this argument before NPTv6 was published, and
the distinctly rough consensus was to publish it as Experimental. There's
not much the current draft can do to push that toothpaste back in the tube.
Equally, there's not much it can do to abolish the existing implementations
of NAT66 and NPTv6.

In terms of the art of the possible, it can describe in more detail the
failure modes caused by ULA+NPTv6, and even perhaps explain why those
failure modes are less serious that the failure modes of GUA+NAT66.

I think a careful explanation of the failure modes is more useful than a
bunch of SHOULD NOTs.

    Brian

---

From: Gert Doering <[email-masked]>
Date: Tue, 3 Nov 2015 21:42:37 +0100

Hi,

> I strongly support making ULA go away.

There is no consensus for that.  As prior speakers said, ULAs are useful.

Gert Doering
        -- Operator
-- 
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 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Nov 2015 08:07:30 +1100

> There is no consensus for that.  As prior speakers said, ULAs are useful.

It'll also discourage IPv6 adoption if they go away.

If people have to pay for IPv6 address space just to use IPv6 they'll
either steal public IPv6 space to use instead, or stick with IPv4 and
RFC1918s.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Nov 2015 10:18:58 +0900

> either steal public IPv6 space to use instead, or stick with IPv4 and
I don't think that's a good argument. I think it's more important to
preserve the architecture and end-to-end than to rush "IPv6" adoption by
deploying it the wrong way. If there are reasons we can't use global
addresses everywhere (e.g., the inability to multihome), then we need to
fix those, and I'd rather we accept a slightly lower adoption rate as the
price of doing it right.

IPv6 adoption seems to be growing just fine at the moment. If NAT is what
you want, use IPv4.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 4 Nov 2015 10:37:43 +0900

On 2015-11-03 1:55 PM, Lorenzo Colitti wrote:
> My recollection is that we never got around to publishing this 
> document because we never managed to agree on what to say in the 
> recommendations. I think that because the working group does not 
> actually have consensus on what ULAs should be used for.
>
>     be | should be) used in similar ways to RFC 1918, including using
>     them behind NPT66 or in the absence of global addresses, and say
>     that the document should list those as use cases.
>
Being a person who brought up one of the cases, I would like to clarify 
that this (used in similar ways to RFC1918) is not an umbrella statement 
(i.e. ULAs are not uniformly a replacement of where RFC1918 addresses 
have been used).  However, there is at least one strong example where 
ULAs are technically suitable in place of where RFC1918 was used - 
(example there was modem management IPs). In this case, ULAs were used 
as a match for the technical requirements of such management needs.  
RFC1918 was also used previously as the closest match for the same 
technical needs, but the selection of ULAs and RFC1918s were made 
independently against a set of technical requirements (not as a 
comparative between address types chosen [ULA/RFC1918] - i.e. they were 
both closes match options for requirements).

Not all uses of ULAs result in a decision to need to use NPT66 / NAT66.

>  1. A fair number of WG members are vehemently opposed to such uses,
>     and say that WG documents should explicitly call out such
>     practices as harmful. We heard a few of those members at the mike
>     yesterday during the discussion of the design choices draft.
>
Given ULAs are already used I think it's important to document those use 
cases and outline the pros/cons of such usage.  For use cases where 
there is data showing harm, that should be noted (based on the practical 
deployment observation/data gathered - and not based on the theory of 
what may occur unless this can be well articulated clearly/technically).
> recommendation, which is likely to make it hard to get consensus on 
> this draft. We can go through that disagreement again, but I don't 
> personally think the outcome will be any different from the one we had 
> last time around.
Hence why I prefer to not name this a recommendation document.  I prefer 
just giving it a title which denotes it as a ULA use case or deployment 
document.  It's useful to know what has been deployed, and if possible 
the drivers of those decisions to better understand the reasoning behind 
such deployments.

>
> I happen to be in camp #2 and would be happy to support this draft if 
> it said that ULA-only deployments, NPT66 and NAT66 are harmful and 
> should be avoided. But I'm sure a fair number of people disagree with me.
This is an interesting one.  technically, NPT66 /NAT66 can be used with 
or without ULAs (although we know the most likely occurrence would 
potentiality be with ULAs - but that's not absolute).  If there is a 
strong set of data which shows this [harm], should that not be 
documented interdependently as a standalone draft/RFC? (with the data 
gathered which shows/describes this harm in technical detail) .

Then any document, including a ULA use case document, can point to that.

regards,

Victor K

> <mailto:[email-masked]>> wrote:
>
>     <mailto:[email-masked]>> wrote:
>
>     >WG,
>     >
>     Cable
>     subject
>     addressed.
>     or subject to copyright belonging to Time Warner Cable. This
>     E-mail is intended solely for the use of the individual or entity
>     to which it is addressed. If you are not the intended recipient of
>     this E-mail, you are hereby notified that any dissemination,
>     of and attachments to this E-mail is strictly prohibited and may
>     be unlawful. If you have received this E-mail in error, please
>     notify the sender immediately and permanently delete the original
>     and any copy of this E-mail and any printout.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Nov 2015 13:47:30 +1100

In message <CAKD1Yr3Qn48eQ1Q4VovCsr_S2+RADRZKzi9qBDoh8G2w6Be+=[email-masked]>
> fix those, and I'd rather we accept a slightly lower adoption rate as the

	ULA + PA is NOT the "wrong way".

	ULA does NOT imply NAT.

	I don't think NAT should be done in IPv6 but that in no way
	indicates that I thing ULA is bad.

	You can misuse PI and NAT that to PA when you can't get your
	ISP to accept the PI.  Do we ban PI because that can happen?

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 4 Nov 2015 04:36:05 +0000

Here¹s the consensus as I currently see it:

1. There is consensus that NAT66 (particularly NAPT) is bad, for exactly
the same reasons given in various NAT44/CGN documents (RFC2993 and
RFC3027, as given in the draft).
2. There is consensus that NPT66 is bad, for some of the reasons give in
various NAT44/CGN documents. It might be slightly less bad than NAT66,
since it has slightly fewer of the problems given in those documents.
3. There is rough consensus on the use of ULAs outside of translation
scenarios, such as in walled garden use cases, and/or in combination with
PA space.

#2 is covered with the words "it introduces similar additional complexity
to applications, which may cause applications to break.² (section 4.2.1)
I would like to see more specifics on what breaks, in order to support a
stronger statement.

#3 is covered in the draft in some detail. Those who disagree with this
consensus need to explain why.

To everyone commenting on this draft, please refer to the document in your
comments. ³This text[Š] should be changed to [Š] because [Š]² is very
helpful. Argument by repetition or decibel is not helpful.

Lee

On 11/4/15, 11:47 AM, "v6ops on behalf of Mark Andrews"
<[email-masked] on behalf of [email-masked]> wrote:

>
>In message
><CAKD1Yr3Qn48eQ1Q4VovCsr_S2+RADRZKzi9qBDoh8G2w6Be+=[email-masked]>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Wed, 4 Nov 2015 05:30:55 +0000

Hi Lee,

Thanks for the summary and the guidance.

> #2 is covered with the words "it introduces similar additional complexity to
> applications, which may cause applications to break.² (section 4.2.1) I would
> like to see more specifics on what breaks, in order to support a stronger
> statement.

Ack. I'll make it in the next version.

Best regards,
Bing

> Sent: Wednesday, November 04, 2015 1:36 PM
> To: Mark Andrews; Lorenzo Colitti
> Cc: v6ops list
> 1. There is consensus that NAT66 (particularly NAPT) is bad, for exactly the
> same reasons given in various NAT44/CGN documents (RFC2993 and RFC3027,
> as given in the draft).
> 2. There is consensus that NPT66 is bad, for some of the reasons give in various
> NAT44/CGN documents. It might be slightly less bad than NAT66, since it has
> slightly fewer of the problems given in those documents.
> 3. There is rough consensus on the use of ULAs outside of translation scenarios,
> such as in walled garden use cases, and/or in combination with PA space.
> 
> #2 is covered with the words "it introduces similar additional complexity to
> applications, which may cause applications to break.² (section 4.2.1) I would
> like to see more specifics on what breaks, in order to support a stronger
> statement.
> 
> comments. ³This text[Š] should be changed to [Š] because [Š]² is very helpful.
> Argument by repetition or decibel is not helpful.
> 
> Lee
> 
> 
> >> > If people have to pay for IPv6 address space just to use IPv6
> >> > they'll either steal public IPv6 space to use instead, or stick
> >> > with IPv4 and RFC1918s.
> >> >
> >>preserve the architecture and end-to-end than to rush "IPv6" adoption
> >>by  deploying it the wrong way. If there are reasons we can't use
> >>global  addresses everywhere (e.g., the inability to multihome), then
> >>we need to  fix those, and I'd rather we accept a slightly lower
> >>adoption rate as the  price of doing it right.
> >
> >I don't think NAT should be done in IPv6 but that in no way indicates
> >that I thing ULA is bad.
> >
> >You can misuse PI and NAT that to PA when you can't get your ISP to
> >accept the PI.  Do we ban PI because that can happen?
> >
> >> IPv6 adoption seems to be growing just fine at the moment. If NAT is
> >>what  you want, use IPv4.
> >--
> >Mark Andrews, ISC
> copyright belonging to Time Warner Cable. This E-mail is intended solely for the
> use of the individual or entity to which it is addressed. If you are not the
> intended recipient of this E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be unlawful. If you
> have received this E-mail in error, please notify the sender immediately and
> permanently delete the original and any copy of this E-mail and any printout.
>

---

From: Philip Matthews <[email-masked]>
Date: Wed, 4 Nov 2015 14:37:24 +0900

Unless there is strong consensus (which I don't think there is), then I suggest that it is better to list the pros and cons of each usage and let people make their own choices, than to just say "Don't do this".  It is very hard in the IETF to get solid consensus on things, and so I suggest we just present the facts and let people draw their own conclusions. 

- Philip

On 2015-11-04, at 13:36 , Howard, Lee wrote:

>>> what

---

From: Jon Mitchell <[email-masked]>
Date: Wed, 4 Nov 2015 02:46:15 -0500

> consensus need to explain why.

Great summary - just wanted to add as an operator my agreement with #3,
I also feel after a thorough re-reading of the draft that it does not
endorse ULA+NAT solutions directly and I'm supportive of having a
document that covers this space.

> helpful. Argument by repetition or decibel is not helpful.

I think the below wording changes might be helpful although I don't
think they will specifically address any concern raised in this thread,
it may help with some of the perceived bias of the draft.

-Jon

Intro - 
replace: "normally are not used on the public Internet"
with: "they are not to be globally routed on the public Internet".

Section 3.2 - rename section title, these addresses are not Globally
Unique - maybe "Low Probability of Non-Uniqueness"

Section 4.2 -
first bullet - replace: "the standard way, this will not be a big problem."
with: "using the standard algorithm, this is extremely improbable."

third bullet - replace entirely with: "Prefix generation: Randomly
generated according to the algorithms defined in [RFC4193].  If there
are some specific reasons that call for manual predictable assignments,
that manipulation should be kept strictly in the Subnet ID and not the
Global ID, as described in Section 3.1 of [RFC4193] to avoid collision."

Section 4.3 -
replace: "and the enterprise wants to provide site-local IPv6 connectivity,
a ULA is the best choice for site-local IPv6 connectivity."
with: "a ULA may be considered for providing local IPv6 connectivity
needs."

Section 5.1 -
2nd paragraph, replace: "But it is not necessary to combine ULAs with
any kind of NAT."
with: "However it is not recommended to combine ULAs (or any other IPv6
address) with any kind of NAT."
Also, scratch last two sentences of paragraph.

Section 5.2 -
2nd paragraph, replace: "and configure ACLs on relevant border routers
to block them out of the scope."
with: "and configure ACLs and appropriate route filters on relevant
border routers to block them from leaving the domain."

---

From: Mark Smith <[email-masked]>
Date: Wed, 4 Nov 2015 20:39:14 +1100

you want, use IPv4.

I'm not advocating ULAs to then be used with IPv6 NAT, I'm advocating its
use for closed networks that are not connected to the Internet, or for use
in parallel with PI or PA space, so that internal network addressing is
completely decoupled from and not dependent on external access and having
to have (and pay) external parties for access space.

There is only one case where I'd accept ULA only addressing that had a
level of access to the Internet, and that is where the ULA addresses are
used to teach a full and application specific proxy or gateway (e.g. a HTTP
proxy). I'd accept that if the user truly wants the complete identities of
the hosts to be hidden from the Internet - the traffic looks like it all
originated from the proxy itself to outside parties.

I think the fundamental use with NATs is they're a half measure - in many
cases they're either not application aware, so they only translate IP
header addresses, or they're not truly acting as a full and complete proxy
for the hosts sitting behind them, such that the hosts aren't truly hidden
from the outside destinations.

Regards,
Mark.

---

From: t.petch <[email-masked]>
Date: Wed, 4 Nov 2015 09:55:37 +0000

----- Original Message -----
From: "Liubing (Leo)" <[email-masked]>
To: "Lorenzo Colitti" <[email-masked]>; "Howard, Lee"
<[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>
Sent: Tuesday, November 03, 2015 5:33 AM
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work
or abandon?

> > For as long as that disagreement exists, it will be hard to make a
recommendation,
> [Bing] I basically agree with this claim. But that is actually why we
changed the document’s purpose from recommendations to considerations,
that it only discusses pros and cons of those possible scenarios, and
NOT make any formal recommendation.
> But maybe because the draft’s short name was not changed accordingly,
it has been still “draft-ietf-v6ops-ula-recommendations”, which made
people misunderstand the purpose of the draft.
>
> I’ve requested to the chairs to change the draft’s short name to
“draft-ietf-v6ops-ula-considerations”, I hope it is doable.

I think that an extraordinarily bad idea.  The draft name is an
identifier, something to tie together the various versions, comments
thereon, Last Calls etc. in the years to come.  Change the identifier -
as some foolish WGs are wont to do - and that  link is broken so it
becomes difficult to see what has gone on previously.  What matters is
what the RFC contains, such as the title and the running footing
thereof, not the identifier we use to tie together the work while
getting there.

Tom Petch

p.s. More generally, I have seen overloading an identifier with
semantics cause many network problems over the years and is always a bad
idea.

>   1.  Some proponents of ULAs are suggesting that ULAs (are being |
can be | should be) used in similar ways to RFC 1918, including using
them behind NPT66 or in the absence of global addresses, and say that
the document should list those as use cases.
and say that WG documents should explicitly call out such practices as
harmful. We heard a few of those members at the mike yesterday during
the discussion of the design choices draft.
it said that ULA-only deployments, NPT66 and NAT66 are harmful and
should be avoided. But I'm sure a fair number of people disagree with
me.
>
> On Tue, Nov 3, 2015 at 9:49 AM, Howard, Lee
<[email-masked]<mailto:[email-masked]>> wrote:
> On 11/3/15, 9:20 AM, "Victor Kuarsingh"
> >in use, having a document which outlines those use cases is, in my
mind,
Cable
subject
addressed.
> >>notified that any dissemination, distribution, copying, or action
taken

------------------------------------------------------------------------
--------

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 11:42:08 +0100

Hi,

> since it has slightly fewer of the problems given in those documents.

I don't think there is consensus on that... otherwise we wouldn't have
published NTP66.

Gert Doering
        -- NetMaster

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 4 Nov 2015 12:26:26 +0000

> On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti <[email-masked]> wrote:
> 
> On Wed, Nov 4, 2015 at 6:07 AM, Mark Smith <[email-masked] <mailto:[email-masked]>> wrote:
> If people have to pay for IPv6 address space just to use IPv6 they'll either steal public IPv6 space to use instead, or stick with IPv4 and RFC1918s.
> 
> I don't think that's a good argument. I think it's more important to preserve the architecture and end-to-end than to rush "IPv6" adoption by deploying it the wrong way. If there are reasons we can't use global addresses everywhere (e.g., the inability to multihome), then we need to fix those, and I'd rather we accept a slightly lower adoption rate as the price of doing it right.
> 
> IPv6 adoption seems to be growing just fine at the moment. If NAT is what you want, use IPv4.

So, in your mind, the only usage of ULA is NAT. I actually think there are other uses, such as for addressing cable modems and the like that don't go through a NAT. Assume we agree that NAT is evil. Is there a reason uses in which an address is excluded from inter-network usage is therefore bad?

---

From: David Farmer <[email-masked]>
Date: Wed, 4 Nov 2015 08:40:18 -0600

> On Nov 4, 2015, at 04:42, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Please don't mistake support for publishing a document as support for a technology.

The only thing I think is worse than NAT66, and the slightly less objectionable NPT66, are a 1000 slightly and subtly different versions of NAT66.  Not publishing a document can ensure we will have those 1000 different versions of NAT66, it will not ensure that NAT66 is not deployed.

I believe our only hope of a world without NAT66 deployed all over the place is to define the beast and explain why we think it is a bad idea.  Until we charter the IEP (the Internet Engineering Police) and/or the IEA (the Internet Engineering Army) the only weapons we have are words and their power to persuade.  

We could try to holding or breath until NAT66 goes away, but all that will lead too is a bunch of passed-out network engineers on the carpet at the IETF Plenary. 

To explain why we think NAT66 is a bad idea, we have to acknowledge it exists.  Just a with IPv4 our failure to define a standard form of NAT, will not prevent the deployment of NAT, it will ensure the deployment of subtly incompatible and worse versions of NAT.  Our only useful way forward is to define NAT66 and explain why we think it is a bad idea.

Thanks.

-- 
===============================================
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: Owen DeLong <[email-masked]>
Date: Wed, 4 Nov 2015 12:01:13 -0300

I actually agree with what David says below. However, I’d like to make sure that EVERYWHERE we document any form of IPv6 NAT, we also document that it is considered harmful.

Owen

> On Nov 4, 2015, at 11:40 AM, David Farmer <[email-masked]> wrote:
> 
>

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 18:06:38 +0100

Hi,

> Please don't mistake support for publishing a document as support for a technology.

Oh, there might not be consensus to *like* NPT66, but there definitely is
no consensus that "it is bad" either.  I, for one, would object.

As do lots of enterprise networks that like to have it in their toolbox.

*Mandating* NAT is bad (IPv4, CGN, DS-Lite, ...) - "having tools" is *good*.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 18:07:11 +0100

Hi,

On Wed, Nov 04, 2015 at 12:01:13PM -0300, Owen DeLong wrote:
> I actually agree with what David says below. However, I???d like to make sure that EVERYWHERE we document any form of IPv6 NAT, we also document that it is considered harmful.

"That some people in IETF consider it harmful"

Please do not speak for me.

Gert

---

From: Owen DeLong <[email-masked]>
Date: Wed, 4 Nov 2015 16:37:44 -0300

> On Nov 4, 2015, at 2:07 PM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Are you really claiming you can make a case that deployment of NAT is not harmful? I’m very skeptical that such a case can be made.

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 20:52:54 +0100

Hi,

On Wed, Nov 04, 2015 at 04:37:44PM -0300, Owen DeLong wrote:
> Are you really claiming you can make a case that deployment of NAT is 
> not harmful? I???m very skeptical that such a case can be made.

Widen your mind :-) - and indeed, I am making this case.  Multiple
different scenarios where NAT is making life much easier (or enabling
a solution at all that might not be otherwise possible).

And none of this is the trivial case of conflicting RFC1918 IP address 
usage in enterprise VPN scenarios.

Or the case of destination NAT used for load-balancing...  (still NAT,
even if not N:1 source NAPT).

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Wed, 4 Nov 2015 17:12:37 -0300

> On Nov 4, 2015, at 4:52 PM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

In IPv6? Such as?

Even in IPv4, each and every one of those cases is actually harmful. It may also come with some  benefits which some people may believe outweigh the harm, but denying that it is also harmful is misguided at best and deceitful at worst.

> usage in enterprise VPN scenarios.

Which doesn’t apply to IPv6. Note that my specific statement was about IPv6 NAT.

> even if not N:1 source NAPT).

Unnecessary in IPv6 and not entirely harmless.

Owen

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Nov 2015 07:14:09 +1100

On 5 Nov 2015 6:53 AM, "Gert Doering" <[email-masked]> wrote:
> > >> I actually agree with what David says below. However, I???d like to
make sure that EVERYWHERE we document any form of IPv6 NAT, we also
document that it is considered harmful.
> a solution at all that might not be otherwise possible).

Are people who use it "successfully" aware of the limitations it imposes
i.e. those described in RFC2993?

Something working doesn't mean it works well, or that the costs imposed by
it are immediately obvious or possibly ever obvious if they're externalised
costs, that you may indirectly pay (e.g., periodic "bubble" packets to keep
NAT sessions alive so that VoIP handsets can receive calls when they're
behind a NAT)

> even if not N:1 source NAPT).

Breaks PMTUD because a unicast address isn't being used as a unicast
address - an address to identify a unique destination/host.

The PMTUD problems would go away if the LB terminated the TCP connections -
which has also then restored the unicast address = unique (single)
destination property.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 21:17:34 +0100

Hi,

> i.e. those described in RFC2993?

Yes.  The most important limitation in these cases is "make sure your
documentation is precise".

I said before that *imposing* NAT on people is bad, but taking away
tools is also bad.  And as such, I oppose the statement that there
would be IETF consensus on "NAT is bad".

In almost all cases, alternative approaches could be used (like, in
the loadbalancing case, use a reverse proxy, add extra http headers
so the real server can know the real client IP, etc) - but in many
cases, these are more expensive or require cooperation by other parties
that have no interest.  Tool.  Useful.  By conscenting adults.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 21:19:01 +0100

Hi,

> Unnecessary in IPv6 and not entirely harmless.

Lots of different ways to build loadbalancer exist, and they all have
benefits and drawbacks.  Otherwise people would not use all the variants.

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Wed, 4 Nov 2015 17:41:35 -0300

> On Nov 4, 2015, at 5:19 PM, Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

So I notice you completely left out all of the other responses. Does that mean that we have consensus that NAT in IPv6 is actually harmful?

Even in the load balancer case, you’ve admitted there are drawbacks.

Owen

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 21:56:41 +0100

Hi,

> So I notice you completely left out all of the other responses. Does that mean that we have consensus that NAT in IPv6 is actually harmful?

No.  It is a tool, which has uses, and drawbacks.  Not having the tool
available would be harmful.

WE HAVE NO CONSENSUS THAT NAT IS HARMFUL.  For those that are a bit slow.

> Even in the load balancer case, you???ve admitted there are drawbacks.

Sure.  Breathing has drawbacks.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 4 Nov 2015 21:04:55 +0000

On 04/11/2015 15:01, Owen DeLong wrote:
> I actually agree with what David says below. However, I’d like to make
> sure that EVERYWHERE we document any form of IPv6 NAT, we also document
> that it is considered harmful.

Just then they came in sight of thirty or forty windmills that rise from
that plain. And no sooner did Don Quixote see them that he said to his
squire, "Fortune is guiding our affairs better than we ourselves could have
wished. Do you see over yonder, friend Sancho, thirty or forty hulking
giants? I intend to do battle with them and slay them. With their spoils we
shall begin to be rich for this is a righteous war and the removal of so
foul a brood from off the face of the earth is a service God will bless."

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 5 Nov 2015 08:43:13 +1100

On 5 Nov 2015 07:57, "Gert Doering" <[email-masked]> wrote:
> > So I notice you completely left out all of the other responses. Does
that mean that we have consensus that NAT in IPv6 is actually harmful?
> WE HAVE NO CONSENSUS THAT NAT IS HARMFUL.  For those that are a bit slow.

Next time you're about to resort to insults, don't.

Your not going to convince Owen and I by calling us idiots.

(And you'll also have to overcome my 20 years of seeing and encountering
NAT limitations over and over again, including the very first time a
customer of mine wanted to use it in 1995 because one of the earliest NAT
implementations couldn't NAT NetBIOS).

---

From: Gert Doering <[email-masked]>
Date: Wed, 4 Nov 2015 22:44:46 +0100

Hi,

> Your not going to convince Owen and I by calling us idiots.

There is no way to convince Owen and you.  What I'm doing here is to
state for the record that there is no consensus.

Gert Doering
        -- NetMaster

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 5 Nov 2015 07:44:28 +0900

Sent from my iPhone

> On Nov 4, 2015, at 21:26, Fred Baker (fred) <[email-masked]> wrote:
> 
> 
> So, in your mind, the only usage of ULA is NAT. I actually think there are other uses, such as for addressing cable modems and the like that don't go through a NAT.

Stable interior only prefixes in the absensence of pi.

Numbering of temporarily isolated networks sandboxes and so on. Link local only goes so far.

> Assume we agree that NAT is evil. Is there a reason uses in which an address is excluded from inter-network usage is therefore bad?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2015 11:45:10 +1300

Going back a bit:

> I don't think there is consensus on that... otherwise we wouldn't have

There was rough consensus to publish NPTv6 as experimental. There was
clearly no consensus to publish it on the standards track.

But anyway: that is history now. IMHO we need text in the current draft
that not only states that ULA+NPTv6 has drawbacks, but actually summarises
them. And states that the IETF has not defined NAT66, and summarises the
additional drawbacks that ULA+NAT66 would bring. I believe that most of the
information about the drawbacks is already documented, in RFC 6296 itself,
RFC 4864, RFC 2993 and maybe elsewehere. There is a good set of
references in RFC 6296.

However, I don't think any of those references discusses the load balancer
drawback. It is mentioned in a different context at
http://tools.ietf.org/html/rfc7098#page-10. As it happens, that describes
a case where NPTv6 is definitely less harmful than NAPT. (When we say
NAT66, are we referring to NAT66 or NAPT66?)

Bing already indicated that the authors will add more or less what I suggest.
That's really the only change needed, IMHO. I'll save a detailed re-review
for the next draft.

   Brian

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 4 Nov 2015 23:32:21 +0000

Observation: the use of the words ³bad² and ³harmful² do not advance the
cause of a clearer document or finding consensus. I apologize for using
such words.

We have at least two documents describing limitations of NAT, which are
cited in this draft. I think we have consensus on the way we say it, so
unless you want to propose new words for this document, stop talking about
NAT.

In order to advance this document, we need words describing why NPT66 is
not as good as native IPv6. The only documentation of that at present is
the NPT66 RFC itself, RFC6296 (especially Section 5).

I don¹t recall any arguments against the use of ULA when there is no NAT
or NPT being used. Please send text reminding me.

Lee

On 11/5/15, 5:41 AM, "v6ops on behalf of Owen DeLong"
<[email-masked] on behalf of [email-masked]> wrote:

>So I notice you completely left out all of the other responses. Does that
>mean that we have consensus that NAT in IPv6 is actually harmful?
>
>Even in the load balancer case, you¹ve admitted there are drawbacks.
>
>Owen
>

---

From: "Howard, Lee" <[email-masked]>
Date: Wed, 4 Nov 2015 23:33:47 +0000

From: v6ops <[email-masked]<mailto:[email-masked]>> on behalf of Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, November 3, 2015 at 9:18 PM
To: Mark Smith <[email-masked]<mailto:[email-masked]>>
Cc: 'IPv6 Operations' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?
 I'd rather we accept a slightly lower adoption rate as the price of doing it right.

Speaking only as an operator, I disagree.
Operators need IPv6 to be universally adopted before they run out of IPv4 addresses. Otherwise, they will have to deploy some form of NAT.
Your argument says that any of the set of NAT444 or address family transition service is preferable to ULA (which, especially in the absence of NAT66/NPT66, doesn't make sense to me(.

It is growing, and it's good to see. It is not growing fast enough, or we wouldn't need transition technologies or CGN.

Lee

---

From: Owen DeLong <[email-masked]>
Date: Wed, 4 Nov 2015 22:01:04 -0300

Gert,

There are a number of tools which are harmful and yet still in wide use for a variety of reasons.

I’m not saying NAT is prohibited.
I’m not saying the IETF should say NAT is bad. (NAT is bad, but the IETF probably shouldn’t say so.).

Nonetheless, even in the cases where NAT is the best solution, it remains harmful. At this point, I believe
that to be documented fact rather than opinion.

Think of it in the same way that, for example, aripiprazole is necessary and often the only choice of drug that works for some people’s particular conditions, yet almost universally does cause some harm in the process. Usually the benefit outweighs the drawbacks or it isn’t prescribed. Nonetheless, it is considered “harmful”.

So it’s interesting that while you yourself have acquiesced that NAT causes harm, you still claim not to agree that NAT is harmful.

Owen

> On Nov 4, 2015, at 6:43 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> On 5 Nov 2015 07:57, "Gert Doering" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Hi,
> >
> (And you'll also have to overcome my 20 years of seeing and encountering NAT limitations over and over again, including the very first time a customer of mine wanted to use it in 1995 because one of the earliest NAT implementations couldn't NAT NetBIOS).
>

---

From: "Liubing (Leo)" <[email-masked]>
Date: Thu, 5 Nov 2015 01:05:01 +0000

Hi Brian,

Thanks for your constructive suggestions. And I expect your detailed review of the future version. Thank you in advance.

B.R.
Bing

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, November 05, 2015 7:45 AM
> To: Gert Doering; Howard, Lee
> Cc: v6ops list
> >> 2. There is consensus that NPT66 is bad, for some of the reasons give
> >> in various NAT44/CGN documents. It might be slightly less bad than
> >> NAT66, since it has slightly fewer of the problems given in those documents.
> >
> But anyway: that is history now. IMHO we need text in the current draft that
> not only states that ULA+NPTv6 has drawbacks, but actually summarises them.
> And states that the IETF has not defined NAT66, and summarises the additional
> drawbacks that ULA+NAT66 would bring. I believe that most of the information
> about the drawbacks is already documented, in RFC 6296 itself, RFC 4864, RFC
> 2993 and maybe elsewehere. There is a good set of references in RFC 6296.
> 
> http://tools.ietf.org/html/rfc7098#page-10. As it happens, that describes a
> case where NPTv6 is definitely less harmful than NAPT. (When we say NAT66,
> are we referring to NAT66 or NAPT66?)
> 
> That's really the only change needed, IMHO. I'll save a detailed re-review for
> the next draft.
> 
>    Brian
>

---

From: Owen DeLong <[email-masked]>
Date: Wed, 4 Nov 2015 22:02:25 -0300

> On Nov 4, 2015, at 7:44 PM, Joel Jaeggli <[email-masked]> wrote:
> 
> 
> 
> Sent from my iPhone
> 
> On Nov 4, 2015, at 21:26, Fred Baker (fred) <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> 
>>> On Nov 4, 2015, at 10:18 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
>>> 

True, but there’s no advantage to using ULA for this over GUA if you have GUA available.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 5 Nov 2015 10:10:50 +0900

Le 05/11/2015 05:14, Mark Smith a écrit :
[...]

> i.e. those described in RFC2993?

Which makes think the RFC 2993's section on IPv6 may need update given 
that now IPv6 NATs do exist, that 6to4 is deprecated, that ULAs 
substituted site-locals, etc.

Alex

>
> Something working doesn't mean it works well, or that the costs imposed
> by it are immediately obvious or possibly ever obvious if they're
> externalised costs, that you may indirectly pay (e.g., periodic "bubble"
> packets to keep NAT sessions alive so that VoIP handsets can receive
> calls when they're behind a NAT)
>
> The PMTUD problems would go away if the LB terminated the TCP
> connections - which has also then restored the unicast address = unique
> (single) destination property.
>
> Regards,
> Mark.
>
>  > Gert Doering
>  >         -- NetMaster
>  > --

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 5 Nov 2015 10:23:34 +0900

> True, but there’s no advantage to using ULA for this over GUA if you 

That's not necessarily true.  In past experience, we had a need to nail 
up temporary networks quickly to test functions, and getting GUA was 
going to take time (based on procedures) and ULA was available right 
away.  Given the testing was related to network impairments, having 
immediate access to addressing was beneficial. So GUA was available, but 
not in the time frame needed.

There is also an operational benefit to using ULAs for some functions 
where the hosts do not need inter-domain reachability. The security 
perimeter and related policy can be much more stable (requiring less 
changes as you add space) depending on what GUA space you have access to 
(as it may not be contiguous).  Also, from an front line ops 
perspective, there is also a very clear visual discriminator that comes 
in handy (vs. GUAs which can be hard to differentiate as to which are 
for interior-only functions vs. inter-domain functions.).

regards,

Victor K

>>
>>> Assume we agree that NAT is evil. Is there a reason uses in which an 
>>> address is excluded from inter-network usage is therefore bad?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2015 14:31:18 +1300

On 05/11/2015 14:10, Alexandre Petrescu wrote:

...
> Which makes think the RFC 2993's section on IPv6 may need update given that now IPv6 NATs do exist, that 6to4 is deprecated,
> that ULAs substituted site-locals, etc.

I can testify that 6to4 had not been invented when RFC 2993 was written,
so its deprecation is hardly relevant.

   Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 5 Nov 2015 10:38:56 +0900

On 2015-11-05 7:45 AM, Brian E Carpenter wrote:
> But anyway: that is history now. IMHO we need text in the current 
> draft that not only states that ULA+NPTv6 has drawbacks, but actually 
> summarises them. And states that the IETF has not defined NAT66, and 
> summarises the additional drawbacks that ULA+NAT66 would bring. I 
> believe that most of the information about the drawbacks is already 
> documented, in RFC 6296 itself, RFC 4864, RFC 2993 and maybe 
> elsewehere. There is a good set of references in RFC 6296. However, I 
> don't think any of those references discusses the load balancer 
> http://tools.ietf.org/html/rfc7098#page-10. As it happens, that 
> describes a case where NPTv6 is definitely less harmful than NAPT. 
> (When we say NAT66, are we referring to NAT66 or NAPT66?) 
These are good points, however,

  how do we constructively provide objective information as to the 
technical drawbacks of a function which is not fully defined (re: 
NAT66).  I heard it noted this week that folks needed to differentiate 
between NAT66 and NAPT66 (as an example) at mics to then provide further 
input to the discussion (in v6ops).  This lack of definition (of NAT66 
and/or its variants) makes it difficult to make a full constructive 
argument (as we will need to keep repeating/expressing what we mean by 
NAT66 in each instance , or we just hope everyone has the same reference 
points - which is unlikely)

I can see how we can make the points against NPT66 since we at least 
have that documented.

regards,

Victor K

> Bing already indicated that the authors will add more or less what I 
> suggest. That's really the only change needed, IMHO. I'll save a 
> detailed re-review for the next draft. Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Nov 2015 15:23:35 +1300

Yes, Alexandre has caught me out. I had completely overlooked that
RFC 2993 has a stray reference to 6to4 as work in progress.
However, it's beside the main point of that particular paragraph
in RFC 2993, which really says that NAPT44 can be useful to allow
legacy IPv4 to coexist with IPv6. That has happened, quite regardless
of 6to4.

Looking at the change made when the 6to4 reference was added:
(https://tools.ietf.org/rfcdiff?url2=draft-iab-nat-implications-06.txt)
I suspect that our thinking was a bit confused at the time. But
I don't think it really needs an updated RFC from the IAB.

Regards
   Brian

On 05/11/2015 14:48, Alexandre Petrescu wrote:
> 
> 
> Le 05/11/2015 10:31, Brian E Carpenter a écrit :
> So they presciently used the word "6to4"...
> 
> Alex
> 
>>
>>     Brian
>>
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Nov 2015 17:13:34 +0900

On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee <[email-masked]> wrote:

> And so on. It seems pretty clear. Is this language insufficiently strong
> for you? What words would you use instead?
>

I would prefer if we used phrasing of the form "<xxx> is considered
harmful" or "<xxx> is not recommended".

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 5 Nov 2015 09:05:03 +0000

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: Thursday, November 5, 2015 at 4:13 AM
To: Lee Howard <[email-masked]<mailto:[email-masked]>>
Cc: "Liubing (Leo)" <[email-masked]<mailto:[email-masked]>>, 'IPv6 Operations' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee <[email-masked]<mailto:[email-masked]>> wrote:
And so on. It seems pretty clear. Is this language insufficiently strong for you? What words would you use instead?

I would prefer if we used phrasing of the form "<xxx> is considered harmful" or "<xxx> is not recommended".

You deleted a lot of context, including the text:

"(NPT66) is not recommended by the IETF."

Can we consider your concern addressed?

Lee

---

From: David Farmer <[email-masked]>
Date: Thu, 5 Nov 2015 12:17:02 -0600

On 11/5/15 03:05 , Howard, Lee wrote:
>         And so on. It seems pretty clear. Is this language
>         insufficiently strong for you? What words would you use instead?
>
>
> “(NPT66) is not recommended by the IETF.”

For the most part I like this.  It takes emotional trigger words out of 
it.  However, I would suggest focusing on Internet connectivity and away 
from all potential uses of NAT.  I believe the primary objection to NAT 
is in a general-purpose Internet context, and other more specialized 
uses might be less objectionable to some.  So something like;

    Use of NPT66, and NAT66 as a general concept, are NOT RECOMMENDED in
    the context of general-purpose Internet connectivity.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2015 08:44:23 +1300

On 06/11/2015 07:17, David Farmer wrote:
> For the most part I like this.  It takes emotional trigger words out of it.  However, I would suggest focusing on Internet
> connectivity and away from all potential uses of NAT.  I believe the primary objection to NAT is in a general-purpose Internet
> context, and other more specialized uses might be less objectionable to some.  So something like;
> 

If we're not writing a BCP, we don't need to do it that way, even though it's
factually true. We can simply say things like

NPTv6 is an experimental technology and network address translation for
IPv6 has not been defined by the IETF. Therefore, they do not have a role
to play in general-purpose Internet connectivity.

Outside our little world, the effect is much the same.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Nov 2015 07:14:33 +1100

On 6 November 2015 at 05:17, David Farmer <[email-masked]> wrote:
> For the most part I like this.  It takes emotional trigger words out of it.
> However, I would suggest focusing on Internet connectivity and away from all
> potential uses of NAT.  I believe the primary objection to NAT is in a
> general-purpose Internet context, and other more specialized uses might be
> less objectionable to some.  So something like;
>

I think the above simpler statement is better, this text implies that
there are no consequences (to anything) of using address translation
outside of an Internet context. There clearly are many technical
consequences, as have been documented in many RFCs, and we shouldn't
effectively be dismissing them by omission or implying they only
matter in certain contexts.

 (I think it would be better describe the thing being recommended
against being "address translation", rather than specific methods.
Mentioning specific address translation technologies implies that
other later ones may be consequence free.),

As far as I can see, only one person here is strongly objecting to
stating address translation is harmful. One person strongly objecting
doesn't mean that consensus hasn't been reached by the IETF (see
RFC7282 - "On Consensus and Humming in the IETF")

I think there are two types of people we need to address:

- people who don't really care as much or have as much time for the
details and to know the various benefits and drawbacks. They just want
to follow a guide as to what will work best, making minimal value
judgements

- people who are willing to make value judgements and consider various
trade-offs. They will be interested to know, research and consider the
topic.

The first category of people will mostly accept a simple statement
recommending against or for something, with their next question being,
"so what do I do instead." (e.g. RFC4864 instead of address
translation).

The second category will put weight on what is being stated in the
recommendation, however they themselves will want to have a much
deeper understanding of the why the recommendation has been made, by
researching and reading supporting references. In some ways they're
effectively making the decision their own. They may even decide
against the recommendation. In either case, they'd be able to defend
the decision themselves if they're challenged on it.

(With many people being only being used to private addressing and NAT
in IPv4, I suspect there will be a few people pushed into the second
category who are normally first category people.)

Since this ID is an advice document, I'd like to see content that
would satisfy both types of people. So perhaps:

(a) a simple statement recommending against address translation
(b) a paragraph or so as to mentioning the sorts of consequences it
has, and also that the increasing use of encryption will prevent the
ability to address translate addresses in payloads
(c) references to RFCs that discuss the consequences of address
translation, either specific to IPv6 (i.e., the Implications for
Applications section in the NPT66 RFC), or more general ones e.g.,
RFC2993, RFC1627, with mention that although they were written about
IPv4, some or all of the implications will also apply to IPv6 address
translation.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Thu, 5 Nov 2015 21:25:16 +0100

Hi,

> RFC7282 - "On Consensus and Humming in the IETF")

Oh, and 3 persons repeatedly stating something when everyone else has
given up and gone home for the evening make consensus?

Please.  Quite a number of "real world" operators have spoken in favour
of having NAT-alikes in their tool box here in the past (and were usually
being yelled at for being so stupid and having no idea about True Ivory
Tower Networking).  So, yes, seems they all have gone away now - but
that does not make their prior statements less valid.

Gert Doering
        -- NetMaster

---

From: "Howard, Lee" <[email-masked]>
Date: Thu, 5 Nov 2015 21:56:14 +0000

Would somebody please explain to me exactly what NPT66 breaks?
Preferably in a way that could be included in a draft.

Thanks,
Lee

---

From: Igor Gashinsky <[email-masked]>
Date: Thu, 5 Nov 2015 04:47:34 -0500 (EST)

On Thu, 5 Nov 2015, Howard, Lee wrote:

:: On Tue, Nov 3, 2015 at 3:18 PM, Howard, Lee <[email-masked]<mailto:[email-masked]>> wrote:
:: And so on. It seems pretty clear. Is this language insufficiently strong for you? What words would you use instead?
:: 
:: I would prefer if we used phrasing of the form "<xxx> is considered harmful" or "<xxx> is not recommended".
:: 
:: You deleted a lot of context, including the text:
:: 
:: "(NPT66) is not recommended by the IETF."
:: 
:: Can we consider your concern addressed?

That makes it sound like IETF is not "endorsing" NPT66, as opposed to 
actively recommending that people don't use it. I'm with Lorenzo here -  
I would prefer very strong language in the form of "deployment of NPT66 is 
concidered harmful" or "we strongly recommend against the use of NPT66".

Thanks!
-igor

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 6 Nov 2015 12:52:46 +1300

That's in the NPTv6 RFC already, I think. Because we certainly had this
whole conversation prior to reaching rough consensus to publish NPTv6
as Experimental.

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Nov 2015 09:20:56 +0900

It breaks any application that requires that the application know its
source address. Examples are SIP, FTP, audio/video chat, etc.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 6 Nov 2015 09:25:13 +0900

> whole conversation prior to reaching rough consensus to publish NPTv6

https://tools.ietf.org/html/rfc6296#section-5

Is quite a  reasonable citation.

It is resonable to suppose that the deployer of nptv6 exposes the cost
associated with the traversal to application developers who in turn
externalize that in small ways (additional complexity, lost opportunity,
actual cost) to the users of the ntpv6 device.

In ipv4 this cost is endogenous due to scarcity.

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 6 Nov 2015 01:31:02 +0000

>whole conversation prior to reaching rough consensus to publish NPTv6

Yes, exactly, which is why I have a hard time understanding what new
information has arisen that makes us not recommend it. But fine, let¹s
cite the considerations section from the original document as the problem.

Current text:
Although NPTv6 works differently from
         traditional stateful NAT/NAPT (which is discouraged in
         [RFC5902 <http://tools.ietf.org/html/rfc5902>]), it introduces
similar additional complexity to
         applications, which may cause applications to break.

Proposed text:
... it does have significant implications to applications, as documented
in [RFC6296] Section 5, which may  cause some applications to break.

Current text:
      Although NPTv6 is a mechanism that has fewer architectural
      problems than a traditional stateful Network Address Translator in
      an IPv6 environment [RFC6296 <http://tools.ietf.org/html/rfc6296>],
it still breaks end-to-end
      transparency and hence in general is not recommended by the IETF.

Proposed text:

... and hence is not recommended.

Are we there yet?

Lee

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 6 Nov 2015 02:09:06 +0000

That would be https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations; it just expired and therefore might not show up through the usual search mechanisms.

> On Nov 3, 2015, at 9:49 AM, Howard, Lee <[email-masked]> wrote:
>

---

From: James Woodyatt <[email-masked]>
Date: Fri, 6 Nov 2015 11:32:43 +0900

> Preferably in a way that could be included in a draft.

Short answer: address referral is broken by NPTv6, which leads to unilateral self-address fixing (UNSAF) services, which are themselves fundamentally broken (see sections 2 and 3 of RFC 3424).

—james.

---

From: [email-masked]
Date: Fri, 06 Nov 2015 06:31:06 +0100 (CET)

> concidered harmful" or "we strongly recommend against the use of NPT66".

Okay, one more operator then. I want to have NPT66 (and ULA) available
in the toolbox.

Steinar Haug, AS 2116

---

From: Mark Smith <[email-masked]>
Date: Fri, 6 Nov 2015 17:51:11 +1100

> Okay, one more operator then. I want to have NPT66 (and ULA) available

Why would a recommendation against it prevent you using it on your network
if you wanted to? How is the IETF recommending against it stopping you from
using it?

A recommendation not to do something is for people who fundamentally don't
know better.

If you know better, meaning you understand the costs and consequences, and
the owners of the network are willing to pay those costs and deal with the
consequences, then there is nothing stopping you. Nobody is and can force
you to follow the recommendation in your own network.

(Having directly and indirectly paid those costs and having dealt with the
consequences of NAT in IPv4, I don't want to pay them in IPv6, and I don't
think those who don't know better should inadvertently have to end up
paying them either. I personally see the lack of reason for NAT, due to
plenty of addresses, and mechanisms to help smoothly renumber, to be the
most important properly if IPv6.)

Regards,
Mark.

---

From: [email-masked]
Date: Fri, 06 Nov 2015 08:14:25 +0100 (CET)

> if you wanted to? How is the IETF recommending against it stopping you from

I would of course carefully consider the alternatives. But you're right
that it probably wouldn't stop me if I concluded that NPT66 was the best
solution.

> A recommendation not to do something is for people who fundamentally don't

Which leaves the people who would like to be provider independent in a
slightly difficult situation. Recommend /48 PI for everybody? Still too
difficult to acquire for many companies, and with significant scaling
problems if enough people start using it. NPT66? "Harmful", as some
people here would like the documents to say.

Steinar Haug, AS 2116

---

From: Gert Doering <[email-masked]>
Date: Fri, 6 Nov 2015 08:26:16 +0100

Hi,

> Thus this document does not recommend the use of ULA+NPTv6.

This I can perfectly agree to - it's a different message ("understand 
well what you do if you insist on going there"), and clear enough.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 6 Nov 2015 10:08:01 +0000

> source address. Examples are SIP, FTP, audio/video chat, etc.
your argument is the wrong way around: some protocols deliberately
introduce layering violations by demanding that transport identifier
information is encoded at the application layer.  Transport identifier
translation merely shows up this brokenness.  The brokenness is not with
the translation mechanism but with the higher level protocols.

You could argue that this is an angels-on-the-head-of-a-pin style argument
and that it doesn't matter which bit is broken because at the end of the
day, breakage happens and users get hurt.  The point is that is IETF
working groups like to get up on their collective high horses about
identifier translation but apparently don't bat an eyelid when people
create entirely new protocols with glaring layering violations.

I'd happy to see disapproval notices for NPTv6 appearing in this draft if
the IETF first issues explicit recommendations against using SIP, FTP,
audio/video chat and all other protocols which mandate layering violations.

I.e. at least the IETF should be even handed about this and not pretend
that the root cause of the problem is somewhere where in fact it isn't.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 6 Nov 2015 10:15:30 +0000

> well what you do if you insist on going there"), and clear enough.

this is verging on "delenda est carthago" territory.

Nick

---

From: Mark Smith <[email-masked]>
Date: Sat, 7 Nov 2015 12:16:43 +1100

On 6 November 2015 at 21:08, Nick Hilliard <[email-masked]> wrote:
> It breaks any application that requires that the application know its source
> address. Examples are SIP, FTP, audio/video chat, etc.
>
> your argument is the wrong way around: some protocols deliberately introduce
> layering violations by demanding that transport identifier information is
> encoded at the application layer.  Transport identifier translation merely
> shows up this brokenness.  The brokenness is not with the translation
> mechanism but with the higher level protocols.
>
> day, breakage happens and users get hurt.  The point is that is IETF working
> groups like to get up on their collective high horses about identifier
> translation but apparently don't bat an eyelid when people create entirely
> new protocols with glaring layering violations.
>

So this draft is advice about what should and shouldn't be done in the network.

Networks need to aim to best facilitate applications, because
supporting applications is the *sole* reason for networks (a network
without applications has no reason to exist). Network shouldn't be
imposing limitations on applications that don't need to be there,
because it creates a cost and causes cost shifting - the cost of those
network limitations ends up being borne by the applications, as they
then have to implement mechanisms to work around those limitations,
and they will, hence STUN, TURN, UDP or HTTP encapsulation of other
protocols.

We know that some applications use IP addresses as identifiers, and we
should be recommending IPv6 network deployments that best support
applications our networks' customers want to use, not telling them
"don't use that application because it stops me using a type of
device/function in the network I might want to use.". Doing so is
forgetting who's creating the need and reason for network operators
existence.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 7 Nov 2015 18:28:46 +0000

> and they will, hence STUN, TURN, UDP or HTTP encapsulation of other

What you probably mean is:

 - "end users", not "applications"
 - "networks and protocols", not "networks"

If you make those replacements in what you wrote, you end up with something
which is not just more accurate, but also a lot more balanced.

> forgetting who's creating the need and reason for network operators

The relevant warnings, with clear identification about causes and effects,
are already present in rfc6296 and rfc5902.  Both these rfcs are already
referenced in this ID, although I note sadly that 5902 omits any mention of
layering violations by higher level protocols being one of the primary
contributory factors to end-user breakage.

This particular horse has been flogged to death already and there's no need
to flog it any more in this draft.

Nick

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 7 Nov 2015 22:56:20 +0000

On Nov 3, 2015, at 3:17 PM, Mark Andrews <[email-masked]> wrote:
> We should also demonstrate that ULA in conjuction with other GUA is not harmful.

</chair>

I think the point that has to be shown is that it *is* harmful. We didn't have to prove link-local, multicast, unicast, 6to4, or any other address non-toxic; what makes ULA special?

On this list, several operators have stated that they use ULAs in addressing things like cable modems and mobile network infrastructure. If the issue with ULA is NAT, those are examples of devices that need no NAT - for the simple reason that they don't speak outside their domains. However, they are indeed local to a network and their prefix SHOULD NOT be advertised to neighboring networks, nor accepted by those networks if inadvertently advertised.

That really doesn't sound very toxic.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 08 Nov 2015 12:37:50 +1100

In message <[email-masked]>, "Fred Baker (fred)
" writes:
> I think the point that has to be shown is that it *is* harmful. We didn't
> have to prove link-local, multicast, unicast, 6to4, or any other address
> non-toxic; what makes ULA special?

We have also had people argue that using ULA w/ GUA is harmful as
they are worried about connections timing out and address selection
rules from various points in time.

We know ULA + NAT is harmful.  Practical demonstrations of the
alternatives working will eliminate some of the fears people have
for using ULA + GUA (PA).

> On this list, several operators have stated that they use ULAs in
> addressing things like cable modems and mobile network infrastructure. If
> the issue with ULA is NAT, those are examples of devices that need no NAT
> - for the simple reason that they don't speak outside their domains.
> However, they are indeed local to a network and their prefix SHOULD NOT
> be advertised to neighboring networks, nor accepted by those networks if
> inadvertently advertised.
>

It isn't.

> k

---

From: Mark Andrews <[email-masked]>
Date: Sun, 08 Nov 2015 12:50:59 +1100

The IETF network has been traditionally configured as a PI multi-homed
network.  Most of the vendors that turn up have PI multi-homed
networks (Cisco, Juniper, Apple, Microsoft, ISC).  This leaves gaps
in practical experience.

It would be useful for the IETF network to altenate from PI model
to PA model, along with all the workarounds for the limitations
that come with the PA model, periodically.  To test renumbering.

We are wanting smaller sites to move from PA + NAT (IPv4) to PA +
ULA (IPv6).  We should be subjecting ourselves to that configuration.

Mark

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 8 Nov 2015 02:53:06 +0000

> On Nov 8, 2015, at 10:50 AM, Mark Andrews <[email-masked]> wrote:
> 

I commented to the authors of draft-ietf-v6ops-design-choices that they would do well to mention PA and PA+ULA as separate choices, to help the conversation to not rathole on the subject of ULA. They didn't choose to do so, but I would commend the thought to the working group.

If you don't like ULAs, don't use them.

I would encourage discussion of the draft to find another three letter acronym to focus on. The recurrent theme gets boring.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 8 Nov 2015 14:25:34 +0900

> the translation mechanism but with the higher level protocols.

Nope. Those protocols aren't broken, they worked fine for years until NAT
arrived and broke them. They still work fine on networks that operate the
way the Internet was originally designed with end-to-end connectivity.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 8 Nov 2015 14:27:38 +0900

> Are we there yet?

I don't think we ever will be.

---

From: Ivan Pepelnjak <[email-masked]>
Date: Sun, 8 Nov 2015 07:33:41 +0100

Just because I was driving without a seat belt for years doesn’t mean that it’s safe to do so. Just because you COULD doesn’t mean that you SHOULD.

When will we finally grow up (as a community) and get to a point where everyone would consider sending network layer addresses in application messages a bad practice regardless of whether it works or not?
Ivan Pepelnjak
www.ipSpace.net / blog.ipSpace.net

On 8 Nov 2015 at 06:26:10, Lorenzo Colitti ([email-masked]) wrote:

On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard <[email-masked]> wrote:
On 06/11/2015 00:20, Lorenzo Colitti wrote:
It breaks any application that requires that the application know its source address. Examples are SIP, FTP, audio/video chat, etc.
your argument is the wrong way around: some protocols deliberately introduce layering violations by demanding that transport identifier information is encoded at the application layer.  Transport identifier translation merely shows up this brokenness.  The brokenness is not with the translation mechanism but with the higher level protocols.

Nope. Those protocols aren't broken, they worked fine for years until NAT arrived and broke them. They still work fine on networks that operate the way the Internet was originally designed with end-to-end connectivity.
_______________________________________________  
v6ops mailing list  
[email-masked]  
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2015 12:06:27 +0000

On 08/11/2015 05:25, Lorenzo Colitti wrote:
>     translation merely shows up this brokenness.  The brokenness is not
>     with the translation mechanism but with the higher level protocols.
> 

NAT predates both sip and the vast majority of other protocols which encode
inline transport layer identifiers (skype, other chat, etc).

Also, I hope you're not arguing that protocol layering violations are
acceptable from a design point of view.

You're correct that ftp predates nat but having said that, its layering
violations were recognised from the earliest days of the internet as being
atrocious protocol design because of the problems they caused.

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 9 Nov 2015 08:01:28 +1300

> acceptable from a design point of view.

Ah, so you don't like TCP, either, then?

This is all very interesting (and why I wrote my rant last year,
https://www.cs.auckland.ac.nz/~brian/CCR-201404-IPaddrHarmful.pdf)
but I'm not sure what it has to do with the ULA draft, now we've established
that ULA+NPTv6 is not an IETF standard.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Sun, 08 Nov 2015 20:47:32 +0100

>atrocious protocol design because of the problems they caused.

Call me old fashioned, but what NAT breaks is not what is traditionally
called a protocol layering violation. (The TCP checksum is one of the classical
layering violations in the IP protocol stack)

At the transport layer you have transport level network addresses. In transport
protocols such as TCP or UDP, a transport level address consists of an
IP address and a port number. Since the start of the internet, that's how we
refer to transport level sockets.

So it is perfectly normal for protocols above the transport layer to pass
transport layer addresses around. How else would a distributed application
organise itself?

But NAT breaks that.

But NAT also breaks the core internet protocols. Suppose a host uses dynamic
DNS to register its IP address in DNS (alternatively, a DHCP server can
register on behalf of the client). This will completely fail in the context
of NAT unless all DNS servers where such an address might be registered are
aware of NAT and avoid returning those resource records to parties outside
the NAT.

So a network level device requires changes in a application layer protocol.
A clear layering violation.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Nov 2015 04:53:48 +0900

On 11/08/2015 02:25 PM, Lorenzo Colitti wrote:
> On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>>     It breaks any application that requires that the application know
>>     its source address. Examples are SIP, FTP, audio/video chat, etc.
>     information is encoded at the application layer.  Transport
>     identifier translation merely shows up this brokenness.  The
>     brokenness is not with the translation mechanism but with the higher
>     level protocols.
> 
> Nope. Those protocols aren't broken, they worked fine for years until
> NAT arrived and broke them. 

Not-so-clean design (so to speak :-) ) that showed up as a result of
NATs.  Sending addresses in the app protocol is a bad idea. For multiple
reasons.

> They still work fine on networks that
> operate the way the Internet was originally designed with end-to-end
> connectivity.

not sure what you mean by "end-to-end" connectivity.

But if you refer to the property where there is no filtering between the
aforementioned two devices, I wonder how many of such networks are
interconnected via the public Internet.

  ... that train has left ages ago.

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

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 8 Nov 2015 22:06:14 +0000

On 08/11/2015 19:47, Philip Homburg wrote:
> called a protocol layering violation.

When you code layer 3 information at what we usually refer to as layer 7,
this is layering violation.

> transport layer addresses around. How else would a distributed application

No, the combination of layering violations and transport identifier
translation causes this to break.  The root cause of the problem is the
layering violation mandated in the L7 protocol; the breakage trigger is
NAT.  The result is end user trouble.

> DNS

ddns is also a layering violation because it makes an assumption at layer 7
about what's going on in layer 3.

Nick

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 8 Nov 2015 22:40:03 +0000

> On Nov 4, 2015, at 4:24 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Agreed

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 Nov 2015 00:08:53 +0100

>this is layering violation.

I disagree. Absent any session, presentation, and security layers, 
transport layer identifiers are the application layer identifiers. There is
nothing else.

It would be different if we actually had stable identifiers that were
in actual use. But we don't. There is hardly any use of LISP.

And of course, LISP was only defined after the first use of NAT and 
long after DNS was defined and became in wide spread use.

>about what's going on in layer 3.

Again, we have to use transport layer identifiers, because the IP stack
doesn't define anything else.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Nov 2015 10:18:32 +0900

> interconnected via the public Internet.

False dichotomy. Not all filtering causes equal damage to applications.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Nov 2015 22:48:38 -0300

> False dichotomy. Not all filtering causes equal damage to applications.

NAT "broke" FTP for two reasons:

1) IP addresses transferred in the app protocol: this is flawed design. It
makes the app protocol layer-3 dependent, when it need not.

2) "Diode firewall" as a side effect: one might argue that this is flawed
design, too. And an ipv6 diode firewall breaks ftp as badly (hence pasvd).

So in this.respect, nat had just exposed flawed design.

Thanks,
Fernando

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Nov 2015 10:52:55 +0900

> So in this.respect, nat had just exposed flawed design.
It's not the design that's flawed, it's NAT that is flawed.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Nov 2015 23:01:28 -0300

wrote:
>> 1) IP addresses transferred in the app protocol: this is flawed design.
It makes the app protocol layer-3 dependent, when it need not.
>>
>> 2) "Diode firewall" as a side effect: one might argue that this is
flawed design, too. And an ipv6 diode firewall breaks ftp as badly (hence
pasvd).
> It's not the design that's flawed, it's NAT that is flawed.

Including a layer-3 object in a layer-7 protocol seems a bit like layer
violation. And whenever we migrate to ipv-something we'll have to update
ftp (again) -- that should be an indication of flawed design.

Additionally, having a server initiate communication towards a client is,
imo, another flaw.

That's certainly not how we'd design a protocol for file transfer if we
were yo design it today.

Thanks,
Fernando

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Nov 2015 11:04:38 +0900

> That's certainly not how we'd design a protocol for file transfer if we
The main reason you wouldn't design it like that today is that NAT has
broken the original architecture of IPv4. But there's no reason to break
IPv6 in the same way. The main reason that NAT came into existence NAT was
address scarcity, and that reason doesn't exist in IPv6.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 8 Nov 2015 23:27:42 -0300

were yo design it today.

Hate NATs as much as you want. Blame them for keeping state in the network
or whatever you want. But don't don't blame them for making flawed design
evident.

FTP PORT does not work in the presence of an ipv6 diode firewall, either.
And layer 3 addrs in layer 7 protocols is not clean design. Period.

Thanks,
Fernando

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Nov 2015 11:40:43 +0900

> And layer 3 addrs in layer 7 protocols is not clean design. Period.
You're saying that it's a cleaner design to require that any application
that needs to do peer-to-peer connectivity or receive incoming connections
must first talk to a third party to ensure it works? Sorry, but I don't
think that makes sense.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 9 Nov 2015 02:44:46 +0000

> On Nov 9, 2015, at 11:27 AM, Fernando Gont <[email-masked]> wrote:
> 
> layer 3 addrs in layer 7 protocols is not clean design. Period.

To my way of thinking, this is very fundamental. RFC 3439 makes a point about coupling, and how coupling causes problems. When an application presumes that an address that is meaningful in its environment is meaningful in another, that is a very basic coupling. If the remote system were given a name - an L7 identifier - that could be translated into an address in the remote environment, which would resolve many of the issues. The problem is not that NAT broke IPv4, or that IPv4 is broken; it is that the applications written using IPv4 made an unfortunate coupling which NATs exaggerate.

I have a similar comment about the socket layer. Having the application ask the OS for a translation and then connect to the address has been very unfortunate for IPv6 deployment; had the socket layer been designed to have the application present a character string (an address in textual form or a name) and return a connected socket, IPv6 deployment would have been invisible to the applications. It's a bad design at the socket layer, and it's not IPv4's fault or IPv6's.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Nov 2015 00:09:39 -0300

El 9/11/2015 11:44, "Fred Baker (fred)" <[email-masked]> escribió:
> To my way of thinking, this is very fundamental. RFC 3439 makes a point
about coupling, and how coupling causes problems. When an application
presumes that an address that is meaningful in its environment is
meaningful in another, that is a very basic coupling. If the remote system
were given a name - an L7 identifier - that could be translated into an
address in the remote environment, which would resolve many of the issues.
The problem is not that NAT broke IPv4, or that IPv4 is broken; it is that
the applications written using IPv4 made an unfortunate coupling which NATs
exaggerate.
>
> I have a similar comment about the socket layer. Having the application
ask the OS for a translation and then connect to the address has been very
unfortunate for IPv6 deployment; had the socket layer been designed to have
the application present a character string (an address in textual form or a
name) and return a connected socket, IPv6 deployment would have been
invisible to the applications. It's a bad design at the socket layer, and
it's not IPv4's fault or IPv6's.

+1 (100% :-) )

Fernando

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Nov 2015 00:17:44 -0300

wrote:
>>
>> FTP PORT does not work in the presence of an ipv6 diode firewall,
either. And layer 3 addrs in layer 7 protocols is not clean design. Period.
> You're saying that it's a cleaner design to require that any application
that
> needs to do peer-to-peer connectivity or receive incoming connections
think
> that makes sense.

Including layer-3 addresses in layer 7, is flawed, and has nothing to do
with what you're referring to above.

What you refer to has to do with the diode-firewall thing (which is a side
effect in nat, and that folks are replicating in ipv6 by deploying a diode
firewall where you currently have a nat box). Obviously, if your policy is
that you don't want incoming connections, and i have the same policy then,
unfortunately, we have to talk to a third party.

PS: No, i don't want an uncalled-for malformed packet to allow an attacker
to gain access to my IoT device, thanks to its buggy implementation. So,
me, I'll do diode-firewall to my devices, regardless of the availability of
global addresses.

Thanks,
Fernando

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 Nov 2015 12:22:33 +0900

> unfortunately, we have to talk to a third party.
Nope. It is much easier to establish a connection across a diode firewall
than to establish one across a NAT. In the former case, all the endpoints
need to do is send each other packets at about the same time. In the
latter, they need to implement NAT traversal via relays.

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2015 17:12:00 +1100

> in actual use. But we don't. There is hardly any use of LISP.

<snip>

> doesn't define anything else.

So I was thinking about this from the perspective of MPTCP.

I think MPTCP is separating the locator and identifier semantics of IP
addresses, by creating a temporary per-session host identifier, which
is the 32 bit MPTCP session token.

Assuming that the application is oblivious to MPTCP because it should
be hidden within the TCP layer, there is still an issue with NATs.
Although MPTCP is now not using IP addresses as identifiers, it is
still trying to use them as locators, as a host announces to its MPTCP
peer what its local IP addresses are, so that additional MPTCP
subflows can come up if the addresses are reachable by the MPTCP peer.

So a NAT would still cause problems with MPTCP unless the NAT was
MPTCP aware, and translated the addresses that are in the MPTCP TCP
option sent to the MPTCP peer, which won't be able to be done if
end-to-end IPsec was in use.

So does that mean that the transport layer shouldn't be using IP
addresses either, even if they're now only locators in an MPTCP
scenario? Is this really saying that layers above the network layer in
hosts shouldn't be aware at all of or be able to find out of the
host's network location?

Mark.

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Nov 2015 17:13:45 +1100

>> I think a careful explanation of the failure modes is more useful than a

+1

We can't prescribe, but we can advise and describe.

---

From: Joe Touch <[email-masked]>
Date: Mon, 9 Nov 2015 13:02:02 -0800

> layering violations in the IP protocol stack)

Given that a NAT breaks the TCP checksum (which depends on the IP
pseudoheader and TCP header) and thus has to recalculate it, wouldn't
that be proof that a NAT breaks what you consider protocol layer violation?

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 9 Nov 2015 13:05:27 -0800

> doesn't define anything else.

Note that some protocols do define other identifiers, e.g., HTTP uses URNs.

We often use L4 identifiers when there are no other upper layer
end-to-end identifiers available, e.g., the app uses 128.9.160.161:80
because that's what the user provided. The fact that these are L4 (or
L3) identifiers is true only because the addresses got passed down
through the stack - which is definitely not layer violation.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 9 Nov 2015 13:10:02 -0800

On 11/8/2015 6:04 PM, Lorenzo Colitti wrote:
> broken the original architecture of IPv4.

NATs actually provide a very sensible model, just not the one most
designers think.

>From the private side, a NAT acts like a router.

>From the public side, a NAT is (not just "acts like") the endpoint.

So it's not surprising that running an application that isn't on the NAT
box causes problems. The NAT is the problem - it wants to act like an
endpoint (sourcing/sinking packets from/to a public IP address) but
doesn't want (or have enough information) to run the app correctly.

The IP achitecture is fine, and NATs can be a valid part of that
architecture, but only to the extent of what they are. They ARE hosts on
the public side. E.g., we would expect that it's hard to run 6 web
servers on port 80 on a single host with a single IP address; why is it
so surpising that a NAT can't support that?

Joe

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Nov 2015 12:50:55 +0100

>that be proof that a NAT breaks what you consider protocol layer violation?

If a layering violation like in TCP gets broken by NAT, then I consider
that fair game. I.e., such layering violations should not exist in the
first place, so it is TCP that is broken.

>through the stack - which is definitely not layer violation.

Commonly used URNs rely on transport layer addresses (which are broken by
NAT) or DNS, which is also broken by NAT (in some cases).

One way of looking at NAT is that it deals with a failure of IP addressing.
In the case of IPv4, with the fact that 32 bits is just not enough.

And in IPv6 most likely in cases where the locator/identifier split is not
in the architecture. 

I.e. NAT breaks the model because it is a fix where the model is broken.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 10 Nov 2015 14:13:22 +0000

What you refer to has to do with the diode-firewall thing (which is a side effect in nat, and that folks are replicating in ipv6 by deploying a diode firewall where you currently have a nat box). Obviously, if your policy is that you don't want incoming connections, and i have the same policy then, unfortunately, we have to talk to a third party.

Nope. It is much easier to establish a connection across a diode firewall than to establish one across a NAT. In the former case, all the endpoints need to do is send each other packets at about the same time. In the latter, they need to implement NAT traversal via relays.

It is only 'slightly' easier... Because guessing the TCP sequence number of the other party... Well good luck :-)

-éric

---

From: Joe Touch <[email-masked]>
Date: Tue, 10 Nov 2015 09:34:25 -0800

On 11/10/2015 3:50 AM, Philip Homburg wrote:
> that fair game.

What's the layering violation?

TCP endpoints are defined as being the endpoint IP + port pair. TCP and
IP are not independent layers; they never have been.

> I.e., such layering violations should not exist in the

If you believe that TCP should have its own IP addresses, then fine.
Let's consider the following:

	IP-IP-TCP

Then the first layer is IP, the second is the IP-TCP pair.

That would provide the clean layering you desire, but NATs would break
that too. NATs intentionally overwrite identities - not just routes.
There's no way to do that without violating every basic premise of layering.

...
> NAT) or DNS, which is also broken by NAT (in some cases).

Right - the basic concept of a NAT is exactly opposite the concept of
strict layering.

> In the case of IPv4, with the fact that 32 bits is just not enough.

Another view is that NATs also exist - especially in IPv6 - as a way for
ISPs to enforce a pricing policy that differentiates consumers from
corporate customers by artificially and deliberately interfering with
the Internet model of global endpoint addresses (i.e., to interfere with
setting up a server, because - of course - only a corporate customer
would need to do that).

> And in IPv6 most likely in cases where the locator/identifier split is not

See above.

> I.e. NAT breaks the model because it is a fix where the model is broken.

I agree that NATs for true address sharing serve a useful purpose, but
that disappears with IPv6. NATs for security can easily be replaced by
stateful firewalls, i.e., that limit incoming connections without
rewriting the headers.

The problem with believing that NATs fix a broken model is that, if the
model *is* broken, it's because of a lack of transport-layer IDs. NATs
further destroy that concept when they overwrite both addresses and
ports - that's not fixing a broken model, it's breaking it even more.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Nov 2015 01:02:16 +0900

On 11/10/2015 11:13 PM, Eric Vyncke (evyncke) wrote:
> 
>         What you refer to has to do with the diode-firewall thing (which
>         is a side effect in nat, and that folks are replicating in ipv6
>         by deploying a diode firewall where you currently have a nat
>         box). Obviously, if your policy is that you don't want incoming
>         connections, and i have the same policy then, unfortunately, we
>         have to talk to a third party.
> 
>     Nope. It is much easier to establish a connection across a diode
>     firewall than to establish one across a NAT. In the former case, all
>     the endpoints need to do is send each other packets at about the
>     same time. In the latter, they need to implement NAT traversal via
>     relays.
> 

I guess that, at the very least, you need be able to guess the ephemeral
ports? And, if you're able to do that, there's a flaw in there (see rfc
6056).

Bottom line is...wh're talking about which pain is less pain :-)... and
truth is that in most of such "pain" scenarios the aforementioned pain
reflects policy of "I don't want to talk with anybody, unless it's me
the one starting the conversation" -- i.e., you shouldn't be ding it,
anyway.

Thanks!

Cheers,

---

From: Owen DeLong <[email-masked]>
Date: Wed, 11 Nov 2015 14:17:16 -0800

> On Nov 5, 2015, at 10:17 , David Farmer <[email-masked]> wrote:
> 
> For the most part I like this.  It takes emotional trigger words out of it.  However, I would suggest focusing on Internet connectivity and away from all potential uses of NAT.  I believe the primary objection to NAT is in a general-purpose Internet context, and other more specialized uses might be less objectionable to some.  So something like;
> 

I could live with this, but I suggest:

“Use of NPT66 and NAT66 as a general concept are NOT RECOMMENDED in the context of internet connectivity.”

If it connects to the v6 internet and it has a v6 address, it shouldn’t need or have NAT in the way.

Sure, some people will do annoying and harmful things with their networks, but there’s no reason we should give them an escape clause to legitimize such activity.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 09:51:49 -0800

Perhaps when someone presents a viable alternative for protocols that require out-of-band signaling for connection setup and tear-down.

Owen

> On Nov 7, 2015, at 22:33 , Ivan Pepelnjak <[email-masked]> wrote:
> 
> www.ipSpace.net <http://www.ipspace.net/> / blog.ipSpace.net <http://blog.ipspace.net/>
> On 8 Nov 2015 at 06:26:10, Lorenzo Colitti ([email-masked] <mailto:[email-masked]>) wrote:
> 
>> On Fri, Nov 6, 2015 at 7:08 PM, Nick Hilliard <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 09:59:37 -0800

> On Nov 8, 2015, at 04:06 , Nick Hilliard <[email-masked]> wrote:
> 

You realize that from this point of perspective, your argument could be seen
as claiming that DNS which provides L3 information over an L4+ protocol
is a layering violation. What would you use instead?

Similarly, the argument can be made with website redirects and embedded
URLs, even if they contain host names rather than L3 and L4 identifiers
directly.

You can dismiss this as reductio ad absurdum, but in reality, the principle
of layering violation as a practical solution to problems that don’t really have
a solution without involving some level of layering violation remains.

It’s utterly impossible to provide any kind of out of band signaling or solution
for session setup/teardown without involving some form of layering violation.

> atrocious protocol design because of the problems they caused.

Yet, despite all of this recognition, nobody ever really solved them. The only
difference introduced with PASV FTP was the ability to reverse the initiation
direction of the OOB channel.

Has anyone developed a general file transfer mechanism that doesn’t involve
layering violations?

SFTP, SCP, etc. don’t qualify… They use the same kind of layering violation, they
just hide it inside of tunnels inside of the SSH protocol.

The file transfers in the various chat applications that I’m aware of also use some
form of what amounts to the tunneled layering violations similar to SSH, regardless
of their use of encryption or not.

TFTP has all of the same issues as FTP.

Is there an alternative to SIP that doesn’t require layering violations?

You can move the layering violations around, but you can’t eliminate them completely.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 10:05:05 -0800

> not sure what you mean by "end-to-end" connectivity.

I won’t speak for Lorenzo, but what I mean when I talk about “end-to-end”
is the situation where the L3 packet that leaves the origin host arrives
at the destination host without being modified except for certain fields
intended to be modified in flight. (Namely TTL/Hop Count, L2 and lower
layer fields, etc.). Certainly the L3 and higher layer identifiers are not
to be tampered with in flight.

If they are, then that is a clear layering violation of the worst possible
type.

> interconnected via the public Internet.

I don’t think that’s what is meant in this context, but I’ll leave it to Lorenzo
to speak for himself.

>  ... that train has left ages ago.

Filtering is not the same as packet mutilation.

Deliver the packet or don’t deliver the packet according to your policies on your network, fine.

Editing the packet to alter its behavior in flight, OTOH, is one of the worst kinds of network skulduggery IMHO.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 10:16:04 -0800

> On Nov 10, 2015, at 03:50 , Philip Homburg <[email-masked]> wrote:
> 

Alternatively, NAT is an alternative form of brokenness where the “cure” is often (usually) worse than the disease.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 10:21:20 -0800

> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
>>> 

With a diode firewall, you don’t have to guess. Most diode firewalls don’t look at TCP sequence numbers actively. They look only at the L3 and L4 identifiers to determine state.
Some look at SYN bits and toss SYN packets going in the wrong direction, but most just look for an ACK bit.

Nonetheless, it’s also much easier because a diode firewall can easily be given an exception to permit a particular flow or the initiation of a class of flows to a particular protected host or set of hosts.

In the case of a NAT, however (more specifically a NAPT), it is not possible to program multiple port 80 terminations to land on different hosts behind the NAT.

In short, without NAT, flows which are desired can be permitted. With NAT, this is much more difficult and in many cases, impossible.

I retain my perspective that one of the worst and most ultimate forms of layering violation is for a forwarding system not residing on either of the end-hosts in a session to impersonate an end-host and mutilate unexpected portions of the datagram in flight.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 10:29:40 -0800

> On Nov 5, 2015, at 21:31 , [email-masked] wrote:
> 

A statement that we strongly recommend against the use of it does not take
it out of your toolbox. It just says that it’s a dangerous tool and that when
you use it to drive a nail through your thumb, you can’t say we didn’t warn you.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 10:32:34 -0800

> On Nov 5, 2015, at 23:14 , [email-masked] wrote:
> 

How is a /48 PI hard to acquire? Where?

I know it’s utterly simple in the ARIN region.
To the best of my knowledge, it is fairly simple in RIPE.
It’s utterly easy in APNIC, though somewhat expensive IMHO.
I believe it is fairly easy in LACNIC.
To the best of my knowledge, it is not difficult or expensive in AfriNIC.

Please explain exactly what circumstances make it too difficult for any company
to acquire a /48 PI as I would consider this a brokenness in the relevant RIR’s
policy and would happily work to resolve the issue.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 10:38:24 -0800

> On Nov 6, 2015, at 02:15 , Nick Hilliard <[email-masked]> wrote:
> 

Given the persistent and pestilent nature of NAT externalizing costs onto other parties not choosing to use it, I think that is a perfectly valid approach at this time.

Let us now go forth and destroy Carthage (remove NAT from the public internet) as to eliminate this problem from our collective future.

If you want to use NAT in whatever form on your own network in a manner that does not externalize costs to software vendors, other providers, or pollute the internet with false identifiers, then by all means, do as you wish.

If your use of NAT does not fall within those limitations, then, indeed, it should be destroyed.

Owen

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Nov 2015 19:46:13 +0100

Hi,

On Thu, Nov 12, 2015 at 10:32:34AM -0800, Owen DeLong wrote:
> I know it???s utterly simple in the ARIN region.
> It???s utterly easy in APNIC, though somewhat expensive IMHO.
> to acquire a /48 PI as I would consider this a brokenness in the relevant RIR???s

The IETF world does not (at least "should not") revolve around "companies",
and I wish you good luck finding a SoHo ISP that will route your PI space.

IOW, having a /48 PI space is nice, but if that does not have Internet
connectivity, how exactly does it differ from ULA?

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 Nov 2015 19:56:57 +0100

> I know its utterly simple in the ARIN region.  To the best of my
> knowledge, it is fairly simple in RIPE.  Its utterly easy in APNIC,
> though somewhat expensive IMHO.  I believe it is fairly easy in
> LACNIC.  To the best of my knowledge, it is not difficult or
> expensive in AfriNIC.
> 
> Please explain exactly what circumstances make it too difficult
> for any company to acquire a /48 PI as I would consider this a
> brokenness in the relevant RIRs policy and would happily work to
> resolve the issue.

Yes, it is easy to get a /48 PI and then what?

Suppose we have small business that moderately happy with poor man's
multihoming using two consumer ISPs (say DSL and cable) and a NAT box.

Now we advice that company to use a /48 PI for IPv6. I'm not even aware of
any consumer ISP offering routed PI space as a service, I probably wouldn't
trust my local cable company to announce my PI space. 

So what does that cost in your part of the world?

My guess is that if one vendor suggests using PI space and another NAT66
then just about any business will pick NAT66. 

I think it is safe assume that any company that doesn't have IPv4 PI space
today will not get IPv6 PI space.

Then there is the obvious scaling problem. If we would insist that every
small business in the world would get (and announce) PI space then the
operators would call us nuts.

(IPv6 poor man's multi homing can be done using by manipulating the
perference values of the PA prefixes, but there is not even an RFC 
detailing how that should be done, let alone products on the market)

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 11:36:06 -0800

> On Nov 12, 2015, at 10:46 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

2620:0:930::/48

Q.E.D.

Owen

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Nov 2015 20:43:27 +0100

Hi,

> > and I wish you good luck finding a SoHo ISP that will route your PI space.

This is not a typical SoHo ISP.

Try finding one which is not your employer.

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 08:53:42 +1300

Please let's not pretend we're discussing the ULA draft any more.

On 13/11/2015 07:32, Owen DeLong wrote:

...
> How is a /48 PI hard to acquire? Where?

As others have implied, that isn't the point. The point (and I expect
we had this argument on the RRG list some years ago) is that we can't
put 10,000,000 /48 entries into BGP. So if we go around encouraging
all small enterprises to get a PI prefix we are all doomed.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 13 Nov 2015 07:08:30 +1100

>> On Nov 5, 2015, at 23:14 , [email-masked] wrote:
<snip.
> policy and would happily work to resolve the issue.

This was was in part what I was getting getting at when I said that
abandoning ULAs would discourage adoption of IPv6.

If you're building a small network that either currently isn't and may
never be attached to the Internet, you have 3 choices:

(a) apply for RIR membership and incur annual RIR costs to get a PI
/48 and after some time delay, be able to build your IPv6 network

(b) use $free ULA space, and be able to build your IPv6 network right now

(c) use $free RFC1918 IPv4 space, and build an IPv4 network right now

Option (a) has financial costs and time delays that option (b)
doesn't, and if option (b) doesn't exist, then option (c) is the most
convenient and timely choice, unless it is essential that IPv6 is
used. Option (c) being the most convenient, cost effective and timely
option for if (b) isn't available will actually discourage support for
IPv6.

I think that if (a) was the only choice, it is in effect creating an
annual tax or license fee on the use of IPv6 technology, because (in
theory) you wouldn't be able to use IPv6 unless you paid an RIR and
waited for them to give you your space. Of course, the other choice
would be that some people would steal space to use instead to build an
IPv6 network, like the documentation prefix. Absence of a local use
address space encourages stealing of other address spaces if you don't
have time to get a proper one or don't have the financial means or
financial incentive to get some.

Humans don't incur costs on themselves unless they see or perceive
some equivalent benefit. Making something available for "free", in
this case a local yet globally unique network address space,
significantly lowers the barrier to IPv6 adoption. If you've bought
the equipment to build your network, and it comes IPv6 enabled for
"free", you can then immediately build an IPv6 network using ULA
space.

If at a later date a ULA addressed network connects to the Internet
they would add PA or PI space to be able to access external
destinations, because IPv6 is designed to fully support parallel
address spaces (i.e., so having ULAs on your network doesn't
automatically imply using NAT66).

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 12:24:27 -0800

> On Nov 12, 2015, at 11:43 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

neither of the upstreams for that address employs me at this time.

Admittedly I did use to work for ONE of the two, but anyone can get that one to route their /48.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 13:42:45 -0800

> On Nov 12, 2015, at 12:08 , Mark Smith <[email-masked]> wrote:
> 

(d) use whatever string of {32,48,64} bits you want and pretend it’s
an IPv6 prefix.

Please explain what benefit (b) offers over (d) in such a case. You’re going
to end up renumbering when you attach to the internet either way.

> financial incentive to get some.

I’m all for providing a lower cost alternative to having a legitimate registry
for addresses for smaller users.

> "free", you can then immediately build an IPv6 network using ULA

Except that ULA isn’t globally unique, it’s just “probably unique” for various
relatively high values of “probably” depending on how you go about choosing
your ULA prefix. Were ULA globally unique, you’d have the double edge sword
of:

	1.	It’s good because it’s free PI address space.
	2.	It’s bad because it’s a free end-run around the RIR policy processes.

> automatically imply using NAT66).

Except for all the problems previously noted in such installations with various
issues around source address selection, etc.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Nov 2015 08:48:19 +1100

In message <[email-masked]>, Owen DeLong write
> Admittedly I did use to work for ONE of the two, but anyone can get that one 

And how many SME's are there in the world?  This paper [1] puts the
number at 125M MSME world wide.  That's 125M routing slots if
everyone gets a /48.

Mark

[1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 13:58:03 -0800

We have to solve the scaling problem of how we currently do routing at some point no matter what.

ULA+NPT as a workaround is an extremely poor choice IMHO.

Owen

> On Nov 12, 2015, at 13:48 , Mark Andrews <[email-masked]> wrote:
> 
> 
> In message <[email-masked] <mailto:[email-masked]>>, Owen DeLong write
> s:
>> 
> [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES <http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES>
> 
>> Owen
>> 
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Thu, 12 Nov 2015 22:59:49 +0100 (CET)

> (d) use whatever string of {32,48,64} bits you want and pretend it$,1ry(Bs
> an IPv6 prefix.
> 
> Please explain what benefit (b) offers over (d) in such a case. You$,1ry(Bre going

Option b lets you use NPT66 to attach to the Internet without
renumbering.

Option d may or may not let you use NPT66 to attach to the Internet
without renumbering - depending on whether the IPv6 address you just
grabbed out of thin air already is in use.

So for those willing to consider NPT66, option b has an advantage.

Steinar Haug, AS 2116

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 14:02:25 -0800

> On Nov 12, 2015, at 13:59 , [email-masked] wrote:
> 
>> (d) use whatever string of {32,48,64} bits you want and pretend it�$,1rys
>> an IPv6 prefix.
>> 
>> Please explain what benefit (b) offers over (d) in such a case. You�$,1ryre going

It’s relatively easy to safely grab addresses that will not be in use for the
foreseeable future using (d).

> So for those willing to consider NPT66, option b has an advantage.

And for those, shame on them for the tendency this has to create uncontrolled costs for other users of the internet.

This is a form of the toxic polluter business model.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Nov 2015 09:53:06 +1100

In message <[email-masked]>, Owen DeLong write
s:
> >> to acquire a /48 PI as I would consider this a brokenness in the
> relevant RIRs
> (d) use whatever string of {32,48,64} bits you want and pretend its
> an IPv6 prefix.
>
> Please explain what benefit (b) offers over (d) in such a case. Youre
> going to end up renumbering when you attach to the internet either way.

Renumbering in IPv6 is not the same as renumbering in IPv4.  In
this case you are just adding a prefix.  You don't stop using the
ULA addresses in (b).  For (d) you need to remove the addresses
because you don't know what you are colliding with.

Additionally we have deployed technology for nodes to update their
addresses in the DNS which deals with most of the renumber problem.

A 1 page BCP which says to do what Apple and various router vendors
have been doing for years updating the DNS should be enough to get
the rest to do this.

> Im all for providing a lower cost alternative to having a legitimate
> registry for addresses for smaller users.
>
> Except that ULA isnt globally unique, its just probably unique for various
> relatively high values of probably depending on how you go about choosing
> your ULA prefix. Were ULA globally unique, youd have the double edge sword
> of:
>
> 	1.	Its good because its free PI address space.
> 	2.	Its bad because its a free end-run around the RIR policy
> processes.

And that matters how?  If you happen to learn a remote ULA address
and actually use it the border router should block the packet and
send back a ICMP administrively prohibited unreachable.  If there
is a ULA prefix collision you still have to match the rest of the
address which is highly unlikely.  Subnet collisions in this case
are likely but not the full address.

> Except for all the problems previously noted in such installations with
> various issues around source address selection, etc.

Which in practice does not exist.  I've run networks with ULA + PA
locally and *never* seen a issue due to address selection.  Longest
match takes care of that for the older machines (0010 vs 1111).
Newer machines know about ULA so have different address match rules
which deal with ULA address leaks.  Properly configuring the border
routers to return ICMPv6 administrively prohibited for attempts to
send a packet outside the site using a address from the ULA prefix
deals with the rest.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 12:50:26 +1300

> number at 125M MSME world wide.  That's 125M routing slots if

Thanks for that reference. My estimate of 10M was based on some hand-waving
arguments about how many SMEs might seriously want to be multihomed; IMHO
most of them will be perfectly happy with PA addressing because they will
have anything that needs a stable address hosted anyway. Most SOHOs just don't
care, and get renumbered without knowing it after power fails etc. Homenet
takes this as a given, of course.

    Brian

---

From: joel jaeggli <[email-masked]>
Date: Thu, 12 Nov 2015 16:03:35 -0800

> takes this as a given, of course.

http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-as-count%2etxt&descr=Unique%20ASes&ylabel=Unique%20ASes&with=step

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Nov 2015 10:04:05 +1000

this is a specious argument.  Its as specious as the 'one IP per citizen'
complaints relating to some national numbering plans, or the model of
assigning v6 to motor vehicle vendors.

the reason its specious, is twofold

1) it has a natural ramp up. to get every SME up to speed and *able* to
multihome and route, takes time. Therefore there is no cliff moment: its a
process. A process which emerges, over time, and permits adjustment of the
routing model to cope.

2) other processes are also placing pressure on routing slots and the
routing model. Therefore, by the time we need to handle 150-250m SMEs
(after all there will be more..) we will have evolved models of both
address management, and scoped routing, and abstract routing data models
which suit the scale we need.

please don't make assumptions now, based on future fear. We have nothing to
fear, except fear itself.

_G

On Fri, Nov 13, 2015 at 9:50 AM, Brian E Carpenter <
[email-masked]> wrote:

> >>>>> The IETF world does not (at least "should not") revolve around
> "companies
> >> ",
> >>>>> and I wish you good luck finding a SoHo ISP that will route your PI
> space
> >> .
> >>>>
> >>>> 2620:0:930::/48
> >>>
> >> Admittedly I did use to work for ONE of the two, but anyone can get
> that one
> >> to route their /48.
> >
> > [1]
> http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES
> >
> >> Owen
> >>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 09:10:10 +0900

> of the other party... Well good luck :-)

The sort of application that tries to do this doesn't typically use TCP.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 16:13:45 -0800

> On Nov 12, 2015, at 14:53 , Mark Andrews <[email-masked]> wrote:
> 
> 
> In message <[email-masked] <mailto:[email-masked]>>, Owen DeLong write
> s:
>> 

I’m well aware of this. Nonetheless, your statement is not true.

(d) if I use something like f3fe::, I can be quite certain for some time to come that
I’m not colliding with anything other than someone else who randomly chose f3fe::.

This is actually a lower likelihood of collision than I get with ULA.

True, if I chose something within 2000::/3, I know I’m likely to collide with some
unknown thing that expects their addresses to be globally unique.

Also true that at some future date, my f3fe:: address may come to collide with
some future IETF decision at which point I _MAY_ have to remove the prefix.

> addresses in the DNS which deals with most of the renumber problem.

Not sure how this is relevant, but whatever.

> have been doing for years updating the DNS should be enough to get

Again, not sure how this is relevant to the utility (or lack thereof) for ULA.

> are likely but not the full address.

Why? There are circumstances where the border router may actually intend
to exchange packets with some other person using that same ULA prefix.

ULA is just like RFC-1918 except it provides a greater illusion of utility. It still
offers all the same problems, just in a less constrained and (potentially) harder
to identify way. It does offer a greater timeline and potential for the creation
of time-bomb configurations that work at the time of installation and then break
spectacularly at some future date due to the collision of earlier decisions on two
networks that later find themselves connected in places far removed from where
those decisions were made.

> send a packet outside the site using a address from the ULA prefix

I hate to break it to you Mark, but your relatively narrow experience does not
constitute the entire world. I have seen these problems, even in as simple a
case as GUA/SLAAC + GUA/Privacy Address.

I have seen problems getting outbound connections to select the correct source
address in a variety of scenarios and I have seen things break in significant and
interesting ways as a result.

I assure you that these problems most definitely do exist in practice in some
environments, even if yours doesn’t happen to be one of them.

Owen

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Nov 2015 11:15:51 +1100

In message <[email-masked]>
> process. A process which emerges, over time, and permits adjustment of the

Your assuming multi-homing.  If you don't have PA, ULA + PA and
don't have ULA + NAT then PI is all that is left and there is a
very small bar to jump to be singly attached.  You don't even need
to run a routing protocol.  You just need the ISP to inject the /48
for you.

Owen wants us to just recommend PI and to forget about PA, ULA +
PA and ULA + NAT.  If that is the recommendation then we will have
125M /48's within a couple of years.  That's why we should reject
Owen's recommedation and go with something more conservative.

	e.g. a mixture of PI, PA and PA + ULA.

> --001a1138f6f038e523052460cc28
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">this is a specious argument.=C2=A0 Its as specious as the =
> &#39;one IP per citizen&#39; complaints relating to some national numbering=
>  plans, or the model of assigning v6 to motor vehicle vendors.<div><br></di=
> v><div>the reason its specious, is twofold</div><div><br></div><div>1) it h=
> as a natural ramp up. to get every SME up to speed and *able* to multihome =
> and route, takes time. Therefore there is no cliff moment: its a process. A=
>  process which emerges, over time, and permits adjustment of the routing mo=
> del to cope.</div><div><br></div><div>2) other processes are also placing p=
> ressure on routing slots and the routing model. Therefore, by the time we n=
> eed to handle 150-250m SMEs (after all there will be more..) we will have e=
> volved models of both address management, and scoped routing, and abstract =
> routing data models which suit the scale we need.</div><div><br></div><div>=
> please don&#39;t make assumptions now, based on future fear. We have nothin=
> g to fear, except fear itself.</div><div><br></div><div>_G</div></div><div =
> class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Nov 13, 2015 a=
> t 9:50 AM, Brian E Carpenter <span dir=3D"ltr">&lt;<a href=3D"mailto:brian.=
> [email-masked]" target=3D"_blank">[email-masked]</a>&gt=
> ;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
> .8ex;border-left:1px #ccc solid;padding-left:1ex">On 13/11/2015 10:48, Mark=
>  Andrews wrote:<br>
> &gt;<br>
> &gt; In message &lt;<a href=3D"mailto:95BC3D07-EF27-45A9-A1E0-12F9B43061C7@=
> delong.com">[email-masked]</a>&gt;, Owen D=
> eLong write<br>
> &gt; s:<br>
> &gt;&gt;<br>
> &gt;&gt;&gt; On Nov 12, 2015, at 11:43 , Gert Doering &lt;<a href=3D"mailto=
> :[email-masked]">[email-masked]</a>&gt; wrote:<br>
> &gt;&gt;&gt;<br>
> &gt;&gt;&gt; Hi,<br>
> &gt;&gt;&gt;<br>
> &gt;&gt;&gt; On Thu, Nov 12, 2015 at 11:36:06AM -0800, Owen DeLong wrote:<b=
> r>
> &gt;&gt;&gt;&gt;&gt; The IETF world does not (at least &quot;should not&quo=
> t;) revolve around &quot;companies<br>
> &gt;&gt; &quot;,<br>
> &gt;&gt;&gt;&gt;&gt; and I wish you good luck finding a SoHo ISP that will =
> route your PI space<br>
> &gt;&gt; .<br>
> &gt;&gt;&gt;&gt;<br>
> &gt;&gt;&gt;&gt; 2620:0:930::/48<br>
> &gt;&gt;&gt;<br>
> &gt;&gt;&gt; This is not a typical SoHo ISP.<br>
> &gt;&gt;&gt;<br>
> &gt;&gt;&gt; Try finding one which is not your employer.<br>
> &gt;&gt;<br>
> &gt;&gt; neither of the upstreams for that address employs me at this time.=
> <br>
> &gt;&gt;<br>
> &gt;&gt; Admittedly I did use to work for ONE of the two, but anyone can ge=
> t that one<br>
> &gt;&gt; to route their /48.<br>
> &gt;<br>
> &gt; And how many SME&#39;s are there in the world?=C2=A0 This paper [1] pu=
> ts the<br>
> &gt; number at 125M MSME world wide.=C2=A0 That&#39;s 125M routing slots if=
> <br>
> &gt; everyone gets a /48.<br>
> <br>
> Thanks for that reference. My estimate of 10M was based on some hand-waving=
> <br>
> arguments about how many SMEs might seriously want to be multihomed; IMHO<b=
> r>
> most of them will be perfectly happy with PA addressing because they will<b=
> r>
> have anything that needs a stable address hosted anyway. Most SOHOs just do=
> n&#39;t<br>
> care, and get renumbered without knowing it after power fails etc. Homenet<=
> br>
> takes this as a given, of course.<br>
> <br>
> =C2=A0 =C2=A0 Brian<br>
> <br>
> <br>
> &gt;<br>
> &gt; Mark<br>
> &gt;<br>
> &gt; [1] <a href=3D"http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482=
> b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES" rel=3D"noreferrer" tar=
> get=3D"_blank">http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b5195=
> 83b6d16/MSME-CI-AnalysisNote.pdf?MOD=3DAJPERES</a><br>
> &gt;<br>
> &gt;&gt; Owen<br>
> &gt;&gt;<br>
> &gt;&gt; _______________________________________________<br>
> &gt;&gt; v6ops mailing list<br>
> &gt;&gt; <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> &gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"nor=
> eferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><=
> br>
> <br>
> _______________________________________________<br>
> v6ops mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/v6ops" rel=3D"noreferrer" =
> target=3D"_blank">https://www.ietf.org/mailman/listinfo/v6ops</a><br>
> </blockquote></div><br></div>
> 
> --001a1138f6f038e523052460cc28--
> 
> 
> --===============2879774530696980085==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============2879774530696980085==--
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 09:15:42 +0900

> number at 125M MSME world wide.  That's 125M routing slots if

I doubt that all but a small fraction of those SMEs actually need
multihoming. But even for those that do - we should be working on making it
possible to multihome using src+dst routing, not NPT66 or NAT66.

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Nov 2015 10:20:52 +1000

I'm sorry Brian, but as I said in another reply, this is just specious.
It's true in as much as IF all SME's wound up in BGP we'd have a heat-death
problem.

But a) they won't arrive tomorrow, or next year: it takes time,  and b)
other solutions to routing will emerge. Like, giving them scoped /48 out of
a block which has export limits under some covering prefix, and limits the
local visibility of their BGP independence to within some constrained
context.

It never ceases to amaze me that I tell a yak-herder my BGP failures,
forcing local path selection, with no subsequent alteration in routing of
concern to them, *and we're not even shipping packets*

Tony Hain amongst others proposed models of geographic and scoped
assignment which were shot down in flames by the usual suspects. Because
its "not how we do it now" people don't like talking about this sensibly,
but there are rational models of address management which preserve BGP like
behaviour, but don't expose all routing decisions globally, that only have
local meaning.

G

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 16:22:58 -0800

> On Nov 12, 2015, at 16:15 , Mark Andrews <[email-masked]> wrote:
> 
> 
> In message <[email-masked] <mailto:[email-masked]>>

No… You are placing words into my mouth that simply were never there.

I want to forget about ULA and ULA+NAT.

I’m fine with PA for those willing to accept it and I advocate PI for those not
willing to accept PA and its limitations.

I’ve never campaigned against PA. I have campaigned against the refusal
of PI for those that did not want PA, but that is a different issue. PA where it
is an adequate solution is fine with me. IMHO, those are a fairly limited set
of circumstances and we should be expecting a relatively significant growth
in the IPv6 routing table over the next couple of years, whether we like the idea
or not. But again, that’s a separate issue.

> 	e.g. a mixture of PI, PA and PA + ULA.

I accept a mixture of PI and PA. I even accept PA+ULA, though I argue it is an
inferior solution with significant drawbacks.

Nonetheless, anything involving NAT whether or not it involves ULA on a system
which is connected to the internet is a harmful “solution" where the harm inflicted
often (usually) extends beyond the network that chose to implement said “solution”.

Owen

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Nov 2015 10:24:18 +1000

Strong +1. We need to stop using FUD on future routing cost to limit how we
design systems for enterprises and homes. By all means lets constrain
current behaviour to scale with memory and CPU, but to set limits 5-10-15
years out based on fear of a situation which is unlikely to emerge, and
will emerge into different technology and models.. Well its sad.

Its Dionysius Lardner "60mph will kill humans, stop speeding up steam
trains" thinking.

Whats even weirder, is that its some people who helped displace prior art,
telephone number centric thinking who are doing it. How come the former
rebels have become the empire?

_G

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 13:30:30 +1300

> 	e.g. a mixture of PI, PA and PA + ULA.

Exactly. (I deny that my argument is specious; but then I won't believe
in the BGP4 scaling fairy until I see him or her).

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 13:34:46 +1300

On 13/11/2015 13:20, George Michaelson wrote:
> other solutions to routing will emerge. 

No doubt. But Mark is correct: we have to defer the crisis until the solution
is available. We deferred it once by introducing CIDR 20 years ago. Encouraging
PI for all customers is antiCIDR, and that's a problem.

   Brian

> Like, giving them scoped /48 out of

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 Nov 2015 11:51:06 +1100

In message <[email-masked]>, Owen DeLong write
s:
> > In message <[email-masked]
> <mailto:[email-masked]>>, Owen DeLong
> write
> > s:
> >>

So you just want a random free for all.  Guess what it costs to clean
up the mess that produces.  We are going through the process of dealing
with the mess of people thinking that the DNS root was a free for all
despite it not being one.

> Not sure how this is relevant, but whatever.

Then you are not @#$!# paying attention.

> to exchange packets with some other person using that same ULA prefix.

And border routers can actually talk to two or more sites using the
same ULA prefix today.  This isn't rocket science.  The api's to
do this exist and are in use.  It just takes a little care.  The
concept of the site boundary being through the middle of a box and
the same prefixes being in use on multiple sites has been part of
IPv6 from just about the very begining.  If your border router can't
handle this file a bug report because it is broken.

Now if you want to route between ULA's using the same prefix then
you have problems but it is easy to generate new ULA prefixes that
don't collide and to then stop using the ones that collided.

> those decisions were made.

There is no time bomb.  Only the illusion of a time bomb.

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Nov 2015 10:58:02 +1000

Since I work in the governance side, I have to be clear that I have no
voice in policy in RIR land, this is just my personal opinion.

But my personal opinion is that we are not facing a CIDR scale problem in
this niche, and probably don't need to act like we are.

My reason is simple: CIDR was about exhaustion as much as about routing. We
have only half the problem, and even that is (in my opinion) tendentious.
We *may* have half the CIDR problem, but its a may, not a *do*. -Therefore,
applying CIDR logic to the address management process in V6 is not (yet)
justified.

Contrariwise, we have an uptake problem. We should be encouraging uptake of
IPv6, and if pushback from network-literate SME's is that they are
concerned about capture behind a PA then we should admit PI processes, and
not be over-pessimistic about the cost in future routing terms of PI to SMEs

Rather than asking BGP/Router people "can you make a router now for 100m
prefixes" we should be saying "if we can forsee 100m prefixes in 5-10 years
time, can you get there, and if not, what models of prefix management would
work for you"

I think this is a corollary of what John Scudder did in IEPG: we need the
conversation with the ASIC people to be framed the right way.

-G

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 17:08:34 -0800

> despite it not being one.

No, not advocating doing this, just pointing out that it has little difference
from ULA.

> Then you are not @#$!# paying attention.

Sure I am. The fact that I don’t agree with you and don’t share your perspective
doesn’t mean I’m not paying attention.

> don't collide and to then stop using the ones that collided.

I didn’t say anything about this… My point was that your claim that a border
router should never forward a ULA packet was patently false and you just
proved my point.

> There is no time bomb.  Only the illusion of a time bomb.

Only if you have fully coordinated ULA which there is no supporting RFC to
provide. Sure there are an assortment of ULA registries out there (which do
happen to in several cases already collide with each other), but short of the
two sites that later collide using the same registry, yes, there is an actual
time bomb.

Owen

---

From: David Farmer <[email-masked]>
Date: Thu, 12 Nov 2015 19:47:42 -0600

> [1] http://www.ifc.org/wps/wcm/connect/9ae1dd80495860d6a482b519583b6d16/MSME-CI-AnalysisNote.pdf?MOD=AJPERES

Flipping that around, how many Large Enterprises are there in the world? 
  I found about 16K for the US.  So, expand that globally, that 
shouldn't be insane to think about for the number of PI blocks in the 
global IPv6 route table.

Like has been said they won't happen all at once and I sure even some of 
them will do PA anyway.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 11:11:27 +0900

> PI for all customers is antiCIDR, and that's a problem.

The solution is there - it's multihoming using src+dst routing. This is
what we should be recommending.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 15:27:36 +1300

> what we should be recommending.

Like draft-ietf-6man-multi-homed-host does, you mean? I can't possibly disagree ;-)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Nov 2015 15:32:59 +1300

On 13/11/2015 14:47, David Farmer wrote:
> Flipping that around, how many Large Enterprises are there in the world?  I found about 16K for the US.  So, expand that
> globally, that shouldn't be insane to think about for the number of PI blocks in the global IPv6 route table.
> 

Absolutely not, a few hundred thousand PI prefixes are not very alarming.
It's when we get to millions that PI becomes a possible heresy.

    Brian

> Like has been said they won't happen all at once and I sure even some of them will do PA anyway.
>

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Nov 2015 10:06:47 +0900

On 11/13/2015 09:10 AM, Lorenzo Colitti wrote:
> On Tue, Nov 10, 2015 at 11:13 PM, Eric Vyncke (evyncke)
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     It is only 'slightly' easier... Because guessing the TCP sequence
>     number of the other party... Well good luck :-)
> 
> 

You still need to guess the port numbers. And if you're able to, that's
a sign there's something you still need to fix (see RFC6056).

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Nov 2015 10:04:18 +0900

> to be tampered with in flight.

FTP PORT doesn't work fine in firewalled environments. It requires a
middlebox to tap into the FTP control protocol so that the fw can open
the necessary holes. -- So the only networks where FTP PORT works fine
is un-NATed, unfiltered networks -- which is kind of Wonderland.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Nov 2015 10:27:50 +0900

Owen,

On 11/13/2015 03:21 AM, Owen DeLong wrote:
> 
>> On Nov 10, 2015, at 06:13 , Eric Vyncke (evyncke) <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> the endpoints need to do is send each other packets at about the same
>>> time. In the latter, they need to implement NAT traversal via relays.
>>
> With a diode firewall, you don’t have to guess. Most diode firewalls
> don’t look at TCP sequence numbers actively. They look only at the L3
> and L4 identifiers to determine state.
> Nonetheless, it’s also much easier because a diode firewall can easily
> be given an exception to permit a particular flow or the initiation of a
> class of flows to a particular protected host or set of hosts.

The problem is how to do this automagically.

> In the case of a NAT, however (more specifically a NAPT), it is not
> possible to program multiple port 80 terminations to land on different
> hosts behind the NAT.

That's like saying that the problem with cars is that they cannot fly --
yes, that's what a NAT is.

I might also add that this is another kludge that is made evident by
NAT: there's no reason whatsoever for which a given service should run
in any specific transport protocol port. Consider that a kludge or
shortcut than a principle.

> I retain my perspective that one of the worst and most ultimate forms of
> layering violation is for a forwarding system not residing on either of
> the end-hosts in a session to impersonate an end-host and mutilate
> unexpected portions of the datagram in flight.

I might grant that one if you want. But virtualy everything that you
mentioned that NAT breaks are shortcuts (or flawed design) rather than
"principles" we should stick to.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 11:59:37 +0900

> a sign there's something you still need to fix (see RFC6056).

The port numbers are no more a guess than the IP addresses are. Whatever
told you the IP addresses can also tell you the port numbers.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 12:24:20 +0900

> Like draft-ietf-6man-multi-homed-host does, you mean? I can't possibly

Well, the hard part is not the host, but the network... but still, good
that we agree :-)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Nov 2015 12:36:45 +0900

On 11/13/2015 11:59 AM, Lorenzo Colitti wrote:
> On Fri, Nov 13, 2015 at 10:06 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

So: You want to talk to me, but I don't accept incoimng connections. I
want to talk to you, but you don't accept incoming connections.

You claim that it is simpler to achieve that with NATs, than with FWs.
How would that happen without relying on a third party, and without
guessing port numbers to fake e.g. a TCP simultaneous open?

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 12:53:59 +0900

> guessing port numbers to fake e.g. a TCP simultaneous open?

The IP addresses and port numbers could be signaled out of band using
another mechanism (NFC, bluetooth, email, smoke signals, well-known ports,
whatever). If you don't use NAT, the two parties have all the information
they need and the communication can be entirely peer-to-peer with no third
party involved. If you do NAT, you have to involve a third party, and
depending on how draconian the NAT is, that third party might have to be
proxy all the traffic for the duration of the connection. That's high cost,
high latency, and low quality.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 13 Nov 2015 01:15:00 -0300

whatever).

And for that signaling you need.... a third party.

Si it ends up being a discussion of what type of third party one hates the
most.

As noted, shortcuts in the current in the current architecture should not
be interpreted as design principles.. NATs happen to make this very
evident. Don't shoot the messenger for this.

If a network has a policy of only allowing outgoing connections, then any
workaround to do that is an attack on that policy. And making.that
workaround more difficult can thus be seen as a feature.

Fernando

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 20:49:02 -0800

> On Nov 12, 2015, at 17:04 , Fernando Gont <[email-masked]> wrote:
> 

FTP is not the only protocol being discussed and there are actually a variety
of alternative ways to solve the FTP PORT problem that do not require
removing the firewall or having an unfiltered network.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 12 Nov 2015 20:53:07 -0800

> On Nov 12, 2015, at 17:27 , Fernando Gont <[email-masked]> wrote:
> 
> Owen,
> 

Why does it have to be automagic?

> yes, that's what a NAT is.

Well… That is certainly a limitation of most automobiles, but I’m happy to
report that there are working alternatives such as the Terrafugia Transition
and some older prototypes as well.

> shortcut than a principle.

Meh… There’s no mechanism available for signaling port numbers in response
to name lookups (modulo SRV records that don’t seem to be very popular in
practice). There are certain advantages to the idea of well known port numbers
and whether or not you consider them a kludge, they are certainly in widespread
use and have a great deal of history and support in the IETF and IANA.

> "principles" we should stick to.

We can agree to disagree as we so often do.

Owen

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 13 Nov 2015 07:59:49 +0000

A those lively NAT discussions...

I agree with Lorenzo: ports are 'just' an extension of the IP address and can be negotiated (SDP for example). Also agree with Fernando: add a 3rd party (or a 4th one -- double NAT) and your problems come.

And there are at least one firewall which checks the TCP sequence numbers, so, any attempt to 'bypass' the diode-like function by sending SYN on one side and SYN+ACK on the other side will also require to negotiate the TCP sequence numbers... And those are outside the realm of the user space application

-éric

From: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Date: vendredi 13 novembre 2015 03:59
To: Fernando Gont <[email-masked]<mailto:[email-masked]>>
Cc: Eric Vyncke <[email-masked]<mailto:[email-masked]>>, IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

The port numbers are no more a guess than the IP addresses are. Whatever told you the IP addresses can also tell you the port numbers.

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 09:05:08 +0100

Hi,

> what we should be recommending.

And to chime in: I see this as a good and viable solution for end users
and "small shop multihoming" - small shop being: no externally visible
stuff hosted locally, no inbound VPN stuff, no firewall rules elsewhere
that reference these IPv6 prefixes, etc. - "your typical barber shop".

There are bits and pieces missing to make this a complete solution
(namely, source address failover or "source address happy eyeballs"),
but if these show up, the solution is actually more flexible and more
powerful than BGP-based stuff.   You want bittorrent from your machine
to take another upstream than your ssh sessions?  "just pick the proper
source address"...  (and yes, work is needed here)

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 20:11:09 +0900

> And for that signaling you need.... a third party.
Not for NFC, bluetooth, smoke signals, or well-known ports you don't. And
even if you do need a third party, there's a huge difference between a
third party that relays / snoops your traffic vs. a third party that just
puts the two parties in touch and then disappears from the equation.

> evident. Don't shoot the messenger for this.
And we come around to the previous argument. The situation is not that we
are shooting NAT for coming and telling us the architecture is broken. The
situation is that we are shooting NAT for breaking it.

> workaround more difficult can thus be seen as a feature.
Such a policy is misguided because it ignores the reality that today
outgoing connections are just as dangerous as incoming ones, if not more.
We need a better reason to break the architecture than misguided policies.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 20:12:12 +0900

On Fri, Nov 13, 2015 at 4:59 PM, Eric Vyncke (evyncke) <[email-masked]>
wrote:

> I agree with Lorenzo: ports are 'just' an extension of the IP address and
> can be negotiated (SDP for example). Also agree with Fernando: add a 3rd
> party (or a 4th one -- double NAT) and your problems come.
>
> And there are at least one firewall which checks the TCP sequence numbers,
> so, any attempt to 'bypass' the diode-like function by sending SYN on one
> side and SYN+ACK on the other side will also require to negotiate the TCP
> sequence numbers... And those are outside the realm of the user space
> application
>

Absolutely. There are firewalls that only allow through pink packets on
Tuesdays. But checking the sequence number won't help with UDP.

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 13 Nov 2015 11:16:42 +0000

Absolutely. There are firewalls that only allow through pink packets on Tuesdays. But checking the sequence number won't help with UDP.

And yellow packets on Fridays. And, the absence of 'states' in UDP packet is one reason why some edge security policy block UDP

-éric

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 20:18:42 +0900

> (namely, source address failover or "source address happy eyeballs"),

I think you can address most of this by deprecating addresses when an
upstream goes away.

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 12:21:41 +0100

Hi,

> I think you can address most of this by deprecating addresses when an

Networks break further upstream, without the actual upstream being noticeable
broken.  Networks break certain paths, while others are working fine.

We can do better than all-or-nothing.  We should.

Gert Doering
        -- NetMaster

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 13 Nov 2015 20:25:53 +0900

On Fri, Nov 13, 2015 at 8:21 PM, Gert Doering <[email-masked]> wrote:

> Networks break further upstream, without the actual upstream being
> noticeable broken.  Networks break certain paths, while others are working
> fine.
>

True, but this happens today with RFC1918+NAT multihoming as well.

> We can do better than all-or-nothing.  We should.

Agreed. But even if we don't, we won't be making things worse.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 13 Nov 2015 13:49:13 +0100

>noticeable

I don't think a host should try to figure out which paths work and which
don't.

Maybe somebody can come up with a simple algorithm that generalises
happy-eyeballs and that is compatible with today's host operating systems.
But I doubt it. 

So while we wait for hosts to magically figure out what works and what doesn't
(and for mobile hosts, in any possible context, even when there is
high packet loss on the local link, etc),

I propose that routers just inform hosts which source prefixes are unusable
according to unspecified monitoring code running on the router. (Obviously,
routers should also propate that knowledge over internal routing protocols in
setups with multiple routers).

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 Nov 2015 13:49:24 +0100 (CET)

> rebels have become the empire?

I have been involved in Internet core routing for 15 years. I've seen the 
routing table grow from around 100k entries, to 650k or so. Yet, as far as 
I can tell, state of the art platforms still can't install routing updates 
faster than around 10k prefixes per second, which is not significantly 
faster than 15 years ago.

What has changed is a lot of advanced mechanisms to work around this 
problem, plus faster CPUs so changes propagate faster so we have less 
flapping of routes.

No significant improvement in the routing system has happened during this 
time, and I don't see any in the works. Doing route lookups is costly, 
larger tables mean more power consumption etc.

I'm sure we can design routers that can handle 10x the prefixes they can 
today, but at what cost?

Also, why should a core router in Europe have to care about an office 
connection being affected by something on the other side of the globe? IP 
has become successful because the core doesn't have to keep state for 
L4 connections, but if we radically increase the state needed to be kept 
for L3 destinations, we will most likely run into problems. Yes, they 
might be solved, but currently we do not know how.

So I would very much like to stay away from an architecture that suggests 
"PI for everybody".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 14:18:19 +0100

Hi,

> I don't think a host should try to figure out which paths work and which

I disagree, and strongly so.  Maybe not "probe all paths at the same time",
but if one is not working, it would be silly not to try alternatives if
they exist.

[..]
> setups with multiple routers).

So, if you have upstreams A and B, and targets C and D, of which "C" cannot
be reached over "A" and "D" not via "B" (not all that unlikely given the
direction in which low-price SoHo ISPs and peering wars are developing),
would you rather declare both broken, or just use B to reach C, and A to
reach D?

Defining "the upstream is broken" is actually fairly hard - the router might
be perfectly happy about upstream A, because 99% of its monitoring targets
work perfectly well - but if the user's 1% that he wants to talk to do not
work (routing hickup, anycast cluster broken, peering overloaded), it is
the wrong conclusion to declare "it is working, no need to try anything
else"...

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Fri, 13 Nov 2015 14:23:29 +0100

Gert,

> the wrong conclusion to declare "it is working, no need to try anything

exactly. the end-points has much more information about the end to end path than the first-hop router has.
unless you want it to be a DPI/layer violating/state-hogging middlebox.
even having every router participate in global routing wouldn't help you very much. global routing has convergence times measured in many minutes.

cheers,
Ole

---

From: Michael H Lambert <[email-masked]>
Date: Fri, 13 Nov 2015 08:27:24 -0500

> On 13 Nov 2015, at 07:49, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Also, why should a core router in Europe have to care about an office connection being affected by something on the other side of the globe?

Indeed.  Unless one is intentionally trying to design a chaotic system.

Michael

---

From: Philip Homburg <[email-masked]>
Date: Fri, 13 Nov 2015 14:40:19 +0100

>but if one is not working, it would be silly not to try alternatives if

Given the current interfaces in mainstream operating systems and lack of
specified algorithms, I'm not holding my breath until this happens on a
large scale.

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 14:43:13 +0100

Hi,

> specified algorithms, I'm not holding my breath until this happens on a

"Not holding your breath" is sort of the wrong answer to "the IETF should get
busy and solve this", no?

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Nov 2015 13:47:03 +0000

> Indeed.  Unless one is intentionally trying to design a chaotic system.

The type of chaos which which involves most ASNs having a full view of the
Internet is less bad than the type where only a handful of them do.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 Nov 2015 14:50:15 +0100 (CET)

> Internet is less bad than the type where only a handful of them do.

If the Internet will have 10x the number of routes it has today in the 
not-so-distant-future, there is a considerable risk that most smaller 
players won't be able to afford to have a full view.

I already know people today who do route filtering because their 
devices might only have 256k TCAM slots.

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Nov 2015 14:32:18 +0000

> On 12 Nov 2015, at 23:50, Brian E Carpenter <[email-masked]> wrote:
> 

Not sure that last point is strictly true…

Tim

---

From: Tim Chown <[email-masked]>
Date: Fri, 13 Nov 2015 14:47:02 +0000

> On 13 Nov 2015, at 13:23, [email-masked] wrote:
> 
> Gert,
> 
> unless you want it to be a DPI/layer violating/state-hogging middle box.

Which is a very important point, and a big argument for src+dst based host decisions. And we’ve already seen some early demonstrators in home net / hackathons in recent IETFs.

Tim

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Nov 2015 15:53:01 +0000

Another usage for out GPU?

Pascal

> Le 13 nov. 2015 à 14:50, Mikael Abrahamsson <[email-masked]> a écrit :
> 
> If the Internet will have 10x the number of routes it has today in the not-so-distant-future, there is a considerable risk that most smaller players won't be able to afford to have a full view.
> 
> I already know people today who do route filtering because their devices might only have 256k TCAM slots.
> 
> --

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 09:31:24 -0800

> On Nov 13, 2015, at 03:16 , Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
>> 

And yet DNS almost always works and you can already find open source software that implements a full dual-stack tunnel capability in the form of DNS request/response packets.

Run that on a public DNS server somewhere, register it as authoritative for some random zone and the firewall is out the window.

If you allow outbound connections and someone on the inside wants to allow inbound connections, they can, whether you like it or not.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 09:39:35 -0800

> I'm sure we can design routers that can handle 10x the prefixes they can today, but at what cost?
> 
> Also, why should a core router in Europe have to care about an office connection being affected by something on the other side of the globe? IP has become successful because the core doesn't have to keep state for L4 connections, but if we radically increase the state needed to be kept for L3 destinations, we will most likely run into problems. Yes, they might be solved, but currently we do not know how.
> 
> So I would very much like to stay away from an architecture that suggests "PI for everybody".

The alternative perspective is that because we’ve been able to avoid this issue by treating most of the internet users as second-class citizens, we have chosen not to put resources into solving it.

Perhaps it is time to stop treating internet users as second-class citizens and actually put resources into solving this problem in a meaningful way.

It is truly unfortunate that the IETF deliberately punted on this issue during the development of IPv6. I believe this decision was driven by a number of the larger ISPs of the day (carriers) pushing to maintain CIDR as a mechanism of customer lock-in and exacerbated by sheer laziness from others.

I believe that an extra 32-bit field in the IPv6 header could have provided a significant step towards solving this problem by encoding the destination transit AS in the packet at the first router capable of resolving that information and then routing on that basis in the IDR realm. In that case, stub networks (non-transit autonomous systems) would not need to be visible in BGP and we would not need to track prefix state beyond the closest transit ASNs. A separate map of Prefix->Candidate Transit ASNs could be maintained through a mechanism somewhat similar to DNS.

Unfortunately, we don’t have the bits to do this in the IPv6 header and the solution will now be harder.

Owen

---

From: David Conrad <[email-masked]>
Date: Fri, 13 Nov 2015 10:20:02 -0800

> I doubt that all but a small fraction of those SMEs actually need multihoming.

Really? This strikes me as IPv4-think. Given the migration to the cloud, the availability of multiple layer 2 infrastructures (particularly in the wireless space) which will likely drive down costs, and the increasing dependence upon "the cloud" for everything from traditional Internet services to the "Internet of Things" (whatever that means), I would think the future will be rife with multihoming for reliability/resiliency reasons, and not just by Es (SM or otherwise), but by residentials as well.

> But even for those that do - we should be working on making it possible to multihome using src+dst routing, not NPT66 or NAT66.

Since renumbering remains "hard" (for some value of that variable), I personally think the largest driver for NPT66/NAT66 is people not wanting to be locked into an ISP and not wanting to bother with the RIR nonsense and cos, not multihoming (currently)t.  When the cost of getting a PI prefix is significantly higher than what you pay for Internet connectivity, PA+NAT is a natural outcome for IPv6, just as it was for IPv4.

Regards,
-drc

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 19:41:51 +0100

Hi,

> I believe that an extra 32-bit field in the IPv6 header could have provided a significant step towards solving this problem by encoding the destination transit AS in the packet at the first router…

So you're in the LISP "we noticed that route caches do not scale, but we
try again and again" camp now?

Gert Doering
        -- NetMaster

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 10:54:31 -0800

> On Nov 13, 2015, at 10:41 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

Who said anything about a route cache?

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Nov 2015 07:58:36 +1300

> Not sure that last point is strictly true…

Well, it seems implicit in HNCP to me.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Nov 2015 08:02:03 +1300

> happy-eyeballs and that is compatible with today's host operating systems.

We tried. It's called shim6. Firewalls break it.

   Brian

---

From: Philip Homburg <[email-masked]>
Date: Fri, 13 Nov 2015 20:19:19 +0100

>We tried. It's called shim6. Firewalls break it.

I'd call shim6 a protocol and not an algorithm. Happy eyeballs is quite 
compatible with firewalls, NAT, etc. No problem there. I'm sure happy
eyeballs-like approaches can be tried for the multiple-prefix case.

The problem I ran into is that by the time my happy eyeballs implementation
did everything I wanted it do, it was way to complex. Adding support for
many source prefixes would just be too much.

Now, maybe somebody can come up with an approach that doesn't have that
problem. Don't know.

Mean while, I have something that works with every operating system today.
It may not be perfect. So I'm not terribly motivated to add more host
complexity to solve those edge cases.

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 Nov 2015 20:21:41 +0100

Hi,

> Who said anything about a route cache?

So you want to do the map lookup every time a packet traverses one of
these routers?  Or should the Prefix->Candidate Transit ASNs map be
distributed everywhere, like, with BGP, so all these routers get to hold
100M map entries all the time?

Gert Doering
        -- NetMaster

---

From: "Howard, Lee" <[email-masked]>
Date: Fri, 13 Nov 2015 19:41:52 +0000

I apologize for not continuing to ride herd on this thread since returning
from the IETF meeting.

Please, let us focus on this document in this thread.
Other IPv6 operational issues should get a different subject line.
Proposals for maintenance updates to the IPv6 protocol should go to 6man.
Proposals for fundamental changes should go to the IESG or IAB.

Lee

On 11/13/15, 12:39 PM, "v6ops on behalf of Owen DeLong"
<[email-masked] on behalf of [email-masked]> wrote:

>>connection being affected by something on the other side of the globe?
>>IP has become successful because the core doesn't have to keep state for
>The alternative perspective is that because we¹ve been able to avoid this
>issue by treating most of the internet users as second-class citizens, we
>have chosen not to put resources into solving it.
>
>Perhaps it is time to stop treating internet users as second-class
>citizens and actually put resources into solving this problem in a
>meaningful way.
>
>It is truly unfortunate that the IETF deliberately punted on this issue
>during the development of IPv6. I believe this decision was driven by a
>number of the larger ISPs of the day (carriers) pushing to maintain CIDR
>as a mechanism of customer lock-in and exacerbated by sheer laziness from
>others.
>
>I believe that an extra 32-bit field in the IPv6 header could have
>provided a significant step towards solving this problem by encoding the
>destination transit AS in the packet at the first router capable of
>resolving that information and then routing on that basis in the IDR
>realm. In that case, stub networks (non-transit autonomous systems) would
>not need to be visible in BGP and we would not need to track prefix state
>beyond the closest transit ASNs. A separate map of Prefix->Candidate
>Transit ASNs could be maintained through a mechanism somewhat similar to
>DNS.
>
>Unfortunately, we don¹t have the bits to do this in the IPv6 header and
>the solution will now be harder.
>
>Owen
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 12:39:55 -0800

> On Nov 13, 2015, at 11:21 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

There’s a difference between caching part of a  map in RAM for active flows and
having to cache an entire routing table for all possible destinations with full path
information and multiple alternatives.

One is a very large data structure for each possible path.

Also, the lookup doesn’t have to be performed by every router in the path, just the
first IDR capable router in the path.

So this is very different from the LISP approach.

Owen

---

From: [email-masked]
Date: Fri, 13 Nov 2015 21:50:39 +0100 (CET)

> There$,1ry(Bs a difference between caching part of a  map in RAM for active flows and

Caching active flows has been tried before, repeatedly, and unfortunately
it doesn't scale.

Steinar Haug, AS 2116

---

From: Mark Andrews <[email-masked]>
Date: Sat, 14 Nov 2015 08:10:15 +1100

> complexity to solve those edge cases.

The simplest way will probably be to extend getaddrinfo to return
pairs of address and just work down the list until you get a working
connection starting new ones relatively quickly after waiting 50
ms or so between first few to reduce the number of embryonic connects
that you kill when you get success.  It adds one more system call
to the default loop when starting a tcp connection.

	socket, fcntl, fcntl, bind, connect, select/poll

		vs

	socket, fcntl, fcntl, connect, select/poll

For subsequent connections to the same node from the same application
for the same session you just re-use the discovered pair of addresses.

Mark

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Nov 2015 21:39:39 +0000

> players won't be able to afford to have a full view.

the dfz is growing linearly at ~50k prefixes/year.  On this basis, 10x the
number of prefixes is a very long way away.

Nick

---

From: David Farmer <[email-masked]>
Date: Fri, 13 Nov 2015 17:37:02 -0600

> Please, let us focus on this document in this thread.

So, I think we are going with some from of "NPT66 and NAT66 are not 
recommended" along with pointers to what breaks if you use NPT66 or 
NAT66, section 5 of RFC6296, RFC4864, RFC2993, etc...

What about addressing solutions to the issues that are driving some to 
consider NPT, which I think are multihoming, provider lock in, and 
fundamentally renumbering.  So maybe reference LISP (RFC6830), ILNP 
(RFC6740), renumbering (RFC5887), and maybe the Home Net architecture 
(RFC7368).

Other suggestions?

It's not an effective argument to say; "Don't do that, because we said 
so, and we don't know what you should do, just not that."

To be effective besides telling people "don't do that", we need to tell 
them "why they shouldn't" and probably more important "what the 
alternatives are".

So "NAT is harmful" is not an effective argument.

Thanks

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 14 Nov 2015 10:54:21 +0900

On Sat, Nov 14, 2015 at 6:10 AM, Mark Andrews <[email-masked]> wrote:

> It adds one more system call

... until you realize that bind() doesn't actually affect routing.

---

From: Mark Smith <[email-masked]>
Date: Sat, 14 Nov 2015 13:39:49 +1100

<snip>

> (d) use whatever string of {32,48,64} bits you want and pretend it’s

That's stealing space and will most certainly happen if there is no
proper local and free address space to use instead. (I'd have done
that if there weren't site-locals when I first wanted to run up IPv6
at home just to get some experience with it.)

> for addresses for smaller users.

Zero cost is what is needed.

You can only charge money for magic numbers because of the magic, not
the numbers. The numbers themselves are free, because anybody can make
them up.

The magic you're buying or renting when you get RIR space is:

- actively managed global uniqueness (although not absolutely
guaranteed, because of the human error factor)

- implicit acceptance of routes for that space by networks that carry
the DFZ route table

The first property is really a requirement and necessity demanded by
the second one.

If people don't need the magic of implicit acceptance in the DFZ, why
should they have to pay for it? That is the unnecessary tax or cost on
enabling IPv6 that you're creating by saying people should be required
to use RIR space, even if they have no intention of having the
corresponding local address space routes in the DFZ.

If people later need the magic of implicit acceptance in the DFZ, they
can get PA or PI, and most importantly add it to their existing ULA
addressed network.

Renumbering is not required to add PA/PI, and that is where IPv6
provides a much better alternative than IPv4 - IPv4 demanded an
exclusive or between PA/PI address space and RFC1918s, and RFC1918s
were perceived to be cheaper and easier for a variety of reasons,
including because a 'magic translation box' could be used between
RFC1918s and PA/PI needed to reach the Internet.

In other words, in IPv4 we're forced into serial address spaces, where
as in IPv6 we have the opportunity for multiple parallel ones.

> > spa

>         1.      It’s good because it’s free PI address space.

It isn't "free PI address space", because it doesn't have the magic
that real PI address space has - implicit acceptance by all carriers
of the DFZ route table.

The only similar properties between PI and ULAs are the
(statistical/managed) global uniqueness.

>         2.      It’s bad because it’s a free end-run around the RIR policy processes.

Not if you can't successfully get it globally routed.

Here's the challenge for you. Show us how easy it is for you to get a
ULA of your choosing permanently accepted in all ASes who accept the
DFZ route table, at a cost and effort that is lower than using RIR PI
space instead.

> issues around source address selection, etc.

I've been running ULAs here at home more than 4 years, both with 6to4
IPv6 connectivity, and for the last 4 years native connectivity. I
haven't seen any issues, or if there have been any, they've been
overcome transparently via such things as Happy Eyeballs. (with the
caveat that all my hosts are fundamentally Linux, although various
distros - Fedora, Android, Chromecast and Chrome OS.)

More recently, anybody who has been running IPv6 on OpenWRT since
BarrierBreaker 14.07, released on 30th of September 2014, has had an
ULA prefix automatically generated and announced to hosts on the LAN
interfaces. Via a few Internet searches, I can't find any reports of
issues relating to OpenWRT and automatic ULAs in the last 2 years.

Regards,
Mark.

---

From: Octavio Alvarez <[email-masked]>
Date: Fri, 13 Nov 2015 18:47:39 -0800

> complexity to solve those edge cases.

Can you elaborate on your approach?

Thanks.

---

From: Joe Touch <[email-masked]>
Date: Fri, 13 Nov 2015 18:50:12 -0800

> On Nov 13, 2015, at 5:54 PM, Lorenzo Colitti <[email-masked]> wrote:
> 

Routing can be source dependent, e.g., policy routing. 

Joe

---

From: Owen DeLong <[email-masked]>
Date: Fri, 13 Nov 2015 19:18:35 -0800

> Zero cost is what is needed.

I think a nominal fee (say US$25/year) wouldn’t represent a significant barrier.

> guaranteed, because of the human error factor)

To the best of my knowledge there are all of 3 instances of non-uniqueness
temporarily resulting from such errors in all of internet history and all in IPv4
or ASNs.

> - implicit acceptance of routes for that space by networks that carry

Really? I don’t think so.

> The first property is really a requirement and necessity demanded by

Certainly the second cannot function with the first, yes, but the first
property is oh so desirable for so many other reasons.

> corresponding local address space routes in the DFZ.

If it isn’t connecting to the global internet than it doesn’t matter what numbers
you make up or whether they are unique or how you go about making them
up. It’s not stealing space, it’s just using random numbers that aren’t actually
internet addresses because you happen to be running the same protocol on
your disconnected network as most networks run on the internet.

> can get PA or PI, and most importantly add it to their existing ULA

With all the attendant problems that have been repeatedly discussed.

> RFC1918s and PA/PI needed to reach the Internet.

I can put an RFC1918 address and a GUA IPv4 address on the same
interface on any modern host as well. This is no different from IPv6.

There is no meaningful difference in this regard. ULA is just RFC1918
with more addresses available for stupid host tricks.

> as in IPv6 we have the opportunity for multiple parallel ones.

This statement is not reality on any modern system.

> that real PI address space has - implicit acceptance by all carriers

Neither does real PI space. This is a figment of your imagination.

> (statistical/managed) global uniqueness.

Not at all true…

In fact, those are arguably the only differences.

They are both prefixes of 128 bit numbers, usually in /48 chunks.
They are both intended for numbering interfaces on devices running the IPv6 protocol.
They are both capable of being forward by routers.
Both can be described and routes distributed via OSPFv3, ISIS, and BGPv4.

The only real difference between ULA and PI is the convention of not routing
ULA across borders where administrators choose to enforce and/or abide by
said convention and the fact that anyone can make up whatever ULA address
they want, where there is an expectation that PI is coordinated through an RIR,
though there is enough history of hijacking in IPv4 prefixes that I see no reason
to believe this will not occur with IPv6.

> Not if you can't successfully get it globally routed.

I assert that this is simply a matter of the right number of “wombats” placed
in the right pockets. (To use a term coined by Jan Zorz).

> DFZ route table, at a cost and effort that is lower than using RIR PI

The cost for the first people to do it will be extraordinarily high. As it becomes
more common practice, the price will drop.

> distros - Fedora, Android, Chromecast and Chrome OS.)

As has been repeatedly pointed out to you, the use in your home does not
constitute a comprehensive study of all possible or even all likely environments.
I have had multiple issues with source address selection in IPv6 in my environment,
especially on Apple equipment, even without using ULA. ULA would only make
the problem 10x worse.

> issues relating to OpenWRT and automatic ULAs in the last 2 years.

I briefly had a router that did that to my network. That option was quickly turned
off to resolve the myriad problems it created. Subsequently, that router was
abandoned in favor of a router I didn’t have to keep beating about the head
and shoulders to prevent it from damaging the network in unexpected ways.

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 14 Nov 2015 06:52:08 +0100 (CET)

> number of prefixes is a very long way away.

And you think this is going to continue in the future if we say "PI is the 
preferred way to multihome and please RIRs, make it as easy as possible 
for people to do this" ?

---

From: Philip Homburg <[email-masked]>
Date: Sat, 14 Nov 2015 12:05:54 +0100

>preferred way to multihome and please RIRs, make it as easy as possible 

PI space is EUR 50 per year in the RIPE region, isn't it? Doesn't sound like
a barrier to obtaining some.

Of course, having PI space is useless if your ISP doesn't want to announce
it for you.

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 12:14:12 +0100

Hi,

> ... until you realize that bind() doesn't actually affect routing.

It totally does, at least in the context we're discussing here (dual-/48
style multihoming with src-dependent routing).

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 12:19:33 +0100

Hi,

> a barrier to obtaining some.

Having to deal with that every year is a hassle unless you really want
PI - in which case, it is not.  It's actually a nicely balanced hurdle.

Making it free would encourage everyone and their dog to get a block, 
whether they need it or not.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Sat, 14 Nov 2015 12:29:38 +0100

>whether they need it or not.

It struck me that PI in the RIPE region is similar to getting a DNS domain.
There is a registry (for PI in the RIPE region that would be the RIPE NCC)
and there are registrars (that would be the LIRs in the RIPE region)

For a DNS domain, registrars have completely automated process where you
pick the name, fill in the nameservers, pay, etc. Usually you can pay for
multiple years in advance, so doesn't take too much time.

It seems to me that the same model could apply to PI if it would get 
popular. Though I have to admit, I never bothered to look into the 
actual procedures for getting PI space. Maybe you have to show up in 
person in Amsterdam :-)

---

From: Owen DeLong <[email-masked]>
Date: Sat, 14 Nov 2015 04:04:17 -0800

> On Nov 14, 2015, at 03:05 , Philip Homburg <[email-masked]> wrote:
> 

HE will announce anyone’s PI /48 for free on request if they have an ASN.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Nov 2015 07:10:19 +1300

> HE will announce anyone’s PI /48 for free on request if they have an ASN.

Explain how that works when there are ten million of them.

   Brian

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 19:14:03 +0100

Hi,

> actual procedures for getting PI space. Maybe you have to show up in 

It is similar to the DNS process.  And, as you might have noticed, not
every Internet user in the world has their own domain.  qed. :)

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Sat, 14 Nov 2015 19:15:38 +0100

Hi,

On Sat, Nov 14, 2015 at 04:04:17AM -0800, Owen DeLong wrote:
> HE will announce anyone???s PI /48 for free on request if they have an ASN.

So, where can I order a DSL circuit to my home from HE, for competitive
pricing, with the /48 added in for free?

See how absurd that argument is?  PI that I have to get someone to tunnel
to me over IPv4 (which I might not even have anymore) is not exactly useful.

Gert Doering
        -- NetMaster

---

From: Octavio Alvarez <[email-masked]>
Date: Sat, 14 Nov 2015 11:48:15 -0800

> a barrier to obtaining some.

Unfortunately that is not the same in the LACNIC region. Assignment is 
2,500 USD + 600 USD yearly. This doesn't consider the ASN.

It is definitely for enterprises and large organizations only.

Best regards.

---

From: Owen DeLong <[email-masked]>
Date: Sat, 14 Nov 2015 16:52:12 -0800

> On Nov 14, 2015, at 10:10 , Brian E Carpenter <[email-masked]> wrote:
> 

I don’t know, but I don’t think that’s a realistic number in any sort of immediate timeframe.

My guess would be that it will take quite some time before we face that issue and that by then
if we haven’t figured it out, we’re going to have some pretty big problems regardless of whether
or not SMEs are using PI /48s.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 14 Nov 2015 16:54:20 -0800

> On Nov 14, 2015, at 10:15 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

You can use any DSL circuit you want. HE’s stuff operates over a tunnel.

> to me over IPv4 (which I might not even have anymore) is not exactly useful.

I don’t know whether HE will tunnel it over IPv6 or not. I do know that there are
others who will, though not for free.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sat, 14 Nov 2015 17:01:42 -0800

> On Nov 14, 2015, at 11:48 , Octavio Alvarez <[email-masked]> wrote:
> 
> Unfortunately that is not the same in the LACNIC region. Assignment is 2,500 USD + 600 USD yearly. This doesn't consider the ASN.
> 

Everything internet related seems to cost too much in the LACNIC region.

I’m not sure why this problem persists so much, but I do hope it improves over time.

It’s absurd to see companies charging $30, $50, or in some cases even $100/Mbit when just the other side
of the Rio Grande, you can get tens of Gigabits for less than $0.40/Megabit.

Owen

---

From: Mark Smith <[email-masked]>
Date: Sun, 15 Nov 2015 21:11:36 +1100

> I think a nominal fee (say US$25/year) wouldn’t represent a significant barrier.

It's $25 p.a. that can't be spent on something else.

> Really? I don’t think so.

Why not?

> property is oh so desirable for so many other reasons.

I agree, which is why I think ULAs are much better than site-locals.

> With all the attendant problems that have been repeatedly discussed.

Can you enumerate them for me please?

> interface on any modern host as well. This is no different from IPv6.

*You* can put two addresses on a interface. DHCPv4 can't, and the
protocol stack treats the addresses/subnets as though they were
assigned to different interfaces/links.

See above.

> Neither does real PI space. This is a figment of your imagination.

"Implicit" is a form of the word "implied". Implied doesn't guarantee
they will be accepted by all networks carrying DFZs. It means of all
of the IPv6 address space, PI is most likely to be accepted by
networks carrying DFZ, because most people who carry DFZ routes have a
default accept policy, and only drop a small subset of routes (their
own PI/PA etc.)

> in the right pockets. (To use a term coined by Jan Zorz).

And it would be a terrible way to spend your "wombats".

> The cost for the first people to do it will be extraordinarily high.

Right. That creates a massive incentive to use the much cheaper RIR PI
space to more easily and quickly achieve the same goal.

> As it becomes

I never claimed it was.

It is operational experience with ULAs in one type of environment, and
it is a piece of empirical evidence that seems to disprove your
assertions that ULAs will only cause trouble.

> and shoulders to prevent it from damaging the network in unexpected ways.

"your home does not constitute a comprehensive study of all possible
or even all likely environments."

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Nov 2015 23:01:20 +0900

On 11/13/2015 08:11 PM, Lorenzo Colitti wrote:
> On Fri, Nov 13, 2015 at 1:15 PM, Fernando Gont
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> The IP addresses and port numbers could be signaled out of band
>> using another mechanism (NFC, bluetooth, email, smoke signals,
>> well-known ports, whatever).
> 
> Not for NFC, bluetooth, smoke signals, or well-known ports you
> don't. And even if you do need a third party, there's a huge
> difference between a third party that relays / snoops your traffic
> vs. a third party that just puts the two parties in touch and then
> disappears from the equation.

Could you please elaborate how this would work:

1. A is behind a diode firewall
2. B is behind a diode firewall
3. A initiates a TCP connection with B.

>> As noted, shortcuts in the current in the current architecture should
>> not be interpreted as design principles.. NATs happen to make this
>> very evident. Don't shoot the messenger for this.
> 
> And we come around to the previous argument. The situation is not
> that we are shooting NAT for coming and telling us the architecture
> is broken. The situation is that we are shooting NAT for breaking
> it.

I fully disagree. NAT can be the most evil device ever. But all this
things we've being talking about have to do with an incomplete
architecture that NAT is making evident rather than about a complete
architecture that NAT is breaking.

>> If a network has a policy of only allowing outgoing connections, then
>> any workaround to do that is an attack on that policy. And 
>> making.that workaround more difficult can thus be seen as a feature.
> 
> Such a policy is misguided

Says who? It's the policy that is being enforced. Period.

> because it ignores the reality that today 

I disagree. Your claim can be correct for an enterprise with BYOD. BUt
it is certainly not true for virtually every home network where a number
of devices are attached to it -- possibly un-updated, with bad defaults,
etc.

In any case it's possible to DoS a device with a single packet, or
worse, that you can root a device with a single packet (see one of the
few openbsd remotely exploitable vulns, alas IPv6-based), a diode
firewall would prevent such devices from being owned from the Internet.

(Not to mention reflection attacks, etc.)

This doesn't mean "yeah.. there couldn't be nothing evil inside", but is
rather along the lines of the principle of "least privilege" applied in
security -- "if I don't need something for ding what I need to do, then
I get read of it"... whether that's superuser privileges, or
connectivity privileges.

Yes... in general, your ability to play with my network is at odds with
my network's security.

> We need a better reason to break the architecture than

The only references to architecture have been shortcomings (e.g.,
well-known ports) r not-so-clean app design such as FTP PORT -- that
become evident with NATs. The rest is policy, not architecture.

In case it's not clear: it's perfectly understandable why many of such
things happened that way. What's not understandable is that we, 40 years
later, don't learn from history and consider "design principles" things
that are not.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Nov 2015 15:34:53 +0900

> 3. A initiates a TCP connection with B.

A and B exchange ports out of band using NFC. A says to B "I am at port
1111". B says to A "I am at port 2222". A binds to port 1111 and connects
to B port 2222. A's firewall creates a mapping A:1111 -> B:2222. At the
same time B binds to port 2222 and connects to A port 1111. B's firewall
creates a mapping B:2222->A:1111. Once both mappings are created, TCP works.

This works behind a simple stateful firewall, but does not work behind a
NAT because the port numbers are rewritten as well. Yes, if the firewall
checks the sequence numbers as well, then A and B need to agree on those
too. It's true that you can't do that as an unprivileged app on today's
host OSes, but rogue apps are certainly able to do this.

> architecture that NAT is breaking.

I know you disagree with that. All I'm saying is that we've gone back to
that.

> firewall would prevent such devices from being owned from the Internet.

But that's really hard. You have to scan Internet space at random, scanning
OUI space for remotely exploitable devices... much easier to use a browser
trojan to compromise the user's host and DOS the device from there.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Nov 2015 22:05:16 -0800

On 11/12/2015 07:53 PM, Lorenzo Colitti wrote:
> On Fri, Nov 13, 2015 at 12:36 PM, Fernando Gont <[email-masked]
> another mechanism (NFC, bluetooth, email, smoke signals, well-known
> ports, whatever). 

Yeah. You could also do all communication out of band, too. That's
handwashing -- the problem is still there, and you don't say how you
solve it, but kind of rather flag it as "out of scope".

---

From: Fernando Gont <[email-masked]>
Date: Sun, 15 Nov 2015 22:21:03 -0800

> Why does it have to be automagic?

Because the regular user is, alas, a user, and not a fw adminsitrator.

> and some older prototypes as well.

Then that's not a car. And that's my point. You're complaining about
something that is a characteristic of NAT.

That said, there's no conceptual reason for which HTTP must run at port
80. And would be perfectly sensible to have multiple instances of
different HTTP implementations at the same host, without having to
resort to other hacks such as ip aliases.

Again: here NATs are making it very evident that harcoding HTTP to port
80 comes at a price.

You don't want a full directory service? -- Fine... then pay the price
for taking a shortcut.

> practice). 

As you note, there is: SRV.

Regarding popularity, when did popularity became a metric of correctness?

> There are certain advantages to the idea of well known port numbers

Can we have a technical discussion, please?

I'm arguing that there are many pieces of the puzzle missing, and you
answer "having a full puzzle is not popular.. besides, everyone loves
it, and we have done it for a long time".

That's like arguing that McDonald's sells quality beef because their
restaurants are usually crowded, and Mc has made a lot of profit for years.

McD might make a lot of money. There might be certain advantages of
eating at McD (price (in some countries), timeliness, or whatever). But
that doesn't make a Big Mac good beef.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Nov 2015 11:56:53 -0800

> On Nov 15, 2015, at 02:11 , Mark Smith <[email-masked]> wrote:
> 
> On 14 Nov 2015 14:19, "Owen DeLong" <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> 

RIRs issue lots of space that may or may not get accepted by any given service provider.

There is nothing inherent in getting an allocation/assignment from an RIR that guarantees
you or even implies you will necessarily get a slot in any particular provider’s routing table.

True, it’s more likely than if you just make up random numbers, but it’s just more likely.

> I agree, which is why I think ULAs are much better than site-locals.

I fail to see the need or usefulness of either, TBH.

> Can you enumerate them for me please?

Review the record. They’ve been well documented and relate mainly to the fact that
most code is not well suited to having the host be multihomed and the APIs provide
poor concepts of application source address selection and the operating system
mechanisms such as they are are generally poorly implemented and even less well
understood by administrators and end users that need them.

> assigned to different interfaces/links.

Depends on the implementation, though I agree about DHCPv4, but that’s not
an inherent property of IPv4, that’s a limitation baked into the IPv4 implementation
of DHCP. In fact, if we taught hosts how to understand it, DHCPv4 could supply
additional addresses in an option field fairly easily and the hosts could easily
apply them to interfaces.

>> This statement is not reality on any modern system.

Stating it again doesn’t make it any less incorrect.

> default accept policy, and only drop a small subset of routes (their

In fact, most of them will also accept a fair amount of bogus space if you put it within
the right range. Making sure it is real PI doesn’t come with any magic. Making it less
likely to conflict with real PI may remove some perceived magic, but that’s not the
same thing.

> And it would be a terrible way to spend your "wombats”.

Perhaps, but that doesn’t mean there won’t come a day when someone chooses to do so.

> space to more easily and quickly achieve the same goal.

Thus obviating the need to have ULA in the first place.

> assertions that ULAs will only cause trouble.

I never said they would ONLY cause trouble… I stated that they do in some environments
cause trouble. You continue to assert that they won’t cause trouble contrary to my own
personal operational experience.

> or even all likely environments.”

Sure, but it does disprove your claim that ULA is harmless.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Nov 2015 12:11:46 -0800

> Says who? It's the policy that is being enforced. Period.

The author of that post for one.
Me for another.

> of devices are attached to it -- possibly un-updated, with bad defaults,

It absolutely is even more true in that case because if you allow those
hosts to make outbound connections, nothing prevents them from initiating
a TCP-based tunnel to a BOT CNC center which then fully opens inbound
access for exploitation regardless of NAT, diode firewall, or anything else.

This has happened more than once and you know it.

QED.

> firewall would prevent such devices from being owned from the Internet.

No… It just _MAY_ add to the steps necessary to do so. See above.

> I get read of it"... whether that's superuser privileges, or

Sort of, but there are other ways to achieve the same effect which
do a better job of accounting for the dangers of outbound connections
as well.

> Yes... in general, your ability to play with my network is at odds with

Sure, but the assumption that this relates to which direction connections
are allowed to be initiated is fundamentally flawed.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 16 Nov 2015 12:39:48 -0800

> something that is a characteristic of NAT.

By what possible definition do you claim that the Terrafugia Transition
is not a car? It is most certainly a car which is capable of doing all the
things a car does and is also capable of becoming an aircraft.

> resort to other hacks such as ip aliases.

Indeed many people run HTTP on non-standard ports for a variety of reasons
and many people (myself included) run other things (such as an SSH server)
on port 80 for other reasons (after the first time I encountered an airport lounge
that thought the only internet access I could possibly need was to ports 80
and 443, I set up an SSH server on port 80 to work around this limitation).

The problem is that there’s no DNS provision for A+P records or AAAA+P records
or even meaningful definitions of P records, so while it’s perfectly reasonable
to have http servers at [2001:db8::1]:80, [2001:db8::1]:81, …, there’s no good
way to make www.foo.com map to [2001:db8::1]:80 and www.bar.com map
to [2001:db8::1]:81 in the real world.

> Again: here NATs are making it very evident that harcoding HTTP to port

No… They’re making it very evident that NAT comes at a price and part of
that price may come from the convenience of having HTTP linked to a
well-known port (there’s nothing magic about 80).

Unless you can convince client resolver libraries and applications to make
better use of SRV records, this is where we are in the real world.

It wasn’t broken before NAT. Sure it represents certain assumptions that
can be violated and NAT most definitely violates them in an extreme way.

However, it is a fundamental tenant of the architecture that I expect
the devices in the network not to edit my packets, but rather to forward
them without mutilation. NAT most definitely violates this and as a result,
it breaks things.

Claiming that this fundamental tenant is incomplete and that NAT is
not the problem is like claiming that it would be OK to introduce a
square ball into a basketball game, claiming that the fact the hoops
are round is a design flaw in the hoop.

> You don't want a full directory service? -- Fine... then pay the price

I want a directory service that is adequate to the task. DNS does that
(mostly) and this is certainly not one of the areas where I consider it
to be meaningfully deficient.

The fact that NAT makes this capability more necessary than the network
without NAT does not make NAT inherently acceptable.

> Regarding popularity, when did popularity became a metric of correctness?

It’s not a metric of correctness, but it is a metric of acceptance and more importantly,
a metric of usefulness.

Clearly SRV has not been deemed adequately useful to achieve wide-spread support
in client software.

> it, and we have done it for a long time”.

You’re arguing that NAT isn’t broken and/or doesn’t break things, but rather
that the design assumptions in the internet are what is broken and NAT being
not broke proves it.

It was never a technical discussion on either side. It has inherently been your
religious support of diode firewalls and NAT that has driven it away from a
technical discussion from the beginning.

> restaurants are usually crowded, and Mc has made a lot of profit for years.

No, it’s like arguing that Fred’s Burgers is probably not going to succeed
since there’s never anybody in their restaurants.

I’m not arguing that the popularity of the present system makes it not broken.
I’m arguing that solutions which do not achieve adoption are not solutions.

> that doesn't make a Big Mac good beef.

Depends on where you go… In Moscow, the McDonald’s actually does
use decent beef (or at least did the last time I ate there in 1993).

Normally I’m not a fan of the golden arches, but it was what was open at
this particular hour and I was pleasantly surprised how much higher the
quality of the food was compared to US operations.

However, that’s a side issue.

The simple reality is that arguing that everyone should eat soy tofu burgers
because beef burgers are somehow inadequate or soy burgers are healthier
or whatever doesn’t seem to change the fact that people like beef and will
go to McDonald’s or wherever else and nobody goes to the Soy Burger
Drivethru. When was the last time you saw a Soy Burger Drivethru restaurant?
If you’re wondering why, it’s because when nobody buys your “solution”,
then your solution clearly didn’t solve anything.

Owen