Subject: [v6ops] new draft: draft-anderson-v6ops-v4v6-xlat-prefix

From: [email-masked]
Date: Sun, 1 May 2016 04:47:02 -0700

A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix. Please take a look at it and comment.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 1 May 2016 16:17:51 +0200 (CEST)

> A new draft has been posted, at http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix. Please take a look at it and comment.

I like it.

So this draft would update https://www.ietf.org/rfc/rfc5156.txt ? Or that 
isn't needed?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tore Anderson <[email-masked]>
Date: Sun, 1 May 2016 20:00:54 +0200

Hi Mikael,

* Mikael Abrahamsson

> > http://tools.ietf.org/html/draft-anderson-v6ops-v4v6-xlat-prefix.
> 
> I like it.
> 
> So this draft would update https://www.ietf.org/rfc/rfc5156.txt ? Or
> that isn't needed?

I checked RFC6052 and RFC6666, which are examples of previously
published documents that are designating special-use IPv6 prefixes.
None of them update RFC5156. Therefore I am assuming it is not
necessary.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 2 May 2016 09:52:21 +0000

> On May 1, 2016, at 11:00 AM, Tore Anderson <[email-masked]> wrote:
> 
> Hi Mikael,
> 
> * Mikael Abrahamsson
> 

</chair>

We actually have a couple of prefixes that might be standardly used for translation; one of them (64:ff9b::/96) is in RFC 6052, and another (::ffff:0:0/96) in RFC 2765. They both have the property that the can't be advertised in BGP, if one believes in 64 bit IIDs, 64:ff9b:: has the property that several instances of it can be deployed in the same subnet (64:ff9b::1:0/96, 64:ff9b::2:0/96, 64:ff9b::3:0/96...). So if the issue is that you want a standard prefix that can have multiple instances in the same network, that already exists. I would question whether you want them all in the same subnet, but that's a fine point.

In addition, in the CERNET2 IVI implementation, which also found its way into RFC 6052, one can use a prefix from one's own allocation. CERNET2 has the prefix straddle bit 64, so that they can multiple IPv4-embedded prefixes matching IPv4 prefixes visible from outside, and if you really want a /96, fine, use something like 2001:db8:0:1::/96, 2001:db8:0:1::/96, and so on just like with 64:ff9b::/96. They would have the properties of being able to have multiple translation instances in the same network on DIFFERENT subnets, and also be able to be advertised in BGP (whether you think that desirable or not being a separate question).

I'm scratching my head at what 64::/16 gives you that you don't already have.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 2 May 2016 12:21:48 +0200

Hi Fred,

* "Fred Baker (fred)" <[email-masked]>

> We actually have a couple of prefixes that might be standardly used
> for translation; one of them (64:ff9b::/96) is in RFC 6052, and
> another (::ffff:0:0/96) in RFC 2765. They both have the property that
> the can't be advertised in BGP, if one believes in 64 bit IIDs,
> 64:ff9b:: has the property that several instances of it can be
> deployed in the same subnet (64:ff9b::1:0/96, 64:ff9b::2:0/96,
> 64:ff9b::3:0/96...). So if the issue is that you want a standard
> prefix that can have multiple instances in the same network, that
> already exists. I would question whether you want them all in the
> same subnet, but that's a fine point.

The problem with this is that 64:ff9b::1:0/96, 64:ff9b::2:0/96, and
64:ff9b::3:0/96 all describe the exact same prefix. The "1", "2", and
"3" digits are part of the suffix, and will by most tools be zeroed out.

Thus you cannot, for example, configure your "blue" NAT64 instance with
64:ff9b::1:0/96, "red" NAT64 with 64:ff9b::2:0/96, "yellow" with
64:ff9b::3:0/96 and so on without creating an ambiguity or randomness
as to which instance will be used for an packet sent to
from 2001:db8::123 to 64:ff9b::192.0.2.0.

What *would* have been nice to be able to do, is to for example have:

64:ff9b::0.0.0.0/96 - NAT64 blue
64:ff9b::1:0.0.0.0/96 - NAT64 red
64:ff9b::2:0.0.0.0/96 - NAT64 yellow
64::0.0.0.0/96 - NAT64 green
64:f00::/64 - SIIT black
64:1234:ff00::/40 IVI brown

...and so on. However, RFC6052 only allows for "NAT64 blue" in the list
above, all the others would be squatting on unallocated space. This
draft would change that.

> In addition, in the CERNET2 IVI implementation, which also found its
> way into RFC 6052, one can use a prefix from one's own allocation.
> CERNET2 has the prefix straddle bit 64, so that they can multiple
> IPv4-embedded prefixes matching IPv4 prefixes visible from outside,
> and if you really want a /96, fine, use something like
> 2001:db8:0:1::/96, 2001:db8:0:1::/96, and so on just like with
> 64:ff9b::/96. They would have the properties of being able to have
> multiple translation instances in the same network on DIFFERENT
> subnets, and also be able to be advertised in BGP (whether you think
> that desirable or not being a separate question).

If you want do run IVI as specified in RFC6219 using your own GUA
allocation you'll need a /32 (well, strictly speaking, you'll only need
a /40 but it mandates that bits 33-40 are all "1", so either you need
a /32 or be extremely lucky about which /40 you've got). Furthermore if
you want to run two instances of IVI you most defintively need a /31.
The standard assignment size an end user can reasonably expect to
receive is on the other hand a /48, so much smaller and thus prevents
the use of IVI.

This draft would help with that, ensuring that everyone can run 64k
instances of IVI in their network if they'd like (using 64:X:ff00::/40
where X can be any value from 0x0 to 0xffff).

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 2 May 2016 15:00:11 +0000

> On May 2, 2016, at 3:21 AM, Tore Anderson <[email-masked]> wrote:

Well, except that RFC 6052 allows for variants that CERNET2 didn't choose. As I said, you could literally (and in this, I'm suggesting that 2001:db8::/32 is standing in for your allocated prefix) use

2001:db8:0:0::/96 NAT64 blue
2001:db8:0:1::/96 NAT64 red
2001:db8:0:2::/96 NAT64 yellow

and so on. So it's something already doable.

---

From: Tore Anderson <[email-masked]>
Date: Mon, 2 May 2016 21:11:26 +0200

* Fred Baker (fred)

> Well, except that RFC 6052 allows for variants that CERNET2 didn't
> choose. As I said, you could literally (and in this, I'm suggesting
> that 2001:db8::/32 is standing in for your allocated prefix) use
> 

I probably have confused matters by talking about two different things
(NAT64 and IVI) at once, sorry about that. I'll to be clearer:

First off, I agree completely with your table above, when running
multiple instances of NAT64 (RFC6146) and 96-bit prefixes, lack of
available ISP/RIR-assigned global address space isn't likely to be a
problem. /96s are easy to come by.

IVI (RFC6219) is another matter entirely since it requires that the
operator has a /40-bit (or more realistically a /32-bit) prefix (cf.
section 3.1). The availability of ISP/RIR-assigned GUA space is thus
quite likely to be a problem for operators wanting to deploy IVI.

Available GUA space could also be a problem if you're running NAT64 or
any other RFC6052-derivative technology, and for some reason want/need
to use a NSP with a prefix length shorter than /64. As the I-D points
out, the RFC6052 algorithm goes all the way down to /32 (see section
2.2).

So that covers the "available space" part of the I-D's problem statement
(which, to be clear, does not apply to RFC6052-derivative technologies
like NAT64 when using 96-bit prefixes).

The second part of the argument in the problem statement is that an
operator might not *want* to use his own GUA space, regardless of how
plentiful it might be. This is admittedly anecdotal, but it seems to me
that this is the case for a majority of operators deploying NAT64 -
pretty much every network I've visited that provide NAT64 service have
been using the WKP 64:ff9b::/96 instead of using an NSP assigned from
their own GUA space.

So basically these operators are starting out with 64:ff9b::/96 for
"NAT64 blue" (i.e., the first one to be deployed). If however at a later
point in time they want to deploy another instance of NAT64 (or some
other IPv4/IPv6 translation technology), they are currently forced to
use GUA space even though that might not be what they prefer.

I don't presume to know all the reasons why these operators are be
preferring 64:ff9b::/96 over a GUA alternative, but speaking only for
myself here's a few benefits:

- Avoids making "the IPv4 internet" a subset of "my own network".
  Consider if your GUA assignment is 2001:db8:abc::/48, and you're
  IPv4/IPv6 translation system is using 2001:db8:abc::464:0.0.0.0/96.
  In this case, it is fairly easy to make the mistake of setting up
  some ACL or similar that treats 2001:db8:abc::/48 as "privileged" in
  some way, without realising that could also mean that the entire IPv4
  internet has been granted the same access as internal clients.

- Avoids advertising reachability to the IPv4/IPv6 translation system
  to the DFZ, if use of the system is intended only for
  internal/downstream nodes. There's no way to advertise
  "2001:db8:abc::/48 except 2001:db8:abc::464:0.0.0.0/96" in BGP. Using
  a distinct non-advertisable prefix provides a second line of defence
  against potential misuse of your translation system by unauthorised
  nodes anywhere on the global IPv6 internet.

- The difference between addresses starting with "64:" instead of
  "20xy:" is immediately obvious, making it easy for a human operator
  reading logs or something to spot that an address is involved in some
  kind of IPv4/IPv6 translation instead of being just another regular
  IPv6 address. (Presumably this is the sole reason why RFC6052
  reserved a WKP that started with "64:" in the first place.)

Tore

---

From: Xing Li <[email-masked]>
Date: Tue, 03 May 2016 07:32:42 +0800

>> receive is on the other hand a /48, so much smaller and thus prevents

The RFC6219 just documents an example of IVI of using 
2001:da8:ff00::/40, any prefixes defined in
RFC6052 can be used. We have configurations in CERNET2 using multiple 
/48s and multiple /64s
for different XLATs in production.

When stateful NAT64 is used, we use well-known prefix, since no 
signaling scheme is required to pass the
parameters of the prefix to DNS64, etc.

> and so on. So it's something already doable.

Yes.

Regards,

xing

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

---

From: Tore Anderson <[email-masked]>
Date: Tue, 3 May 2016 02:54:35 +0200

* Xing Li

> RFC6052 can be used.

Hi Xing,

That's interesting. I've always considered IVI to be fundamentally
different from RFC6052 (and by extension RFC6145), as it seems to me
that RFC6219 sections 3/3.1 prescribes an IVI address format that
differs from RFC6052's in at least two respects:

- RFC6219 specifies that «bit 32 to bit 39 are all ones as the
  identifier of the IVI addresses», while RFC6052 does not mandate
  anything like that.
- RFC6219 places bits 24-31 of the IPv4 address in bits 64-71 of the
  resulting IPv6 address, while RFC6052 places the same bits in 72-79
  of the resulting IPv6 address (assuming a 40-bit prefix).

Especially the second difference seems to me to create an
unreconcilable incompatibility between the two algorithms.

That is, if an IVI translator configured with the prefix
2001:db8:ff00::/40 attempts to translate the IPv4 address
198.51.100.123 to IPv6, it will per RFC6219 be translated to
2001:db8:ffc6:3364:7b00::. A RFC6052 translator using the same prefix
would on the other hand translate the exact same IPv4 address to
2001:db8:ffc6:3364:007b:: instead.

It seems to me, therefore, that in order to use stateless translation
you'll need to use either IVI (per RFC6219) or SIIT (per
RFC6052/RFC6145), and that if you attempt to mix the two in the same
network it simply can't work very well.

> We have configurations in CERNET2 using multiple /48s and
> multiple /64s for different XLATs in production.

In any case, "using multiple /48s .. for different XLATs" might be
prohibitive for other operators regardless of which exact address
mapping algorithm they're using, as the standard assignment size is a
single /48 (or even smaller). While it might be possible to request a
larger assignment, doing so will often involve a fair amount of LIR/RIR
bureaucracy. The I-D would allow them to skip that and go straight to
using locally significant prefixes drawn from 64::/16 instead.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 3 May 2016 01:41:41 +0000

> On May 2, 2016, at 5:54 PM, Tore Anderson <[email-masked]> wrote:
> 
> * Xing Li
> 

Interesting, as the origin of and fundamental argument for RFC 6145 was to document IVI and update RFC 2765 with the CERNET experience. To me, there is an operational difference in the way CERNET/CERNET2 deployed it, but the algorithms are one and the same, the only difference being the exact structure of the address.

---

From: Xing Li <[email-masked]>
Date: Fri, 06 May 2016 17:26:10 +0800

Hi, Tore,

> differs from RFC6052's in at least two respects:

I believe that the confusion is due to the RFC numbers. For the version
00s of RFC6052, RFC6145 and RFC6219, the pulication dates are
RFC6219: Jul 2008
RFC6052: Oct 2008
RFC6145: Jul 2009

So the history of RFC6219 is longer than RFC6052 and RFC6145.
Actually, RFC6052 and RFC6145 are more general versions
of RFC6219 for address translation and header translation, respectively.
The IESG at that time decided to publish proposed standards
RFC6052 and RFC6145 first and then publish RFC6219
The RFC6219 says

   The IVI is an early design deployed in the CERNET for the stateless
   translation.  The IETF standard IPv4-IPv6 stateless and stateful
   translation mechanisms are defined in [RFC6144], [RFC6052],
   [RFC6145], [RFC6146], and [RFC6147].  
                                             - [Page 5] of RFC6219.

>   identifier of the IVI addresses», while RFC6052 does not mandate

RFC6219 is a special NSP of /40 in RFC6052.

    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |PL| 0-------------32--40--48--56--64--72--80--88--96--104---------|
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |32|     prefix    |v4(32)         | u | suffix                    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |40|     prefix        |v4(24)     | u |(8)| suffix                |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |48|     prefix            |v4(16) | u | (16)  | suffix            |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |56|     prefix                |(8)| u |  v4(24)   | suffix        |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |64|     prefix                    | u |   v4(32)      | suffix    |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |96|     prefix                                    |    v4(32)     |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

>   of the resulting IPv6 address (assuming a 40-bit prefix).
This is the u-oct issue when RFC6052 is published. However, the RFC7136
updates [RFC4291] which allows the use of unicast addresses without
u-bit, as long as they're not derived from an IEEE MAC-layer address.

Therefore, the u-oct defined in RFC6052 is not required, which is the
RFC6219s format.

> network it simply can't work very well.

For the XLAT we are using (software and cisco), there is a configuration
function for turning on u-oct (or not). So, as long as keep the address 
format
consistent in the same XLAT domain, it should be no problem.
> using locally significant prefixes drawn from 64::/16 instead.

If the prefixes for the IPv4-translatable and IPv4-converted addresses are
the same, which is the default behavior defined in RFC6052, different /48s
for different IPv4-translatables are perfectly fine. If different prefixes
are used for IPv4-translatable and IPv4-converted addresses, it is also
no problem.

Regards,

xing

---

From: Tore Anderson <[email-masked]>
Date: Fri, 6 May 2016 11:53:59 +0200

* Xing Li <[email-masked]>

Hi Xing,

You're spot on - as IVI (RFC6219) was published later than
RFC6052/RFC6145, coupled with the fact that neither RFC6052 nor RFC6145
makes no mention of «IVI» anywhere, has led me to believe that when
designing IVI it was decided not to use the RFC6052 algorithm, instead
coming up with a slightly different and incompatible mapping. (The
reason why has always puzzled me!)

Thank you for explaining the history behind it.

> > mapping algorithm they're using, as the standard assignment size is
> > a single /48 (or even smaller). While it might be possible to
> > request a larger assignment, doing so will often involve a fair
> > amount of LIR/RIR bureaucracy. The I-D would allow them to skip
> > that and go straight to using locally significant prefixes drawn
> > from 64::/16 instead. 
> 
> If the prefixes for the IPv4-translatable and IPv4-converted
> addresses are the same, which is the default behavior defined in
> RFC6052, different /48s for different IPv4-translatables are
> perfectly fine.

Absolutely, but my point was that access to «different /48s» is a luxury
that not everyone is likely to have. Most business-class ISPs I'm aware
of will assign their customers only one /48, which will need to hold
all the customer's deployed native IPv6 plus all his deployed
translation technologies. So dedicating even a single /48 to a
translation system might be impossible.

Allowing such operators to assign locally significant /48s (or /40s
or /32s or whatever their chosen technology needs) out of 64::/16
instead of restricting it to just 64:ff9b::/96 would help with that.

Tore

---

From: Xing Li <[email-masked]>
Date: Fri, 06 May 2016 19:23:25 +0800

Hi, Toru,

> Thank you for explaining the history behind it.

You are welcome.
> translation system might be impossible.

I see what you mean now. For your information, at CERNET2 we also have 
production
cases for using multiple /64s (NSP), as defined in RFC6052.

Best regards,

xing

---

From: <[email-masked]>
Date: Wed, 11 May 2016 08:49:29 +0200

Hello *,

interesting draft, can something like this be added?

"End hosts and end applications must not handle this address range specially or make any assumptions on the handling of this address range within the network they are connected to."

Rationale: There are a lot of applications that assumed that they were behind a NAT when they discovered an RFC1918 address and activated some kind of NAT traversal. When the 100.64.0.0/10 prefix came for addressing clients (shared address space, RFC6598), those applications failed because they were still behind NAT but did not activate their NAT traversal option.

Holger

---

From: Alejandro Acosta <[email-masked]>
Date: Wed, 11 May 2016 08:16:45 -0400

Agree

---

From: Tore Anderson <[email-masked]>
Date: Thu, 12 May 2016 09:07:58 +0200

* <[email-masked]>

> "End hosts and end applications must not handle this address range
> specially or make any assumptions on the handling of this address
> range within the network they are connected to."
> 
> Rationale: There are a lot of applications that assumed that they
> were behind a NAT when they discovered an RFC1918 address and
> activated some kind of NAT traversal. When the 100.64.0.0/10 prefix
> came for addressing clients (shared address space, RFC6598), those
> applications failed because they were still behind NAT but did not
> activate their NAT traversal option.

Yes, I can add something like that. Thank you for the suggestion.

Tore