Subject: [nat66] Handling longer IPv6 rtg prefixes

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 10:14:58 -0400

Earlier, Margaret Wasserman wrote:
% If we do need to address prefixes of longer than /48 in NAT66,
% that is fairly easy to do. We just need to pick which sacrifices
% we are willing to make. I can think of two choices:
%
% (1) Add the checksum correction to a 2byte portion of the
% lower 64 bits when the prefix is longer than /48, thus modifying
% the IID.
%
% This wouldn't be compatible with (currently unspecified) mechanisms
% that require a constant IID, but we would already have that problem
% with nodes that generate privacy addresses.

It is not correct that all proposed mechanisms that would use the
low-order 64 bits are incompatible with the IPv6 "Privacy Address"
extensions.  Some of those proposals in fact are *completely*
compatible with the "Privacy Address" mechanisms.

In fact, modifying the low-order 64-bits (IPv6 Interface ID)
will break proposed mechanisms that work fine with IPv6
Privacy IDs.  Separately, other things (e.g. deployed IPv6
audit approaches) will break if the low-order 64 bits of a packet
get modified by a NAT66 device.

So modifying the low-order 64-bits is not a desirable technical
approach to the issue of handling NAT66 functions when relatively
longer IPv6 routing prefixes have been deployed.

% or
%
% (2) Fix the UDP or TCP checksum instead of performing the
% checksum correction algorithm when the prefix is longer than /48.

(NOTA BENE:  Margaret has not raised checksum recalculation
performance as an issue, but other folks have done so.  It
is on topic for this note, so I'll discuss it here. :-)

Widely deployed very-lost-cost residential/small-office gateways
that perform NAT re-calculate the UDP/TCP checksums today
without any user-visible performance issues.

In fact, recalculating the Fletcher checksum (used by UDP/TCP)
is very easy to do purely in software on an ordinary very-low-cost
CPU.

So there are existence proofs that performance would be a
non-issue for the kinds of sites that are likely to be given
relatively longer IPv6 routing prefixes.

% The cost here is that we lose the ability to encrypt/protect
% the transport layer headers. In NAT66, we could explicitly
% make this correction for UDP/TCP only, passing through other
% transport layers unmodified, which might help to reduce the
% impact on new innovations at the transportlayer.

Note that SSL/TLS does not protect TCP headers.  So the above
concern is limited narrowly to ESP or AH.[1]

IETF standards-track RFC-3948 specifies UDP Encapsulation
to enable ESP/AH traversal of existing IPv4 NAT devices.
That mechanism is very widely implemented, and is also
very widely deployed today.  It really works quite well.

RFC-3948 works fine with a NAT66 device; no code changes
to an RFC-3948 implementation ought to be required.

So there this issue has already been solved, existing solutions
can be reused, and there is not a new issue arising from NAT66.

So for the sites being given longer IPv6 routing prefixes, the
specification ought to require that the NAT66 device recalculate
the TCP/UDP checksums, and ought to prohibit a NAT66 device
from ever modifying the low-order 64-bits.

Last, I think this WG ought to explicitly document that one
ought never be allocated an IPv6 Routing Prefix longer than
64 bits, and that any IPv6 NAT function that gets specified
also ought not support NAT/NAPT/SAT for prefixes longer than
64-bit

Yours,

Ran
[email-masked]

[1] Separately, IPv6 AH ought to be specified to only include
the IPv6 Interface ID bits, not the IPv6 Routing Prefix bits,
regardless of NAT66.  However, the topic of IPv6 AH belongs
to a different mailing list and a different working group.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 3 Apr 2009 10:47:16 -0400

Hi Ran,

Thanks for your input!

> get modified by a NAT66 device.

How do these mechanisms work with randomly generated privacy IIDs?

> longer IPv6 routing prefixes have been deployed.

That is why I included modifying the IID as a negative in that approach.
> relatively longer IPv6 routing prefixes.

In IPv6, we have the added issue of _finding_ the TCP/UDP checksum.   
There may be extension headers in the way, and we would need to make  
sure that a NAT66 device can handle arbitrary extension headers.   
Otherwise, we are effectively eliminating our ability to add new IPv6  
extension headers in the future.
> can be reused, and there is not a new issue arising from NAT66.

That's excellent.  I wasn't aware of this RFC.  Thanks for pointing it  
out.
> also ought not support NAT/NAPT/SAT for prefixes longer than

Makes sense.  We've said it elsewhere, but it wouldn't hurt to keep  
saying it.  We could also point out the potential advantages to sites  
that have a /48 (and can do IP checksum correction in the subnet bits)  
in the hope that this will add one more straw to the side of folks  
(especially enterprises) demanding a /48 from their provider.
> to a different mailing list and a different working group.

This would be a Good Thing (TM).

Margaret

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 11:00:26 -0400

> extension headers in the future.

Yet another reason to discourage IPv6 NAT.

We need to keep track of these and evaluate their costs, just as much as
we need to identify use cases and evaluate their validity.

Otherwise we run the risk that by narrowing our focus to making IPv6 NAT
work as well as possible, we forget that NAT is still, overall, a bad
idea.  At best, use of NAT in IPv6 is a sign of our failure to educate
users.  At worst, it's a sign of a failing of the Internet architecture
to accommodate important requirements.

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 12:12:18 -0400

> How do these mechanisms work with randomly generated privacy IIDs?

They work without any modifications or any special handling
being required.

> There may be extension headers in the way,

In practice, I do not think extension headers are a real issue here.

A) MEASUREMENTS

First, I've done some measurements.  MUCH MUCH less than 1% of
IPv6 traffic in real enterprise deployments contain ANY
optional header.

Virtually all of the packets that have any optional header
today only have either AH and/or ESP.  In a NAT66 deployment,
such packets will be UDP-encapsulated anyway (as described
in my previous note), so aren't an issue.

B) CASE ANALYSIS

Separately, lets try a case analysis.  Existing IPv6 optional
headers (according to IANA), other than ESP/AH, include:

1) Routing Header
    There is limited use of these headers.  I could not find any
    use in measurements of real deployments.  Type 0 Routing
    Headers are deprecated.  Type 1 were for NIMROD and have
    no deployment.  Type 2 are for Mobile IP, have a fixed
    size, and hence are easy to parse past.

2) Hop-by-Hop Header
    Other than the NULL option, which isn't seen alone, the only
    deployment is of the IPv6 Router Alert option, and the only
    proposal I've seen is draft-stjohns-sipso, which is ONLY deployed
    in closed environments that will NEVER have any IPv6 NAT box
    (that I-D has text explaining why "NEVER" is the right word).

    Because of the TLV syntax of the Hop-by-Hop Header, it is also
    trivially easy to parse past these even on a tiny/cheap CPU,
    even for unrecognised sub-options carried inside the HbH header.

    Further, the IPv6/6MAN WG is quite sceptical about specifying
    any new Hop-by-Hop options, so no additional options in this
    class are likely to be created.

3) Destination Options Header
    Other than the NULL option, which isn't seen alone, there is a
    Mobile IPv6 "Home Address Option".  "Quick Start" is an experimental
    sub-option for certain Transport protocol experiments; it has
    nearly zero implementation or deployment.  There is a Generic
    Packet Tunneling "Tunnel Encapsulation Limit" option, which has
   limited implementation and limited deployment.  There is a Jumbo
    Payload Length option.  This probably has more implementations,
    and some use (e.g. in super-computing environments), but I did not
    encounter it even on Ethernets where 9K frames were configured/ 
deployed.

    As with the Hop-by-Hop Header, the TLV syntax of the overall
    Destination Options Header makes it trivially easy to parse
    past even on a tiny/cheap CPU, even for unrecognised sub-options
    that might be carried inside the Dest Opts Header.

4) Fragmentation Header
    This is the only case to consider more closely.  A NAT66 box
    would need to know how to find the TCP/UDP checksum inside
    a *first* Fragmentation Header only.  There are strict rules
    both on IPv6 header order (generally) and for IPv6 fragmentation
    (specifically).  Supporting this case would not be a lot of
    code in the NAT66 box.

5) Endpoint Identifier
    This codepoint was allocated to Charles Lynn (BBN).  I believe
    this was intended for use with NIMROD experiments.  I do not
    believe that any deployments of this exist anywhere today.
    (Corrections on this understanding would be welcome. :-)

> and we would need to make

The IPv6 community's plan has been (and still seems to be) that
additional "extension headers" would not exist, but instead that
any additional IPv6 "options" would be placed either inside the
"Hop-by-Hop Header" or the "Destination Options Header".

> Otherwise, we are effectively eliminating our ability
> to add new IPv6 extension headers in the future.

I do not think we are.

Over time, IPv4 NAT devices have been updated to support various
extensions to TCP/UDP over IPv4 deployments, so there is good reason
to believe that NAT66 devices also could be enhanced over time.

In the case of the residential/SOHO implementation of NAT66,
a purely software implementation is likely to be common.  Various
software loads, including some 3rd party software loads, exist
for at least some of the existing very-low-cost IPv4 NAT devices
(e.g. Linksys boxen).

Separately, what kind of IP option could one imagine that has
neither a "hop-by-hop" nature nor an "end-to-end" nature ?

(Anything that has either of those natures will fit *inside*
the existing HbH Header or Dest Opts Header, and would traverse
a NAT66 device without any code changes at all, so could be
added at will without any concern about whether one's NAT66
box were upgraded or not.)

Yours,

Ran
[email-masked]

---

From: Rémi Després <[email-masked]>
Date: Fri, 03 Apr 2009 18:33:35 +0200

Ran,

I agree with all the points you made.

I add that if all NAT66s, including that of Margaret (MW-NAT66 for 
short), work for packets that have no other extension header than 
fragmentation and transport, this will not prevent more extension 
headers for connections that are not NATted.

The fact that MW-NAT66 doesn't work for longer prefixes than /48, and 
with /48 forbids to use 0xFFFF as subnet ID, are real weaknesses which 
are readily avoided if next headers are looked at.

Regards,

RD

RJ Atkinson  -  le (m/j/a) 4/3/09 6:12 PM:
>    encounter it even on Ethernets where 9K frames were configured/deployed.
> 
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
>

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 3 Apr 2009 12:49:15 -0400

> Last, I think this WG ought to explicitly document that one ought
never be allocated an IPv6 Routing Prefix longer than 64 bits

Either say that address amplification is forever off the table as a
requirement for IPv6 mechanisms in the space (and I encourage you to try
to get WG consensus on this matter!), define a better mechanism to deal
with address amplification than IPv6-to-IPv6 NAPT, or give up and write
an Internet Draft that defines NAPT66.

- Wes

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 12:54:44 -0400

> an Internet Draft that defines NAPT66.

Wes,

   I have no idea how your quote above relates in any way to anything
that I said.  Nothing I said today obviously relates to the topic of
"address amplification".

Cheers,

Ran

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 3 Apr 2009 13:07:44 -0400

>> requirement for IPv6 mechanisms in the space (and I encourage you to 
>> try to get WG consensus on this matter!), define a better mechanism
to 
>> deal with address amplification than IPv6-to-IPv6 NAPT, or give up
and 
>> write an Internet Draft that defines NAPT66.
>
>Wes,
>
that I said.  Nothing I said 
>today obviously relates to the topic of "address amplification".
>
>Cheers,
>
>Ran

> never be allocated an IPv6 Routing Prefix longer than 64 bits

If a routing prefix is allocated that is longer than 64 bits, then you
may need address amplification in order to use SLAAC.  The need for
"address amplification" derives from a disparity in the size of the
routing prefix given by ISPs and that which the end user wants to use.

- Wes

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 3 Apr 2009 13:17:04 -0400

> that I said. Nothing I said today obviously relates to the topic of

If I have followed Ran's presentation, 'address amplification' is 
orthogonal.

That is provided that address amplification for IPv6 is not engineered 
through prefixes longer than /64. The thought truely scares me, based on 
where IPv6 addressing has evolved over the last decade.

IMNSHO, there are two solutions to the drivers (at least as I understand 
them) for address amplification:

pnat for IPv6 like is done for IPv4.

IPv6 prefixes shorter than /64. Most likely equal to or shorter than /62.

I vote strongly for the later. Anyone that needs address amplification 
(and I believe this will apply to all home gamers) should vote with 
their pocketbook and not go with ISPs that only allocate /64 or single 
/128s. We would have to put this into a BCP to provide the technical 
backing for a particular business model.

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 13:38:18 -0400

> You forgot to include my quote of your previous E-mail:

Not at all.  I could not puzzle out how the quoted text
could possibly relate to your note...and frankly I still
cannot puzzle that out.

> If a routing prefix is allocated that is longer than 64 bits,
> then you may need address amplification in order to use SLAAC.

The SLAAC protocol breaks if the routing prefix exceeds 64 bits,
as near as the IAB could tell when the issue came before them:

   <http://www.iab.org/appeals/kre-ipng-address-arch-draft-standard-response.html 

>  The need for

I can't even parse that sentence, let alone lex it for meaning.

Any road, I still don't think your comments related to my
posted comments at all.

Yours,

Ran

---

From: james woodyatt <[email-masked]>
Date: Fri, 3 Apr 2009 11:41:07 -0700

> In practice, I do not think extension headers are a real issue here.

In current practice, they are not a *huge* issue, but they are an issue.

> "Hop-by-Hop Header" or the "Destination Options Header".

Consider the current status of draft-krishnan-ipv6-exthdr in the 6MAN  
working group, which is that nobody wants to define a standard uniform  
format for IPv6 extension headers.  This draft keeps getting shot down  
every time it's proposed as a working group item.

If the IPv6 community is planning that new extension headers are  
required by IETF standards to conform to a uniform format, then 6MAN  
should be persuaded to change its collective mind and put the standard  
into writing.  Otherwise, any NAT66 standard definition that requires  
TCP/UDP checksum modification should be correctly viewed as implying  
the need for a uniform extension header format standard which does not  
now exist.

> neither a "hop-by-hop" nature nor an "end-to-end" nature ?

draft-woodyatt-ald tries very hard not to define an IP option that  
only firewalls are expected to process.  I have sometimes thought that  
such an IP option would be a good idea.  Whether the nature of such an  
option can be regarded as a subtype of the hop-by-hop nature is a  
debate I'd rather not have today.

> box were upgraded or not.)

Yet, 6MAN has not seen fit to make such a promise to posterity  
explicitly.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2009 16:51:42 -0400

> IPv6 traffic in real enterprise deployments contain ANY

How is that relevant when we're talking about an architectural issue?

We're seeing only the very earliest of IPv6 deployment.  Surely we can't
expect observed traffic to be any indicator of future use.

> "Hop-by-Hop Header" or the "Destination Options Header".

Good point.  So the only new extension headers we can expect to be added
to IPv6 are those for which neither hop-by-hop nor destination-only seem
appropriate.  That's probably not the null set, but it probably does
mean that NATs will be able to deal with most new IPv6 extensions.

> to believe that NAT66 devices also could be enhanced over time.

It's not a black-or-white situation.  We've also observed that the
failure of IPv4 NATs to be updated has caused problems for IPv4 hosts
and applications, and we can expect the same situation to apply to IPv6
NATs.

> for at least some of the existing very-low-cost IPv4 NAT devices

Yes, but it's hard to expect users to consistently maintain those boxes.
  Users want to believe (and vendors want users to believe) that they're
maintenance free.  It's also hard to expect vendors to keep updating the
software for those (commodity) boxes without being paid to do so.

My guess is that users replace those boxes more often than they update
their firmware, if for no other reason than to get the latest wired
and/or wireless LAN technology that's bundled into them.  (Who knows,
maybe they'll buy new boxes for IPv6 too.)

> neither a "hop-by-hop" nature nor an "end-to-end" nature ?

I don't have a firm idea myself, but I know better than to assume that
we'll never have reason to define an option that doesn't fit one of
these categories.

e.g. Maybe an option to make some out-of-band request to a NAT?

Keith

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 03 Apr 2009 18:13:30 -0400

> How is that relevant when we're talking about an architectural issue?

Very relevant.  Options that are not in use today are unlikely
to become very frequently used in the foreseeable future.

And to be clear, my thread is quite clearly focused on
*engineering* details for the specific case where a longer
IPv6 prefix might be allocated to an end user.

I haven't made any *architectural* postings in this thread,
at least so far.  Its all been engineering.

> expect observed traffic to be any indicator of future use.

Surely we can and should.  It won't be a perfect indicator,
since those don't exist, but it is certainly an informative
guide for what we might reasonably expect in future.

Yours,

Ran

---

From: Keith Moore <[email-masked]>
Date: Sat, 04 Apr 2009 05:48:26 -0400

> to become very frequently used in the foreseeable future.

To me it seems way too early in IPv6 deployment to tell.

Of course, yours could turn out to be a self-fulfilling prophecy. If
this kind of argument were used to justify v6 NAT, and v6 NATs were
deployed such that they broke new or existing options (as has happened
in the v4 world) that would certainly discourage further deployment of
those options - making your prediction true.

But from an architectural point of view it makes sense to leave some
wiggle room for future needs.

Though it might be the case that existing "generic" IPv6 extensions are
sufficient.  Thinking about it now I realize that the purpose of the
hop-by-hop vs. destination distinction is to specify the handling of
this extension by boxes that don't recognize the option, not to specify
the handling of the extension of those that do.  And if a router doesn't
recognize a specific option, drop and forward are about the only two
choices it has.  The only real question is whether there are cases where
IPv6 NATs need to behave differently than routers with respect to some
option that they don't understand.

> at least so far.  Its all been engineering.

Well, the choice of whether to essentially preclude deployment of new
options is an architectural choice.

> guide for what we might reasonably expect in future.

Completely disagree.  Assuming IPv6 ever succeeds in any terms that we'd
recognize, you're extrapolating far beyond any data that exists so far.
 That's not sound analysis for either engineering or architecture.

Keith