Subject: [nat66] Fwd: New Version Notification - draft-mrw-nat66-12.txt

From: Fred Baker <[email-masked]>
Date: Mon, 14 Mar 2011 05:54:59 -0700

In discussion with Dave Thaler, I came up with an additional consideration in response to the Transport Directorate review. One of their concerns was that the TCP Authentication Option assumes it has an end-to-end address; Dave pointed out that any such assumption above the network layer is an UNSAF (RFC 3424) practice. So I added the reference. 

Begin forwarded message:

> From: [email-masked]
> Date: March 13, 2011 11:30:02 PM PDT
> To: [email-masked], [email-masked], [email-masked], [email-masked]
> Subject: New Version Notification - draft-mrw-nat66-12.txt
> 
> New version (-12) has been submitted for draft-mrw-nat66-12.txt.
> http://www.ietf.org/internet-drafts/draft-mrw-nat66-12.txt
> 
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-mrw-nat66-12
> 
> IETF Secretariat.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 14 Mar 2011 17:37:25 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fred Baker
> Sent: Monday, March 14, 2011 5:55 AM
> To: NAT66 HappyFunBall
> Subject: [nat66] Fwd: New Version Notification - draft-mrw-nat66-12.txt
> 
> In discussion with Dave Thaler, I came up with an additional
> consideration in response to the Transport Directorate review. One of
> their concerns was that the TCP Authentication Option assumes it has an
> end-to-end address; Dave pointed out that any such assumption above the
> network layer is an UNSAF (RFC 3424) practice.

:-)

I like that.

-d

> So I added the
> reference.
> > To: [email-masked], [email-masked], draft-mrw-
> [email-masked], [email-masked]
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Rémi Després <[email-masked]>
Date: Tue, 15 Mar 2011 18:28:50 +0100

Hello Fred,

Here are some comments, with references to sections.

Le 14 mars 2011 à 13:54, Fred Baker a écrit :
>> ...

1.2
Some caveat concerning the multihoming case may be appropriate (see 2.4 below).

2.1
IMHO, it should be mentioned here that, behind an NPTv6 having a /48, subnet 0xFFFF is forbidden:
- This constraint is significant because it exists neither if global addresses are routed nor with NAPTv6.
- Mentioning it only in section 2.6 and 4.2 with the justification found only in appendix B would let many readers miss it. 

2.4
In case of multihoming with PA's, a limitation of NPTv6 that should be noted is that some incoming connections can fail:
- In a site having global prefixes PA1 and PA2, an internal server has two global IPv6 addresses S1 and S2. 
- If its default exit route goes to the PA1-CPE, incoming connections addressed to S2 will fail due to ingress filtering in the PA1-CPE.
(If only S1 would be advertised to clients, incoming connections would become impossible the PA1-CPE fails, a negation of what multihoming is expected to bring.) 

3.2 and remainder of the document.
The word datagram seems to be used instead of packet:
- RFC 2460 doesn't use the word datagram for IPv6, even in case of fragmentation 
- In any case, NPTv6 operates individually on packets without concern with reassembling fragments. 

9.
Last... and least (but already signaled), my name is Remi Despres, not Remi Depres
(Actually, it is Rémi Després but it is understood that ASCII doesn't permit.)

Regards,
RD

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 13:17:01 -0700

> - If its default exit route goes to the PA1-CPE, incoming connections addressed to S2 will fail due to ingress filtering in the PA1-CPE.

I don't think this hits the mark.  From section 5:

                     [...] Also, an NPTv6 Translator does not aggregate
   traffic for several hosts/interfaces behind a lesser number of
   external addresses, so there is no inherent expectation for an NPTv6
   Translator to block new inbound flows from external hosts, and no
   issue with a filter or blacklist associated with one prefix within
   the domain affecting another. [...]

I'm not sure that NPTv6 introduces any new site-multihoming problems for firewalls beyond those they already have, but I suspect it might.  Without NPTv6 involved to unify multiple external prefixes into a single local prefix, hosts on traditionally site-multihomed networks will discover each external prefix and their attributes separately.  With NPTv6 unifying the external prefixes into a single local prefix, they discover only one prefix and its unified attributes.  I suspect that NPTv6 might add a burden on firewalls related to the unification of external prefix attributes so that routers advertising the local prefix have unified attributes to advertise that prevent communications failures associated with attribute renewal.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Mar 2011 15:51:57 -0700

You're correct. Apart from the fact that I misspelled his name (shame on me), his comments miss the mark.

There is, in fact, a problem with NPTv6 with respect to multihoming, which is that if I have two upstreams and therefore two prefixes and routing changes (a session is using one ISP and either internal routing changes or the DMZ it is using fails), the session might switch to a different DMZ and as a result have a different IP address. This is equally true of NAPT44; if I change NAPTs, I change addresses. In NAPT, that is true even if they go to the same ISP. with NPTv6, multiple Translators going to the same ISP will use the same upstream prefix, and sessions can be rerouted between them or load shared, which is not true in NAPT44. So I will argue that if the limitations of NAPT44 around rerouting are acceptable, NPTv6's limitations - which the draft is IMHO very up front about - are not as bad as what folks deal with operationally today. To my mind, section 5 spends quite a bit of effort indicating that there are issues around differences in addresses. This is also discussed in RFC 3424. 

How would I fix that? The same way I would fix Multipath TCP and therefore the TCP Authentication Option - because I think they are the same problem. I would start out by observing, with RFC 3424, that protocols above the network layer make a mistake when they tie themselves to the Network Layer Address. It's the same mistake they would be making if they tied themselves to the MAC Address. Rather than quote RFC 3439 on the topic, I'll simply encourage people to read its comments on complexity, amplification, and especially coupling, which may be found at http://tools.ietf.org/html/rfc3439#section-2. When you couple layers together, things go belly up. Instead of complaining about the fact, which the IETF makes a grand past-time of and this thread is a case in point, start thinking about how to not couple them. With Multipath TCP we need to be able to send data to and receive data from any of our peer's addresses, and do so from any of our own. IMHO, the way to do that is to have each peer create a nonce - ILNP's random number, in a TCP option, might be a very good one - that will identify it to a peer, and use that regardless of the address pair. Having a TCP session change addresses is exactly the same behavior as having a Multipath TCP switch from using one address pair to using another address pair, which it might do packet by packet; an end to end session identifier above the network layer, what NIMROD calls an "identifier" and tries to split from the "locator", solves that quite nicely.

HIP, BTW, doesn't work for this. It requires two complete exchanges to operate using the same address pair before the HIT is established. I can trivially construct a network in which that will never happen; I suggested that problem to some students at BUPT, who prototyped NPTv6, ILNP, and GSE with HIP, and published two papers. One points out that ILNP doesn't have the problem (the nonce solves it), and the other points out that HIP does.

Ran's cue... I agree that all we have to do is change the TCP and UDP pseudo-header and therefore the checksum, and ILNP will be a superior solution, one that doesn't drop TCP sessions around a route change to a different provider. I personally don't think the pseudo-header change will happen within my lifetime, and think that people don't spend a lot of cycles thinking about NAPT44 route flap effects.

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 16:12:24 -0700

On Mar 15, 2011, at 15:51 , Fred Baker wrote:
> 
> To my mind, section 5 spends quite a bit of effort indicating that there are issues around differences in addresses.

It does, but I think there might be room to improve section 2.4 further by discussing the problem of choosing the correct valid and preferred lifetimes for routers advertising the internal network prefix.  There may also be ramifications for firewalls that implement I-D.ietf-pcp-base.

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Mar 2011 16:37:12 -0700

> It does, but I think there might be room to improve section 2.4 further by discussing the problem of choosing the correct valid and preferred lifetimes for routers advertising the internal network…

In RIPng, IS-IS, OSPFv3, and BGP-4+, route lifetimes are not a question of attributes of the prefix such as whether it is internal or external. They are attributes specified in the routing protocol. In any variant of RIP, the system originating the prefix does so if and only if the relevant interface is up, and does so as often as the announcement timer fires - by default, in RIPng, every 30 seconds. In OSPF, a prefix LSA similarly reflects the prefix's state as seen by its originator, is refreshed every 1800 seconds as long as the prefix remains up, and is withdrawn should it go down. IS-IS follows suit, and so does BGP4+. 

To my mind, the ramifications for the port control protocol are very simple. 

AN NPTv6 TRANSLATOR DOES NOT, EVER, UNDER ANY CIRCUMSTANCES, SCREW WITH PORTS. COLD STOP, NOTHING MORE TO SAY, AND THE DRAFT SPENDS A FAIR BIT OF SPACE SAYING THAT INCLUDING THE WORDS "MUST NOT".

If a firewall, such as specified in RFC 6092, is opening or closing port filters, that is something the filter logic and its manager do. The firewall might be configured to open these ports, close those ports, and close a third set of ports unless someone asks for them to be opened. The PCP conversation is with the firewall functionality, which is COMPLETELY AND 100% SEPARATE FROM THE NPTv6 TRANSLATOR FUNCTIONALITY.

Hence, I have no clue what you're getting at in asking me to wax eloquent on in either topic, and mystified as to why you would want me to. It's irrelevant to NPTv6.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Mar 2011 13:04:55 +1300

On 2011-03-16 11:51, Fred Baker wrote:
...
> people don't spend a lot of cycles thinking about NAPT44 route flap effects. 

The interesting thing is that people don't spend cycles thinking about
any of the NAT-induced glitches which cause end users to lose sessions;
some of these will apply to NPTv6 of course. I wonder if it's possible
to quantify this (rough % of sessions lost by NAPT44 glitches, and
how many of these would *not* occur with NPTv6)?

    Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Mar 2011 17:29:33 -0700

> how many of these would *not* occur with NPTv6)?

I don't think so, at least not in any general sense, because it's a matter of routing, traffic loads, probability of failure, and so on - it's is all about specific cases. 

If a network has two upstreams and one DMZ to each, it will apply to every TCP session open at the time of the failure. If it has two DMZs to each, does re-routing take it to the other DMZ to the same ISP (0% loss) or a DMZ to a different ISP (100% loss), or some middle ground?

If failures happen every 100 days, and the network typically opens and closes 3100 TCP sessions/second (assumes that every session consumes 50 KBPS on a 155 MBPS link and that is exactly what's happening), 3100/(100*24*3600*3100) is 0.00003733572282%, or so says /Applications/Calculator.app. If you don't like my numbers, insert your own. For the record, we had a power failure this morning at the house and every TCP session I had outstanding did a belly flop. I think that was exactly zero.

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 18:12:16 -0700

On Mar 15, 2011, at 4:37 PM, Fred Baker wrote:
> 
> The PCP conversation is with the firewall functionality, which is COMPLETELY AND 100% SEPARATE FROM THE NPTv6 TRANSLATOR FUNCTIONALITY.

Not true entirely true.

Using NPTv6 to facilitate site multi-homing as described in section 2.4 means that hosts may have multiple external addresses and PCP servers with which to communicate their port control needs to IPv6 firewalls (c.f. REC-48 in RFC 6092) for ports bound to their single locally prefixed interface identifiers.

PCP assumes deployment only in single-homed sites, and hosts deployed behind NPTv6 translators have no systematic way to determine that they *aren't* in a single-homed site.  Indeed, that's the point of NPTv6: to present an approximation of a single-homed network when in fact the network is multi-homed with provider-aggregated addresses.  Support for PCP will entail a proxy server that handles port control requests from internal addresses and proxies them to the PCP servers for each of the external firewalls.

Moreover, there is an open problem, which the PCP working group will eventually discover in the fullness of time, dealing with external address discovery.  Hosts deployed behind NPTv6 that expect to use PCP to obtain the external addresses mapped to their internal addresses will need to cope with the fact that multiple addresses may be in the list.  Indeed they may get IPv4 addresses too, from NAT64 boxen.  When NPTv6 is used for site multi-homing, then each of the external addresses will need to be returned by the PCP proxy server.  Possibly, each with their own lifetimes.  Not sure what the PCP people will do when they come fact to face with this problem.

Look, you don't have to design a PCP proxy server in this draft.  You just need to point out that PCP will need one.  Either that or you need to point out that site multi-homing with NPTv6 isn't compatible with PCP.  Pick one, but please don't just ignore the issue.

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Mar 2011 18:33:54 -0700

> Using NPTv6 to facilitate site multi-homing as described in section 2.4 means that hosts may have multiple external addresses and PCP servers with which to communicate their port control needs to I…

  "Since there is significant detriment caused by modifying transport
   layer headers and very little, if any, benefit to the use of port
   mapping in IPv6, NPTv6 Translators that comply with this
   specification MUST NOT perform port mapping."

> Look, you don't have to design a PCP proxy server in this draft.  You just need to point out that PCP will need one.  Either that or you need to point out that site multi-homing with NPTv6 isn't co…

I'm sure that the community will be well informed by your draft when you file it.

---

From: james woodyatt <[email-masked]>
Date: Tue, 15 Mar 2011 18:42:23 -0700

>   specification MUST NOT perform port mapping."

I think you're missing my point.  The PCP protocol is intended for controlling firewalls even in the absence of port mapping.  The issue with PCP has nothing to do with port mapping.  It has to do with pinhole control and REC-48 of RFC 6092, which PCP is intended to meet.

Once again, I am NOT talking about port mapping.
I am NOT talking about port mapping.
I am NOT talking about port mapping.
I am NOT talking about port mapping.
I am NOT talking about port mapping.
I am NOT talking about port mapping.

I am talking about the implications for firewalls and PCP-capable hosts deployed behind site multi-homing NPTv6 systems as described in section 2.4 of your draft.

---

From: Fred Baker <[email-masked]>
Date: Tue, 15 Mar 2011 21:59:33 -0700

> I am talking about the implications for firewalls and PCP-capable hosts deployed behind site multi-homing NPTv6 systems as described in section 2.4 of your draft.

They will be exactly the same as any other firewall. Since the feature doesn't change the ports, PCP will turn them on or off, exactly as it does with any other firewall.

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 16 Mar 2011 08:09:39 +0100

> how many of these would *not* occur with NPTv6)?

You get NAPT44 glitches under two circumstances, in my experience:
- your NAT gateway is buggy or overwhelmed and loses NAT state ->
  single sessions fail randomly
- your NAT gateway reboots, all sessions that were going previously are
  toast

Both are due to the statefulness of NAPT44. Since NPTv6 is stateless,
I do not expect either to apply. (Modulo "it's buggy as an ant farm", but
that's not a protocol failure, especially not of the protocol algorithm
is fairly simple).

If an outside link fails, I would say it was unfair to blame the NPTv6 for
the sessions across it failing; it's not the cause, the sessions would
have died without translation just the same.

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 16 Mar 2011 08:41:56 +0100

Hi,

> They will be exactly the same as any other firewall. Since the feature doesn't change the ports, PCP will turn them on or off, exactly as it does with any other firewall. 

If I understand correctly, the intended use for the pinhole control
protocol is that you can tell an upstream firewall "hey, I'm
2001:db8:a:b:c:d:e:f and I want to accept incoming connections on port 12345"
whereupon the firewall goes from "deny all inbound" to "deny all inbound
except to 2001:db8:a:b:c:d:e:f port 12345".

Since it'll be for incoming connections, you'll want all possible paths
opened, and of course for the addresses apparent on the "outside"
interface of the firewall.

I think the "you may need a proxy if your translator is between you and
the firewall" is better situated in the PCP draft, since it will not only
apply to one kind of translation.

Other need to mention it in the NPTv6 document does not exist: Since the
address translation itself is utterly deterministic in the NPTv6 case,
you do not need to build hooks into the NPTv6 translator, the PCP proxy
can calculate them itself given inside and outside prefixes.

regards,
	spz

---

From: JFC Morfin <[email-masked]>
Date: Wed, 16 Mar 2011 11:36:38 +0100

At 23:51 15/03/2011, Fred Baker wrote:
>I suggested that problem to some students at BUPT, who prototyped 
>NPTv6, ILNP, and GSE with HIP, and published two papers.

Would you have their URLs?
Thx.
jfc

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Mar 2011 08:18:48 -0700

Finally, *somebody* understands me. <sniff/>

--jhw (sent from my phone)

---

From: james woodyatt <[email-masked]>
Date: Wed, 16 Mar 2011 08:43:35 -0700

Grmf. WI-fi down on the shuttle today, so I need to compose this followup on my phone.

There is an additional point worth mentioning in the NPTv6 draft. If the firewall is instead positioned between the translators and the protected hosts, then a proxy is still required to support the external address discovery part of the PCP protocol.

Making NPTv6 and PCP play together requires mentioning the problems NPTv6 deployments pose for PCP implementors, or explicitly coming out and saying that PCP isn't expected to be compatible with NPTv6 and describing the reasons for it.

---

From: JFC Morfin <[email-masked]>
Date: Wed, 16 Mar 2011 17:25:44 +0100

At 23:51 15/03/2011, Fred Baker wrote:
>  Rather than quote RFC 3439 on the topic, I'll simply encourage 
> people to read its comments on complexity, amplification, and 
> especially coupling, which may be found at 
> http://tools.ietf.org/html/rfc3439#section-2. When you couple 
> layers together, things go belly up. Instead of complaining about 
> the fact, which the IETF makes a grand past-time of and this thread 
> is a case in point, start thinking about how to not couple them.

Amen.

This is, however, IPv6 built-in. From designers' point of view there 
is an IPv6 address.

 From a user point of view, there are three address layers supported 
by three address segments in an "IPv6 address", that are rather 
similar to domain name levels (and that can be supported by domain 
name levels):

- the IDv6 user defined regional addressing plan (64 bits)
- the GRIDv6 user announced regional ID (the extension to 64 bits of 
the network address below  or the leading bits of the IDv6 segment 
if the network address is 64 bits)
- the IPv6 network address, i.e. the leading block provided by the 
ISP - the part you want to change.

The most difficult part for us is obviously the fuzzy GRIDv6 
identification. There could be a negotiation or the use of bit 65, to 
be set to 0 or 1 in order to indicate where the GRIDv6 info is located.

To better accept this, please remember that the IDNA2008 resolution 
has introduced subsidiarity as the way to address diversity. The 
English language actually lacks two words to fully describe 
subsidiarity in this case:

- what could be translated as "active subsidiarity" from French 
"subsidiarité active", which is a poor word for the concept of 
"matching unity and diversity", I would prefer to translate as 
"progressive or layered subsidiarity". This is what happens in the 
Internet. Introducing subsidiarity in higher (new) fringe to fringe 
layers is the way to protect unity in the lower (most, if not all) 
end to end layers.

- what I do not know how to translate in English is the "principe de 
suppléance", which means that when subsidiarity fails, the upper 
level or collaterals or even the lower level are to provide help 
while respecting the subsidiarity principle. This is the way 
subsidiarity scales. Beware: this is not by solidarity, as it is 
sometimes translated. Solidarity is centered on each subsidiary level 
that needs cooperation because something failed and it requires a 
patched solution, which is to be carried out together on the 
occasion.  Suppléance is a built-in governance mechanism that 
everyone can rely upon as acting as necessary, but not more than 
necessary, when and only when needed. Solidarity is occasional, and 
suppleance capacity is permanent. Suppleance is a governance 
principle, while solidarity is a survival solution.

For example, this should be the role of ICANN in naming and 
addressing. Hierarchy is based on ruling, and subsidiarity is based 
on serving. Suppleance is the way that this serving scales. When I 
say that IDv6 can be supported by domain names translated into IIDs, 
this is by the suppleance of the inability of IPv4 to support local 
IIDs. When Fred proposes NPTv6, this is the simplest (RFC 3439) way 
to apply the suppleance principle among collaterals.

jfc

---

From: Rémi Després <[email-masked]>
Date: Wed, 16 Mar 2011 17:39:56 +0100

Le 15 mars 2011 à 23:51, Fred Baker a écrit :

> ... Apart from the fact that I misspelled his name (shame on me), his comments miss the mark.

1. Thanks for the spelling bit.

2. Is this to mean that you ignore the datagram vs packet bit?

3. I remain convinced that what is said about multihoming is really short, but I won't insist. That's your draft. 

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Wed, 16 Mar 2011 10:31:35 -0700

> - In any case, NPTv6 operates individually on packets without concern with reassembling fragments. 

You're correct that I used "datagram" interchangeably with "packet". Are you asking me to explicitly globally replace "packet" with "datagram" for consistency? I can do that.

This is a point where people often get into hissy fits and I start seeing double as my eyes cross and roll to the back of my head. "Packet" is a general term for "a bit of data wandering around as a quantum", but in X.25 refers to a PDU at the packet layer. Sometimes it's called a "frame", usually at the link layer. TCP calls it a "segment", DCCP calls it a "packet", SCTP sometimes calls it a packet and sometimes refers to "payload", and UDP calls it a "datagram". There are various words used by various applications. Anything ISO calls it a Protocol Data Unit or PDU, and may prepend a word/letter to indicate the layer in question; TP4, for example, exchanges TPDUs. But of course, since many PDUs in fact are parameters of API events as opposed to messages in the network, I tend to think of a PDU as a quantum of data passed through an API.

There are 1215 RFCs that refer to a packet containing an IP header and whatever happens to be inside it as a "datagram"; there are 2814 RFCs that refer to "packets", many of them in an IP context. RFC 1594 defines "datagram" as "a self-contained, independent entity of data carrying sufficient information to be routed from the source to the destination computer without reliance on earlier exchanges between this source and destination computer and the transporting network." http://searchnetworking.techtarget.com/definition/datagram has a fairly clean definition of the term. I find myself referring to IP's messages specifically as "datagrams", and quanta of data at any layer as "packets" pretty generically, and in any Internet context to view the two terms as largely interchangeable - as do, it would appear, 6028 of my colleagues that write RFCs. And no matter what I call them, I get a comment from someone telling me they wished I would call them something else.

I'll do the global replace.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Mar 2011 09:26:45 +1300

> have died without translation just the same.

Well, I think Fred was comparing two multihoming solutions:

1. RFC4116 (PI/BGP4) based multihoming), where user sessions should survive
   if a single ISP link goes down;
2. NAPT based multihoming, where the external address will change if
   an ISP link goes down, so the NAPT session inevitably dies.

I don't know how common that failure is in practice.

However, I agree - the user experience with NPTv6 based multihoming
should be much less prone to glitches than NAPT.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Mar 2011 09:31:21 +1300

Sorry, the previous message was incomplete...

==>This failure mode also exists for NPTv6.

   Brian