Subject: Non-/96 pref64 use cases

From: Jen Linkova <[email-masked]>
Date: Wed, 7 Nov 2018 14:31:34 +1100

It looks like there are a number of options to encode non/96 pref64 in
an RA but before we start discussing them I'd like to understand the
use case better.

Even after re-reading RFC6052 I'm not sure what practical problem can
not be solved with /96 prefix and requires using shorter pref64?

Could anyone describe a use case for this?

The only one I can this of is using the network equipment which is not
capable of carrying routes longer than /64.

Xing, AFAIR you made a comment yesterday saying that you have a use
case for non-/96 prefixes. Would you be able to elaborate on this?

Thanks!
-- 
SY, Jen Linkova aka Furry

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Nov 2018 10:56:38 +0700

> On Nov 7, 2018, at 10:31 AM, Jen Linkova <[email-masked]> wrote:
> 

The CERNET2 situation is this. They have 1000+ campuses, and distribute one or more IPv4 translation prefixes among IPv6-only servers in the network that are accessible from the IPv4-only CERNET via stateless translation. Having the embedded IPv4 prefix straddle bit 64 means that they can route from the translator to data centers whose prefix is the upper part of an IPv4 address embedded in an IPv6 prefix, and the lower part of the address is in the IID. The servers themselves are IPv6-only, and can't distinguish the IPv4-embedded IPv6 addresses from other IPv6 addresses.

It's all about routing.

Yes, they could use a /96 prefix, if they have a LOT MORE IPv4 prefixes work with.

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 11:16:33 +0700

On Wed, Nov 7, 2018 at 10:57 AM Fred Baker <[email-masked]> wrote:

> The CERNET2 situation is this. They have 1000+ campuses, and distribute
> one or more IPv4 translation prefixes among IPv6-only servers in the
> network that are accessible from the IPv4-only CERNET via stateless
> translation. Having the embedded IPv4 prefix straddle bit 64 means that
> they can route from the translator to data centers whose prefix is the
> upper part of an IPv4 address embedded in an IPv6 prefix, and the lower
> part of the address is in the IID. The servers themselves are IPv6-only,
> and can't distinguish the IPv4-embedded IPv6 addresses from other IPv6
> addresses.
>
> It's all about routing.
>

Fred, that explanation isn't very easy to understand. Could you provide an
example?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 14:33:38 +0700

Thanks for the explanation. That doesn't answer the question on why the
translators can't use a /96 prefix though, right? The first 96 bits would
identify the individual translator, and the remaining 32 bits would
identify the IPv4 address.

Also, is DNS64 in use in this network? If it's just transparent stateless
translation, then there's no need for DNS64 translation or synthesis,
right?

On Wed, Nov 7, 2018 at 2:24 PM Fred Baker <[email-masked]> wrote:

>
>
> On Nov 7, 2018, at 11:16 AM, Lorenzo Colitti <[email-masked]> wrote:
> >> Fred, that explanation isn't very easy to understand. Could you provide
> an example?
>
> I'll try. First, though, let's point out that the use of a well-known
> prefix starts with an assumption: Anything with an IPv4 address may be
> found on the other side of the translator advertising that prefix in
> routing, and if there are multiple such translators, they are operating as
> an anycast service - I can go to any of them, perhaps even
> packet-by-packet, and achieve the same result.
>
> What if that assumption doesn't hold? If you don't answer that question,
> the rest of this will be gibberish. In CERNET, that assumption doesn't
> hold. There is not a single "IPv4 is over there". If you want to force that
> to become true, they need to redesign the network.
>
> Now, the obvious use case for multiple non-well-known prefixes on the IPv6
> side of such a translator is that I can distinguish among IPv4 address
> spaces, if I choose to, and send this subset to this translator and that
> subset to that; I would do so by having multiple IPv6 prefixes, one for
> each instance of an IPv4 space. I could do the same on the IPv4 side of the
> translator, but I would do so in routing, by assigning specific IPv4
> prefixes to specific domains and then advertising them appropriately in
> IPv4 routing. It requires some additional administrative effort, but it is
> possible.
>
> The CERNET/CERNET2 situation is that China has at least 2000 universities
> using IPv4, about 1000 of which also use IPv6. They have a national NREN
> connecting them. Xing has built that NREN as two separate backbones, one of
> which is IPv4-only (CERNET) and the other is IPv6-only (and has a lot more
> capacity). Many of the universities that are dual stack offer services that
> are used throughout the network, and need to be accessible both by IPv4 and
> IPv6. How to do that?
>
> What CERNET has chosen to do (I won't argue that it's the only way to do
> it, but it is in fact what they have chosen) is that they provide a common
> IPv6 prefix for their universities (2001:2a00::/n, for some value of n),
> and several IPv4 prefixes, some of which are shared by multiple
> universities. See attached for a set of pictures. One additional
> consideration is that they would like to be able to move servers from one
> campus or data center to another without necessarily having to renumber it.
>
> So having the IPv4 prefix straddle bit 64 in the IPv6 address it gets
> embedded into enables them to use IPv6 routing to divide hosts implementing
> some specific service using routing, even if they share an IPv4 prefix.
> Since it is stateless translation, it doesn't have all of the weaknesses of
> per-session NAT (NAT44 or NAT64 being examples), a number of the issues
> raised in RFC 2993 - those that aren't related to having the IP address in
> a header above IP's - are less of an issue.
>
>
> Victorious warriors win first and then go to war,
> Defeated warriors go to war first and then seek to win.
>      Sun Tzu
>
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Nov 2018 14:40:07 +0700

> On Nov 7, 2018, at 2:33 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> Thanks for the explanation. That doesn't answer the question on why the translators can't use a /96 prefix though, right? The first 96 bits would identify the individual translator, and the remaining 32 bits would identify the IPv4 address.

In responding to an IPv4 request, that works. The request came through a translator, and got to the IPv6 server with the relevant prefix intact. If they are initiating q request to an IPv4 server from the IPv6 side, They have to somehow select the translator. That is in some sense the issue addressed in pref64, but every IPv4 prefix might have a different relevant translator.

"It's complicated".

> Also, is DNS64 in use in this network? If it's just transparent stateless translation, then there's no need for DNS64 translation or synthesis, right?

I'll leave that to Xing.

> >> Fred, that explanation isn't very easy to understand. Could you provide an example?
> 
> I'll try. First, though, let's point out that the use of a well-known prefix starts with an assumption: Anything with an IPv4 address may be found on the other side of the translator advertising that prefix in routing, and if there are multiple such translators, they are operating as an anycast service - I can go to any of them, perhaps even packet-by-packet, and achieve the same result.
> 
> What if that assumption doesn't hold? If you don't answer that question, the rest of this will be gibberish. In CERNET, that assumption doesn't hold. There is not a single "IPv4 is over there". If you want to force that to become true, they need to redesign the network.
> 
> Now, the obvious use case for multiple non-well-known prefixes on the IPv6 side of such a translator is that I can distinguish among IPv4 address spaces, if I choose to, and send this subset to this translator and that subset to that; I would do so by having multiple IPv6 prefixes, one for each instance of an IPv4 space. I could do the same on the IPv4 side of the translator, but I would do so in routing, by assigning specific IPv4 prefixes to specific domains and then advertising them appropriately in IPv4 routing. It requires some additional administrative effort, but it is possible.
> 
> The CERNET/CERNET2 situation is that China has at least 2000 universities using IPv4, about 1000 of which also use IPv6. They have a national NREN connecting them. Xing has built that NREN as two separate backbones, one of which is IPv4-only (CERNET) and the other is IPv6-only (and has a lot more capacity). Many of the universities that are dual stack offer services that are used throughout the network, and need to be accessible both by IPv4 and IPv6. How to do that?
> 
> What CERNET has chosen to do (I won't argue that it's the only way to do it, but it is in fact what they have chosen) is that they provide a common IPv6 prefix for their universities (2001:2a00::/n, for some value of n), and several IPv4 prefixes, some of which are shared by multiple universities. See attached for a set of pictures. One additional consideration is that they would like to be able to move servers from one campus or data center to another without necessarily having to renumber it.
> 
> So having the IPv4 prefix straddle bit 64 in the IPv6 address it gets embedded into enables them to use IPv6 routing to divide hosts implementing some specific service using routing, even if they share an IPv4 prefix. Since it is stateless translation, it doesn't have all of the weaknesses of per-session NAT (NAT44 or NAT64 being examples), a number of the issues raised in RFC 2993 - those that aren't related to having the IP address in a header above IP's - are less of an issue.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 14:42:12 +0700

On Wed, Nov 7, 2018 at 2:40 PM Fred Baker <[email-masked]> wrote:

> In responding to an IPv4 request, that works. The request came through a
> translator, and got to the IPv6 server with the relevant prefix intact. If
> they are initiating q request to an IPv4 server from the IPv6 side, They
> have to somehow select the translator. That is in some sense the issue
> addressed in pref64, but every IPv4 prefix might have a different relevant
> translator.
>

Ok. Then I suppose better questions would be: why does this work with
non-/96 prefixes? Doesn't any prefix length have the problem that the host
doesn't need to know what translator to send the packet to?

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Nov 2018 14:54:05 +0700

> On Nov 7, 2018, at 2:42 PM, Lorenzo Colitti <[email-masked]> wrote:
> Ok. Then I suppose better questions would be: why does this work with non-/96 prefixes? Doesn't any prefix length have the problem that the host doesn't need to know what translator to send the packet to?

I think for most cases there are a small number of translators in the network; certainly, anyone that thinks a well-known-prefix is a good idea isn't normally dealing with more than one or two. I would make the same comment about /96 prefixes. How often have we argued about the length of an IID? We had to issue at RFC to tell a certain chip vendor that a routing prefix longer than 64 bits was a reality. Now we're suggesting that the routing prefix in CERNET might be 96+n bits in length - the IPv6 prefix and part of the IPv4 address.

Remember that CERNET started the IPv6-only path in 2008, not 2018. Building stuff with today's hardware might be possible; I'm pretty sure it wasn't ten years ago. You first asked why CERNET did what they did; I think you understand that now. Could they renumber their network to do it your favorite way? Hmmm, maybe. Who's paying? Is there intent for the specifications to remain backward compatible with previous deployments? Removing a capability that is not used, and I think there are several in 6052, probably makes sense. If there is a capability that is in use, I'd like to argue in favor of backward compatibility.
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 15:20:23 +0700

On Wed, Nov 7, 2018 at 2:54 PM Fred Baker <[email-masked]> wrote:

> I think for most cases there are a small number of translators in the
> network; certainly, anyone that thinks a well-known-prefix is a good idea
> isn't normally dealing with more than one or two. I would make the same
> comment about /96 prefixes. How often have we argued about the length of an
> IID? We had to issue at RFC to tell a certain chip vendor that a routing
> prefix longer than 64 bits was a reality. Now we're suggesting that the
> routing prefix in CERNET might be 96+n bits in length - the IPv6 prefix and
> part of the IPv4 address.
>

It's the same reality, right? Routers "MUST be designed to process prefixes
of any length up to /128". BCP 198.

> Remember that CERNET started the IPv6-only path in 2008, not 2018.
> Building stuff with today's hardware might be possible; I'm pretty sure it
> wasn't ten years ago. You first asked why CERNET did what they did; I think
> you understand that now. Could they renumber their network to do it your
> favorite way? Hmmm, maybe. Who's paying? Is there intent for the
> specifications to remain backward compatible with previous deployments?
> Removing a capability that is not used, and I think there are several in
> 6052, probably makes sense. If there is a capability that is in use, I'd
> like to argue in favor of backward compatibility.
>

I see. So if I understand correctly, the situation is:

   1. RFC 6052 defines non-/96 prefixes.
   2. For historical reasons related to hardware support, the Cernet
   network uses non-/96 prefixes.
   3. From a standards perspective, those reasons are no longer relevant
   today due to BCP 198.
   4. Current NAT64 detection techniques (e.g., RFC 7050) allow detecting
   non-/96 prefixes. However, Xing's testing indicates that current host
   implementations do not support this and only support /96.

So I guess the question before the WG is: when defining this new way of
doing NAT64 detection, should we support non-/96 prefixes?

My answer to this would be no, because:

   - If we think the reasons for non-/96 prefixes are no longer relevant
   today, then it's not likely we'll see new networks use them in the future.
   - Therefore, it's likely that existing implementations, which today
   support RFC7050 but not non-/96, are not likely to support non-/96 prefixes
   with this new option, even if we allow them.
   - If implementations aren't going to implement this, then there seems
   little point allowing them in this new option.

But I don't feel too strongly about it.

---

From: Fred Baker <[email-masked]>
Date: Wed, 7 Nov 2018 16:05:50 +0700

> On Nov 7, 2018, at 3:20 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> It's the same reality, right? Routers "MUST be designed to process prefixes of any length up to /128". BCP 198.

Not really. Older equipment may have been built before we sent that memo, and the design was done before we sent that memo. I don't know what equipment Xing has, but I wouldn't be amazed if some of it has that limitation.

> 	• RFC 6052 defines non-/96 prefixes.
> 	• For historical reasons related to hardware support, the Cernet network uses non-/96 prefixes.

Well, CERNET uses the design because it solves a problem they were trying to solve. The argument for the continuing to use it is that they already are.

> 	• From a standards perspective, those reasons are no longer relevant today due to BCP 198.
> 	• Current NAT64 detection techniques (e.g., RFC 7050) allow detecting non-/96 prefixes. However, Xing's testing indicates that current host implementations do not support this and only support /96.
> So I guess the question before the WG is: when defining this new way of doing NAT64 detection, should we support non-/96 prefixes?
> 
> 	• If we think the reasons for non-/96 prefixes are no longer relevant today, then it's not likely we'll see new networks use them in the future.
> 	• Therefore, it's likely that existing implementations, which today support RFC7050 but not non-/96, are not likely to support non-/96 prefixes with this new option, even if we allow them.
> 	• If implementations aren't going to implement this, then there seems little point allowing them in this new option.

I guess I start by wondering why we need to detect a NAT in the path. We received a packet that had an IPv6 source address, and we swap the addresses to reply to it. What, precisely, is the utility of detecting the NAT in the path? To enforce operationally the biases and whims of IETF architects? Does it actually buy the user or the operator anything?

So I would concur that it isn't needed, but my reasons are different.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 16:29:29 +0700

On Wed, Nov 7, 2018 at 4:05 PM Fred Baker <[email-masked]> wrote:

> >       • If we think the reasons for non-/96 prefixes are no longer
> relevant today, then it's not likely we'll see new networks use them in the
> future.
> >       • Therefore, it's likely that existing implementations, which
> today support RFC7050 but not non-/96, are not likely to support non-/96
> prefixes with this new option, even if we allow them.
> >       • If implementations aren't going to implement this, then there
> seems little point allowing them in this new option.
> I guess I start by wondering why we need to detect a NAT in the path. We
> received a packet that had an IPv6 source address, and we swap the
> addresses to reply to it. What, precisely, is the utility of detecting the
> NAT in the path? To enforce operationally the biases and whims of IETF
> architects? Does it actually buy the user or the operator anything?
>

NAT64 is used if a node only has IPv6 and wants to talk to a node that only
has IPv4. Detecting the NAT64 is useful if the node wants to synthesize
AAAA records starting from A records. If that's not what is used in cernet,
then yes, this option is not useful.

Also, it occurs to me that if Cernet uses multiple translators each with
its own prefix, this option is not really useful there. Even if we include
one option in the RA for each translation prefix, the host receiving the RA
won't know which prefix to use for a given destination.

---

From: Xing Li <[email-masked]>
Date: Wed, 07 Nov 2018 17:58:19 +0800

Hi, Jen, Fred, Lorenzo and All.

Thank you very much for the comments.

The CERNET use case is:

(1) We have been using RFC6052 non-/96 prefix length in most of the 
cases, because of the historical reasons (some old routers are still be 
used).

(2) We are happy that RFC7050 supports non-/96 prefix length in the 
standard. We hope that the new versions of Andriod, iOS (and Win10) can 
implement non-/96 prefix length, since that will give ISP more operation 
freedom.

(3) The major reason that CERNET needs non-/96 prefix length now is that 
we lack the public IPv4 addresses, so we use suffix defined in RFC6052 
to embed PSID (see Figure) for sharing the public IPv4 addresses among 
IPv6 servers.. In this case, non-/96 prefix length is required.

    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    |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)     |
    +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

                                 Figure 1

suffix=PSID

Note that in the case of IPv6-to-IPv6 communication, it will not go to 
the translator. However, if for some reason the DNS64 uses A record to 
generate the AAAA record, then we want the pref64 be the same as the 
real IPv6 address and therefore double translation can be avoided.

For the stateless translation, DNS64 is not required for the IPv6-only 
servers, but DNS64 is required for the clients to access the global IPv4 
Internet.

In summary, we would like this RA pref64 extension to be compatible with 
RFC7050 and allow non/96 prefix length. Thank you verymuch!

Regards,

xing

Lorenzo Colitti 写道:
> On Wed, Nov 7, 2018 at 2:54 PM Fred Baker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Ok. Then I suppose better questions would be: why does this work
>     with non-/96 prefixes? Doesn't any prefix length have the problem
>     that the host doesn't need to know what translator to send the
>     packet to?
>
>     I think for most cases there are a small number of translators in
>     the network; certainly, anyone that thinks a well-known-prefix is
>     a good idea isn't normally dealing with more than one or two. I
>     would make the same comment about /96 prefixes. How often have we
>     argued about the length of an IID? We had to issue at RFC to tell
>     a certain chip vendor that a routing prefix longer than 64 bits
>     was a reality. Now we're suggesting that the routing prefix in
>     CERNET might be 96+n bits in length - the IPv6 prefix and part of
>     the IPv4 address.
>
>
> It's the same reality, right? Routers "MUST be designed to process 
> prefixes of any length up to /128". BCP 198.
>  
>
>     Building stuff with today's hardware might be possible; I'm pretty
>     sure it wasn't ten years ago. You first asked why CERNET did what
>     they did; I think you understand that now. Could they renumber
>     their network to do it your favorite way? Hmmm, maybe. Who's
>     paying? Is there intent for the specifications to remain backward
>     compatible with previous deployments? Removing a capability that
>     is not used, and I think there are several in 6052, probably makes
>     sense. If there is a capability that is in use, I'd like to argue
>     in favor of backward compatibility.
>
>
>    3. From a standards perspective, those reasons are no longer
>       relevant today due to BCP 198.
>    4. Current NAT64 detection techniques (e.g., RFC 7050) allow
>       detecting non-/96 prefixes. However, Xing's testing indicates
>       that current host implementations do not support this and only
>       support /96.
>
> So I guess the question before the WG is: when defining this new way 
> of doing NAT64 detection, should we support non-/96 prefixes?
>
>     * If we think the reasons for non-/96 prefixes are no longer
>       relevant today, then it's not likely we'll see new networks use
>       them in the future.
>     * Therefore, it's likely that existing implementations, which
>       today support RFC7050 but not non-/96, are not likely to support
>       non-/96 prefixes with this new option, even if we allow them.
>     * If implementations aren't going to implement this, then there

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 17:18:41 +0700

Xing,

can you explain how the device would use the prefix that it has learned?
How the bits in the suffix are used, etc.?

Cheers,
Lorenzo

On Wed, Nov 7, 2018 at 4:58 PM Xing Li <[email-masked]> wrote:

> (1) We have been using RFC6052 non-/96 prefix length in most of the cases,
> because of the historical reasons (some old routers are still be used).
>
> we lack the public IPv4 addresses, so we use suffix defined in RFC6052 to
> embed PSID (see Figure) for sharing the public IPv4 addresses among IPv6
> servers.. In this case, non-/96 prefix length is required.
>
> Note that in the case of IPv6-to-IPv6 communication, it will not go to the
> translator. However, if for some reason the DNS64 uses A record to generate
> the AAAA record, then we want the pref64 be the same as the real IPv6
> address and therefore double translation can be avoided.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Nov 2018 17:19:22 +0700

(assuming this is not already documented in an IETF or other document, of
course)

On Wed, Nov 7, 2018 at 5:18 PM Lorenzo Colitti <[email-masked]> wrote:

>> generate the AAAA record, then we want the pref64 be the same as the real
>> IPv6 address and therefore double translation can be avoided.
>>
>>    detecting non-/96 prefixes. However, Xing's testing indicates that current
>>    host implementations do not support this and only support /96.
>>

---

From: Xing Li <[email-masked]>
Date: Wed, 07 Nov 2018 22:50:22 +0800

Lorenzo Colitti 写道:
> (assuming this is not already documented in an IETF or other document, 
> of course)
>
> On Wed, Nov 7, 2018 at 5:18 PM Lorenzo Colitti <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Xing,
>
>     can you explain how the device would use the prefix that it has
>     learned? How the bits in the suffix are used, etc.?
>

It is somehow documented in RFC7597/RFC7599 (MAP-E/MAP-T)

Section 6 of RFC7597 says:
{
6.  The IPv6 Interface Identifier

   The interface identifier format of a MAP node is described below.

                   |          128-n-o-s bits          |
                   | 16 bits|    32 bits     | 16 bits|
                   +--------+----------------+--------+
                   |   0    |  IPv4 address  |  PSID  |
                   +--------+----------------+--------+

                    Figure 8: IPv6 Interface Identifier

   In the case of an IPv4 prefix, the IPv4 address field is right-padded
   with zeros up to 32 bits.  The PSID field is left-padded with zeros
   to create a 16-bit field.  For an IPv4 prefix or a complete IPv4
   address, the PSID field is zero.
}

Regards,

xing

>
>     Cheers,
>     Lorenzo
>
>     On Wed, Nov 7, 2018 at 4:58 PM Xing Li <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         (1) We have been using RFC6052 non-/96 prefix length in most
>         of the cases, because of the historical reasons (some old
>         routers are still be used).
>
>         (2) We are happy that RFC7050 supports non-/96 prefix length
>         in the standard. We hope that the new versions of Andriod, iOS
>         (and Win10) can implement non-/96 prefix length, since that
>         will give ISP more operation freedom.
>
>         (3) The major reason that CERNET needs non-/96 prefix length
>         now is that we lack the public IPv4 addresses, so we use
>         suffix defined in RFC6052 to embed PSID (see Figure) for
>         sharing the public IPv4 addresses among IPv6 servers.. In this
>         case, non-/96 prefix length is required.
>
>         Note that in the case of IPv6-to-IPv6 communication, it will
>         not go to the translator. However, if for some reason the
>         DNS64 uses A record to generate the AAAA record, then we want
>         the pref64 be the same as the real IPv6 address and therefore
>         double translation can be avoided.
>
>         For the stateless translation, DNS64 is not required for the
>         IPv6-only servers, but DNS64 is required for the clients to
>         access the global IPv4 Internet.
>
>         In summary, we would like this RA pref64 extension to be
>         compatible with RFC7050 and allow non/96 prefix length. Thank
>         you verymuch!
>
>         Regards,
>
>         xing
>
>
>
>         Lorenzo Colitti 写道:
>>         On Wed, Nov 7, 2018 at 2:54 PM Fred Baker
>>         <[email-masked] <mailto:[email-masked]>>
>>         wrote:
>>
>>             > Ok. Then I suppose better questions would be: why does
>>             this work with non-/96 prefixes? Doesn't any prefix
>>             length have the problem that the host doesn't need to
>>             know what translator to send the packet to?
>>
>>             I think for most cases there are a small number of
>>             translators in the network; certainly, anyone that thinks
>>             a well-known-prefix is a good idea isn't normally dealing
>>             with more than one or two. I would make the same comment
>>             about /96 prefixes. How often have we argued about the
>>             length of an IID? We had to issue at RFC to tell a
>>             certain chip vendor that a routing prefix longer than 64
>>             bits was a reality. Now we're suggesting that the routing
>>             prefix in CERNET might be 96+n bits in length - the IPv6
>>             prefix and part of the IPv4 address.
>>
>>
>>         It's the same reality, right? Routers "MUST be designed to
>>         process prefixes of any length up to /128". BCP 198.
>>          
>>
>>             Remember that CERNET started the IPv6-only path in 2008,
>>             not 2018. Building stuff with today's hardware might be
>>             possible; I'm pretty sure it wasn't ten years ago. You
>>             first asked why CERNET did what they did; I think you
>>             understand that now. Could they renumber their network to
>>             do it your favorite way? Hmmm, maybe. Who's paying? Is
>>             there intent for the specifications to remain backward
>>             compatible with previous deployments? Removing a
>>             capability that is not used, and I think there are
>>             several in 6052, probably makes sense. If there is a
>>             capability that is in use, I'd like to argue in favor of
>>             backward compatibility.
>>
>>
>>            2. For historical reasons related to hardware support, the
>>               Cernet network uses non-/96 prefixes.
>>            3. From a standards perspective, those reasons are no
>>               longer relevant today due to BCP 198.
>>            4. Current NAT64 detection techniques (e.g., RFC 7050)
>>               allow detecting non-/96 prefixes. However, Xing's
>>               testing indicates that current host implementations do
>>               not support this and only support /96.
>>
>>         So I guess the question before the WG is: when defining this
>>         new way of doing NAT64 detection, should we support non-/96
>>         prefixes?
>>
>>             * If we think the reasons for non-/96 prefixes are no
>>               longer relevant today, then it's not likely we'll see
>>               new networks use them in the future.
>>             * Therefore, it's likely that existing implementations,
>>               which today support RFC7050 but not non-/96, are not
>>               likely to support non-/96 prefixes with this new
>>               option, even if we allow them.
>>             * If implementations aren't going to implement this, then
>>               there seems little point allowing them in this new option.
>>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 07 Nov 2018 22:28:45 +0700

Hi Xing,

I think we are getting confused them.

Unless I got it wrong:

- RFC7050 is meant for stateful NAT64 (RFC6146), but you’re using stateless translation, so should not be using this.

- RFC6052 can be used for both, stateless (only with an NSP) or stateful (NSP or WKP).

- draft-pref64folks-6man-ra-pref64 seems to me oriented to consider only stateful NAT64

And the use case that you’re documenting seems to be MAP-T (RFC7599), which uses RFC6052, but not RFC7050.

So, it looks like draft-pref64folks-6man-ra-pref64 should not be used, as well as RFC7050, because the provisioning of the prefixes in your case, is done by means of DHCPv6 (RFC7598).

If in your case, you use RFC7050, may be is working, but is not a “defined” case. Not saying is wrong, but I think we need further clarification about all this to better understand the need and if may be RFC7050 should be modified to support stateless NAT64, etc.

Regards,

Jordi

De: ipv6 <[email-masked]> en nombre de Xing Li <[email-masked]>
Fecha: miércoles, 7 de noviembre de 2018, 21:51
Para: Lorenzo Colitti <[email-masked]>
CC: Xing Li <[email-masked]>, IETF IPv6 Mailing List <[email-masked]>, congxiao <[email-masked]>
Asunto: Re: Non-/96 pref64 use cases

Lorenzo Colitti 写道: 

(assuming this is not already documented in an IETF or other document, of course)

Xing,

can you explain how the device would use the prefix that it has learned? How the bits in the suffix are used, etc.?

                   |          128-n-o-s bits          |

Regards,

xing

Cheers,

Lorenzo

The CERNET use case is:

(1) We have been using RFC6052 non-/96 prefix length in most of the cases, because of the historical reasons (some old routers are still be used).

(2) We are happy that RFC7050 supports non-/96 prefix length in the standard. We hope that the new versions of Andriod, iOS (and Win10) can implement non-/96 prefix length, since that will give ISP more operation freedom.

(3) The major reason that CERNET needs non-/96 prefix length now is that we lack the public IPv4 addresses, so we use suffix defined in RFC6052 to embed PSID (see Figure) for sharing the public IPv4 addresses among IPv6 servers.. In this case, non-/96 prefix length is required.
 
                                 Figure 1
suffix=PSID

Note that in the case of IPv6-to-IPv6 communication, it will not go to the translator. However, if for some reason the DNS64 uses A record to generate the AAAA record, then we want the pref64 be the same as the real IPv6 address and therefore double translation can be avoided.

For the stateless translation, DNS64 is not required for the IPv6-only servers, but DNS64 is required for the clients to access the global IPv4 Internet. 

In summary, we would like this RA pref64 extension to be compatible with RFC7050 and allow non/96 prefix length. Thank you verymuch!

Regards,

xing 

Lorenzo Colitti 写道: 

2.       For historical reasons related to hardware support, the Cernet network uses non-/96 prefixes.

3.       From a standards perspective, those reasons are no longer relevant today due to BCP 198.

4.       Current NAT64 detection techniques (e.g., RFC 7050) allow detecting non-/96 prefixes. However, Xing's testing indicates that current host implementations do not support this and only support /96.

·         If we think the reasons for non-/96 prefixes are no longer relevant today, then it's not likely we'll see new networks use them in the future.

·         Therefore, it's likely that existing implementations, which today support RFC7050 but not non-/96, are not likely to support non-/96 prefixes with this new option, even if we allow them.

·         If implementations aren't going to implement this, then there seems little point allowing them in this new option.

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- 

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Xing Li <[email-masked]>
Date: Thu, 08 Nov 2018 11:23:03 +0800

Hi, JORDI,

Let's consider the examples using figure in RFC6144

 Scenario 1: An IPv6 Network to the IPv4 Internet
               --------
             //        \\       -----------
            /            \     //          \\
           /             +----+              \
          |              |XLAT|               |
          |  The IPv4    +----+  An IPv6      |
          |  Internet    +----+  Network      |  XLAT: IPv6/IPv4
          |              |DNS |               |        Translator
           \             +----+              /   DNS:  DNS64
            \            /     \\          //
             \\        //       -----------
                --------
                          <====

                           Figure 1: Scenario 1

1. RFC7050 case:

1.1 Stateful translation with RFC7050 (/96) and SLAAC for the client 
(current service in CERNET for Andriod and iOS)

IPv6 pref2=2001:da8:1234::/96 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the 
IPv4 Internet is 5.6.7.8)
Use RFC7050 to find pref64 = 2001:da8:1234::/96

1.2 Stateless translation with RFC7050 (/96 only) and DHCPv6 stateful 
for the client (current service in CERNET for iOS)

IPv6 pref1=2001:da8:beef::/48 (prefix for the source)
IPv6 pref2=2001:da8:1234::/96 (prefix for the destination, i.e. pref64)
IPv4-translatable address = 2001:da8:beef:0102:0304::PSID (1.2.3.4 is 
the public IPv4 address)
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the 
IPv4 Internet is 5.6.7.8)
Use RFC7050 to find pref64 = 2001:da8:1234::/96
This requires hairpin.

1.3 Stateless translation with RFC7050 (when non-/96 works) and DHCPv6 
stateful for the client current service in CERNET for iOS, but cannot 
support IPv4 literal embedded in the application)

IPv6 pref=2001:da8:beef::/48 (same prefix for the source and the 
destination)
IPv4-translatable address = 2001:da8:beef:0102:0304::PSID (1.2.3.4 is 
the public IPv4 address)
IPv4-converted address = 2001:da8:beef:0506:0708:: (IPv4 server in the 
IPv4 Internet is 5.6.7.8)
We want to use RFC7050 to find non-/96 pref64 = 2001:da8:beef::/48
This supports optimal routing based on maximum prefix length match.

2. draft-pref64folks-6man-ra-pref64 case:

2.1 Stateful translation with draft-pref64folks-6man-ra-pref64 (/96) and 
SLAAC for the client

IPv6 pref2=2001:da8:1234::/96 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the 
IPv4 Internet 5.6.7.8)
We can use draft-pref64folks-6man-ra-pref64 to find pref64 = 
2001:da8:1234::/96

Now consider the case I gave in the previous mail, that is the case an 
IPv6 network both have IPv6-only clients (SLAAC) and IPv6-only servers 
(with IPv4 public address sharing)

> The major reason that CERNET needs non-/96 prefix length now is that 
> ......
2.1 Stateful translation with draft-pref64folks-6man-ra-pref64 (when 
non-/96 works) and SLAAC for the client

IPv6 pref=2001:da8:beef::/48 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address1 = 2001:da8:beef:0506:0708:: (IPv4 server in the 
IPv4 Internet 5.6.7.8)
IPv4-converted address2 = 2001:da8:beef:090a:0b0c:: (IPv4 server in an 
IPv6 network 9.10.11.12)
We want to use draft-pref64folks-6man-ra-pref64 to find non-/96 pref64 = 
2001:da8:beef::/48

JORDI PALET MARTINEZ 写道:
> - RFC7050 is meant for stateful NAT64 (RFC6146), but you’re using 
> stateless translation, so should not be using this.
>

See 1.2  and 1.3 above
> - RFC6052 can be used for both, stateless (only with an NSP) or 
Agree.
> - draft-pref64folks-6man-ra-pref64 seems to me oriented to consider 
For the client, yes. But if we consider an IPv6 network which consists 
both clients and servers, then there is a use case.
> which uses RFC6052, but not RFC7050.
It uses RFC7599's address format, but it is a single IPv4/IPv6 
translation,therefor RFC7050 is needed.
>
>  
>
> So, it looks like draft-pref64folks-6man-ra-pref64 should not be used, 
> as well as RFC7050, because the provisioning of the prefixes in your 
> case, is done by means of DHCPv6 (RFC7598).
>
>  
>
> If in your case, you use RFC7050, may be is working, but is not a 
> “defined” case. Not saying is wrong, but I think we need further 
> clarification about all this to better understand the need and if may 
> be RFC7050 should be modified to support stateless NAT64, etc.
>

See above examples.

In summary, since /96 is a special case of variable prefix length, why 
not define non-/96 in draft-pref64folks-6man-ra-pref64 at this stage 
(even with a little bit more overhead). This will save a lot of energy 
for both the standard work and more important, the upgrading work for 
supporting different OSs.

Thanks,

xing

>
> Regards,
>
> Jordi
>
>  
>
>  
>
>  
>
> *De: *ipv6 <[email-masked]> en nombre de Xing Li 
> <[email-masked]>
> *Fecha: *miércoles, 7 de noviembre de 2018, 21:51
> *Para: *Lorenzo Colitti <[email-masked]>
> *CC: *Xing Li <[email-masked]>, IETF IPv6 Mailing List 
> <[email-masked]>, congxiao <[email-masked]>
> *Asunto: *Re: Non-/96 pref64 use cases
>
>  
>
> Lorenzo Colitti 写道:
>
>         can you explain how the device would use the prefix that it
>         has learned? How the bits in the suffix are used, etc.?
>
>
>             (1) We have been using RFC6052 non-/96 prefix length in
>             most of the cases, because of the historical reasons (some
>             old routers are still be used).
>
>             (2) We are happy that RFC7050 supports non-/96 prefix
>             length in the standard. We hope that the new versions of
>             Andriod, iOS (and Win10) can implement non-/96 prefix
>             length, since that will give ISP more operation freedom.
>
>             (3) The major reason that CERNET needs non-/96 prefix
>             length now is that we lack the public IPv4 addresses, so
>             we use suffix defined in RFC6052 to embed PSID (see
>             Figure) for sharing the public IPv4 addresses among IPv6
>             Note that in the case of IPv6-to-IPv6 communication, it
>             will not go to the translator. However, if for some reason
>             the DNS64 uses A record to generate the AAAA record, then
>             we want the pref64 be the same as the real IPv6 address
>             and therefore double translation can be avoided.
>
>             For the stateless translation, DNS64 is not required for
>             the IPv6-only servers, but DNS64 is required for the
>             clients to access the global IPv4 Internet.
>
>             compatible with RFC7050 and allow non/96 prefix length.
>             Thank you verymuch!
>
>             Regards,
>
>             xing
>
>
>
>             Lorenzo Colitti 写道:
>
>                 <[email-masked]
>                     > Ok. Then I suppose better questions would be:
>                     why does this work with non-/96 prefixes? Doesn't
>                     any prefix length have the problem that the host
>                     translators in the network; certainly, anyone that
>                     thinks a well-known-prefix is a good idea isn't
>                     normally dealing with more than one or two. I
>                     would make the same comment about /96 prefixes.
>                     How often have we argued about the length of an
>                     IID? We had to issue at RFC to tell a certain chip
>                     vendor that a routing prefix longer than 64 bits
>                     was a reality. Now we're suggesting that the
>                     routing prefix in CERNET might be 96+n bits in
>                     length - the IPv6 prefix and part of the IPv4 address.
>
>                  
>
>                 It's the same reality, right? Routers "MUST be
>                 designed to process prefixes of any length up to
>                 /128". BCP 198.
>
>                  
>
>                     Remember that CERNET started the IPv6-only path in
>                     2008, not 2018. Building stuff with today's
>                     hardware might be possible; I'm pretty sure it
>                     wasn't ten years ago. You first asked why CERNET
>                     did what they did; I think you understand that
>                     now. Could they renumber their network to do it
>                     your favorite way? Hmmm, maybe. Who's paying? Is
>                     there intent for the specifications to remain
>                     backward compatible with previous deployments?
>                     Removing a capability that is not used, and I
>                     think there are several in 6052, probably makes
>                     sense. If there is a capability that is in use,
>                     I'd like to argue in favor of backward compatibility.
>
>                  
>
>                 2.       For historical reasons related to hardware
>                 support, the Cernet network uses non-/96 prefixes.
>
>                 3.       From a standards perspective, those reasons
>                 are no longer relevant today due to BCP 198.
>
>                 4.       Current NAT64 detection techniques (e.g., RFC
>                 7050) allow detecting non-/96 prefixes. However,
>                 Xing's testing indicates that current host
>                 So I guess the question before the WG is: when
>                 defining this new way of doing NAT64 detection, should
>                 we support non-/96 prefixes?
>
>                  
>
>                 ·         If we think the reasons for non-/96 prefixes
>                 are no longer relevant today, then it's not likely
>                 we'll see new networks use them in the future.
>
>                 ·         Therefore, it's likely that existing
>                 implementations, which today support RFC7050 but not
>                 non-/96, are not likely to support non-/96 prefixes
>                 ·         If implementations aren't going to implement
>                 this, then there seems little point allowing them in
>                 this new option.
>
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative 
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>
>
> This electronic message contains information which may be privileged 
> or confidential. The information is intended to be for the exclusive 
> use of the individual(s) named above and further non-explicilty 
> authorized disclosure, copying, distribution or use of the contents of 
> this information, even if partially, including attached files, is 
> strictly prohibited and will be considered a criminal offense. If you 
> are not the intended recipient be aware that any disclosure, copying, 
> distribution or use of the contents of this information, even if 
> partially, including attached files, is strictly prohibited, will be 
> considered a criminal offense, so you must reply to the original 
> sender to inform about this communication and delete it.
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Nov 2018 13:13:09 +0700

Hi Xing,

I think I understand now better your case, but still my point is that RFC7050 was only meant for stateful NAT64 prefix discovery and you want to use it for stateless (or use draft-pref64folks-6man-ra-pref64, which is also -now- meant as a better choice than RFC7050). Is a matter of what we have defined “today” not that I disagree to change that.

However, I think there is a simpler solution for you.

You’re assuming that clients and servers need to use the “same” protocol for both, internal CERNET communication and communication to outside Internet, which I think it makes it more complex.

You can just keep in the client LANs a regular CLAT function, while the servers use the mechanisms that you are already using, and ad the same time solve the literal problems, etc. for clients.

Communication inside CERNET network will be IPv6, clients will have full support of IPv4-Internet by means of the CLAT (regardless of using SLAAC or DHCPv6), and servers will keep using your actual setup. In the worst case, may be is not needed, servers need to have different addresses (may be in different interfaces, or by means of load balances, or firewall rules, etc.), depending on if the communication is inside CERNET or to/from Internet.

I don’t disagree either that draft-pref64folks-6man-ra-pref64 could support both choices, but may be if your scenario is the only case, and is sorted out as I suggested, there is no need for that.

One of your points is about DNS64 synthetizing AAAA when they already exist. Clearly this is a matter of correctly configuring the DNS64, should not happen.

Regards,

Jordi

De: Xing Li <[email-masked]>
Fecha: jueves, 8 de noviembre de 2018, 10:23
Para: JORDI PALET MARTINEZ <[email-masked]>
CC: Lorenzo Colitti <[email-masked]>, IETF IPv6 Mailing List <[email-masked]>, congxiao <[email-masked]>, Xing Li <[email-masked]>
Asunto: Re: Non-/96 pref64 use cases

Hi, JORDI, 

                           Figure 1: Scenario 1 

1. RFC7050 case:

1.1 Stateful translation with RFC7050 (/96) and SLAAC for the client (current service in CERNET for Andriod and iOS)

IPv6 pref2=2001:da8:1234::/96 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the IPv4 Internet is 5.6.7.8)
Use RFC7050 to find pref64 = 2001:da8:1234::/96

1.2 Stateless translation with RFC7050 (/96 only) and DHCPv6 stateful for the client (current service in CERNET for iOS)

IPv6 pref1=2001:da8:beef::/48 (prefix for the source)
IPv6 pref2=2001:da8:1234::/96 (prefix for the destination, i.e. pref64)
IPv4-translatable address = 2001:da8:beef:0102:0304::PSID (1.2.3.4 is the public IPv4 address)
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the IPv4 Internet is 5.6.7.8)
Use RFC7050 to find pref64 = 2001:da8:1234::/96
This requires hairpin.

1.3 Stateless translation with RFC7050 (when non-/96 works) and DHCPv6 stateful for the client current service in CERNET for iOS, but cannot support IPv4 literal embedded in the application)

IPv6 pref=2001:da8:beef::/48 (same prefix for the source and the destination)
IPv4-translatable address = 2001:da8:beef:0102:0304::PSID (1.2.3.4 is the public IPv4 address)
IPv4-converted address = 2001:da8:beef:0506:0708:: (IPv4 server in the IPv4 Internet is 5.6.7.8)
We want to use RFC7050 to find non-/96 pref64 = 2001:da8:beef::/48
This supports optimal routing based on maximum prefix length match.

2.1 Stateful translation with draft-pref64folks-6man-ra-pref64 (/96) and SLAAC for the client

IPv6 pref2=2001:da8:1234::/96 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the IPv4 Internet 5.6.7.8)
We can use draft-pref64folks-6man-ra-pref64 to find pref64 = 2001:da8:1234::/96

Now consider the case I gave in the previous mail, that is the case an IPv6 network both have IPv6-only clients (SLAAC) and IPv6-only servers (with IPv4 public address sharing)

The major reason that CERNET needs non-/96 prefix length now is that we lack the public IPv4 addresses, so we use suffix defined in RFC6052 to embed PSID (see Figure) for sharing the public IPv4 addresses among IPv6 servers.. In this case, non-/96 prefix length is required.
......
Note that in the case of IPv6-to-IPv6 communication, it will not go to the translator. However, if for some reason the DNS64 uses A record to generate the AAAA record, then we want the pref64 be the same as the real IPv6 address and therefore double translation can be avoided.

2.1 Stateful translation with draft-pref64folks-6man-ra-pref64 (when non-/96 works) and SLAAC for the client

IPv6 pref=2001:da8:beef::/48 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address1 = 2001:da8:beef:0506:0708:: (IPv4 server in the IPv4 Internet 5.6.7.8)
IPv4-converted address2 = 2001:da8:beef:090a:0b0c:: (IPv4 server in an IPv6 network 9.10.11.12)
We want to use draft-pref64folks-6man-ra-pref64 to find non-/96 pref64 = 2001:da8:beef::/48

JORDI PALET MARTINEZ 写道: 

Hi Xing,

Unless I got it wrong:

See 1.2  and 1.3 above

Agree.

For the client, yes. But if we consider an IPv6 network which consists both clients and servers, then there is a use case.

It uses RFC7599's address format, but it is a single IPv4/IPv6 translation,therefor RFC7050 is needed.

See above examples.

In summary, since /96 is a special case of variable prefix length, why not define non-/96 in draft-pref64folks-6man-ra-pref64 at this stage (even with a little bit more overhead). This will save a lot of energy for both the standard work and more important, the upgrading work for supporting different OSs.

Thanks,

xing

Regards,

Jordi

Lorenzo Colitti 写道: 

Xing,

                   |          128-n-o-s bits          |

Regards,

xing

Cheers,

Lorenzo

The CERNET use case is:

 
                                 Figure 1
suffix=PSID

Regards,

xing 

Lorenzo Colitti 写 道: 

RFC 6052 defines non-/96 prefixes.

For historical reasons related to hardware support, the Cernet network uses non-/96 prefixes.

>From a standards perspective, those reasons are no longer relevant today due to BCP 198.

Current NAT64 detection techniques (e.g., RFC 7050) allow detecting non-/96 prefixes. However, Xing's testing indicates that current host implementations do not support this and only support /96.

If we think the reasons for non-/96 prefixes are no longer relevant today, then it's not likely we'll see new networks use them in the future.

Therefore, it's likely that existing implementations, which today support RFC7050 but not non-/96, are not likely to support non-/96 prefixes with this new option, even if we allow them.

If implementations aren't going to implement this, then there seems little point allowing them in this new option.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Nov 2018 15:24:26 +0700

I'm still confused, sorry. If we compare the two of the scenarios, with and
without non-/96 support, then we get:

=======

IPv6 pref2=2001:da8:1234::/96 (pref for the destination, i.e. pref64)
The client has SLAAC IPv6 address
IPv4-converted address = 2001:da8:1234::0506:0708 (IPv4 server in the IPv4
Internet 5.6.7.8)
We can use draft-pref64folks-6man-ra-pref64 to find pref64 =
2001:da8:1234::/96

IPv4-converted address2 = 2001:da8:beef:090a:0b0c:: (IPv4 server in an IPv6
network 9.10.11.12)
=======

How does the non-/96 prefix help in this case?
Presumably the network will need to support both of these scenarios, in
order to deal with clients that support non-/96 prefixes and clients that
don't. How does this work?
If the server is on an IPv6-only network and the client is on an IPv6-only
network, then why can't the client use IPv6 to talk to the server directly?

On Thu, Nov 8, 2018 at 1:13 PM JORDI PALET MARTINEZ <
[email-masked]> wrote:

> Hi Xing,
>
>
>
> I think I understand now better your case, but still my point is that
> RFC7050 was only meant for stateful NAT64 prefix discovery and you want to
> use it for stateless (or use draft-pref64folks-6man-ra-pref64, which is
> also -now- meant as a better choice than RFC7050). Is a matter of what we
> have defined “today” not that I disagree to change that.
>
>
>
> You’re assuming that clients and servers need to use the “same” protocol
> for both, internal CERNET communication and communication to outside
> Internet, which I think it makes it more complex.
>
>
>
> You can just keep in the client LANs a regular CLAT function, while the
> servers use the mechanisms that you are already using, and ad the same time
> solve the literal problems, etc. for clients.
>
>
>
> Communication inside CERNET network will be IPv6, clients will have full
> support of IPv4-Internet by means of the CLAT (regardless of using SLAAC or
> DHCPv6), and servers will keep using your actual setup. In the worst case,
> may be is not needed, servers need to have different addresses (may be in
> different interfaces, or by means of load balances, or firewall rules,
> etc.), depending on if the communication is inside CERNET or to/from
> Internet.
>
>
>
> I don’t disagree either that draft-pref64folks-6man-ra-pref64 could
> support both choices, but may be if your scenario is the only case, and is
> sorted out as I suggested, there is no need for that.
>
>
>
> One of your points is about DNS64 synthetizing AAAA when they already
> exist. Clearly this is a matter of correctly configuring the DNS64, should
> not happen.
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *Xing Li <[email-masked]>
> *Fecha: *jueves, 8 de noviembre de 2018, 10:23
> *Para: *JORDI PALET MARTINEZ <[email-masked]>
> *CC: *Lorenzo Colitti <[email-masked]>, IETF IPv6 Mailing List <
> [email-masked]>, congxiao <[email-masked]>, Xing Li <
> [email-masked]>
> 1.2 Stateless translation with RFC7050 (/96 only) and DHCPv6 stateful for
> the client (current service in CERNET for iOS)
>
> The major reason that CERNET needs non-/96 prefix length now is that we
> lack the public IPv4 addresses, so we use suffix defined in RFC6052 to
> So, it looks like draft-pref64folks-6man-ra-pref64 should not be used, as
> well as RFC7050, because the provisioning of the prefixes in your case, is
> done by means of DHCPv6 (RFC7598).
>
>
>
> clarification about all this to better understand the need and if may be
> RFC7050 should be modified to support stateless NAT64, etc.
>
>
> See above examples.
>
> In summary, since /96 is a special case of variable prefix length, why not
> define non-/96 in draft-pref64folks-6man-ra-pref64 at this stage (even with
> a little bit more overhead). This will save a lot of energy for both the
> standard work and more important, the upgrading work for supporting
> different OSs.
>
> Thanks,
>
> xing
>
>
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *ipv6 <[email-masked]> <[email-masked]> en nombre de
> Xing Li <[email-masked]> <[email-masked]>
> *Para: *Lorenzo Colitti <[email-masked]> <[email-masked]>
> *CC: *Xing Li <[email-masked]> <[email-masked]>, IETF IPv6
> Mailing List <[email-masked]> <[email-masked]>, congxiao
> <[email-masked]> <[email-masked]>
> Current NAT64 detection techniques (e.g., RFC 7050) allow detecting
> If we think the reasons for non-/96 prefixes are no longer relevant today,
> then it's not likely we'll see new networks use them in the future.
>
> Therefore, it's likely that existing implementations, which today support
> RFC7050 but not non-/96, are not likely to support non-/96 prefixes with
> this new option, even if we allow them.
>
> -------------------------------------------------------------------- IETF
> IPv6 working group mailing list [email-masked] Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>

---

From: <[email-masked]>
Date: Thu, 8 Nov 2018 14:17:26 +0000

Hi all, 

There are many reasons for which we went for a flexible approach in 6052:

* Which prefix (and length) is a deployment taste. This is a still valid requirement. 
* Leave the room open for simplified NAT64 operations but allowing for the suffix part to have a checksum neutral prefix. This is a still valid requirement.
* Allow for ports to be included in the suffix part. We had A+P in mind at that time. This is endorsed in RFC7599.

Cheers,
Med

> -----Message d'origine-----
> De : ipv6 [mailto:[email-masked]] De la part de Jen Linkova
> Envoyé : mercredi 7 novembre 2018 04:32
> À : 6man; [email-masked]
> Objet : Non-/96 pref64 use cases
> 
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Xing Li <[email-masked]>
Date: Sun, 11 Nov 2018 11:15:55 +0800

Hi, Lorenzo,

Lorenzo Colitti 写道:
> I'm still confused, sorry. If we compare the two of the scenarios, 
> with and without non-/96 support, then we get:
>
> =======
> Presumably the network will need to support both of these scenarios, 
> in order to deal with clients that support non-/96 prefixes and 
> clients that don't. How does this work?
> If the server is on an IPv6-only network and the client is on an 
> IPv6-only network, then why can't the client use IPv6 to talk to the 
> server directly?
Sorry, my previous example is not very clear. let me try again
Assume CERNET server IPv4 = 9.10.11.12, with address sharing (PSID) and 
pref64 = 2001:da8:beef::/48, therefore the IPv4-translatable address for 
the CERNET server is 2001:da8:beef:090a:0b0c::PSID

In the case of non-/96, WKP=2001:da8:beef::/48
(1) via AAAA or given IPv6 literal directly
    2001:da8::1 (CERNET client) --> 2001:da8:beef:090a:0b0c::PSID 
(CERNET server)
(2) via DNS64 synthetizing AAAA or WKP
    2001:da8::1 (CERNET client) --> 2001:da8:beef:090a:0b0c:: , the 
packets will be routed to a translator for the IPv4 address sharing,
    2001:da8::1 (CERNET client) --> 2001:da8:beef:090a:0b0c::PSID 
(CERNET server)
i.e. in the case of via DNS64 synthetizing AAAA or WKP, it only requires 
one translation process (address sharing)

In the case of /96, WKP=2001:da8:1234::/96
(1) via AAAA or given IPv6 literal directly
    2001:da8::1 (CERNET client) --> 2001:da8:beef:090a:0b0c::PSID 
(CERNET server)
(2) via DNS64 synthetizing AAAA or WKP
    2001:da8::1 (CERNET client) --> 2001:da8:1234::090a:0b0c:: the 
packets will be routed to a translator for nat64,
    1.2.3.4 (IPv4 address pool) --> 9.10.11.12
    then via another translator (stateless nat64 with IPv4 address sharing)
    2001:da8:beef:0102:0304:: --> 2001:da8:1234::090a:0b0c::PSID
i.e. in the case of via DNS64 synthetizing AAAA or WKP, it requires two 
translation processes.

Best regards,

xing

>
> On Thu, Nov 8, 2018 at 1:13 PM JORDI PALET MARTINEZ 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Xing,
>
>      
>
>     I think I understand now better your case, but still my point is
>     that RFC7050 was only meant for stateful NAT64 prefix discovery
>     and you want to use it for stateless (or use
>     draft-pref64folks-6man-ra-pref64, which is also -now- meant as a
>     better choice than RFC7050). Is a matter of what we have defined
>     “today” not that I disagree to change that.
>
>      
>
>     You’re assuming that clients and servers need to use the “same”
>     protocol for both, internal CERNET communication and communication
>     to outside Internet, which I think it makes it more complex.
>
>      
>
>     You can just keep in the client LANs a regular CLAT function,
>     while the servers use the mechanisms that you are already using,
>     and ad the same time solve the literal problems, etc. for clients.
>
>      
>
>     Communication inside CERNET network will be IPv6, clients will
>     have full support of IPv4-Internet by means of the CLAT
>     (regardless of using SLAAC or DHCPv6), and servers will keep using
>     your actual setup. In the worst case, may be is not needed,
>     servers need to have different addresses (may be in different
>     interfaces, or by means of load balances, or firewall rules,
>     etc.), depending on if the communication is inside CERNET or
>     to/from Internet.
>
>      
>
>     I don’t disagree either that draft-pref64folks-6man-ra-pref64
>     could support both choices, but may be if your scenario is the
>     only case, and is sorted out as I suggested, there is no need for
>     that.
>
>      
>
>     One of your points is about DNS64 synthetizing AAAA when they
>     already exist. Clearly this is a matter of correctly configuring
>     the DNS64, should not happen.
>
>
>     Regards,
>
>     Jordi
>
>      
>
>      
>
>      
>
>     *De: *Xing Li <[email-masked] <mailto:[email-masked]>>
>     *Para: *JORDI PALET MARTINEZ <[email-masked]
>     <mailto:[email-masked]>>
>     *CC: *Lorenzo Colitti <[email-masked]
>     <mailto:[email-masked]>>, IETF IPv6 Mailing List
>     <[email-masked] <mailto:[email-masked]>>, congxiao
>     <[email-masked] <mailto:[email-masked]>>, Xing Li
>     <[email-masked] <mailto:[email-masked]>>
>     1.1 Stateful translation with RFC7050 (/96) and SLAAC for the
>     client (current service in CERNET for Andriod and iOS)
>
>     1.2 Stateless translation with RFC7050 (/96 only) and DHCPv6
>     stateful for the client (current service in CERNET for iOS)
>
>     1.3 Stateless translation with RFC7050 (when non-/96 works) and
>     DHCPv6 stateful for the client current service in CERNET for iOS,
>     but cannot support IPv4 literal embedded in the application)
>
>     Now consider the case I gave in the previous mail, that is the
>     case an IPv6 network both have IPv6-only clients (SLAAC) and
>     IPv6-only servers (with IPv4 public address sharing)
>
>
>         The major reason that CERNET needs non-/96 prefix length now
>         is that we lack the public IPv4 addresses, so we use suffix
>         defined in RFC6052 to embed PSID (see Figure) for sharing the
>         public IPv4 addresses among IPv6 servers.. In this case,
>         non-/96 prefix length is required.
>         ......
>     2.1 Stateful translation with draft-pref64folks-6man-ra-pref64
>     (when non-/96 works) and SLAAC for the client
>
>         - RFC7050 is meant for stateful NAT64 (RFC6146), but you’re
>         using stateless translation, so should not be using this.
>
>
>     See 1.2  and 1.3 above
>
>     For the client, yes. But if we consider an IPv6 network which
>     consists both clients and servers, then there is a use case.
>
>          
>
>         And the use case that you’re documenting seems to be MAP-T
>         (RFC7599), which uses RFC6052, but not RFC7050.
>
>         So, it looks like draft-pref64folks-6man-ra-pref64 should not
>         be used, as well as RFC7050, because the provisioning of the
>         prefixes in your case, is done by means of DHCPv6 (RFC7598).
>
>          
>
>         If in your case, you use RFC7050, may be is working, but is
>         not a “defined” case. Not saying is wrong, but I think we need
>         further clarification about all this to better understand the
>         need and if may be RFC7050 should be modified to support
>         stateless NAT64, etc.
>
>
>     See above examples.
>
>     In summary, since /96 is a special case of variable prefix length,
>     why not define non-/96 in draft-pref64folks-6man-ra-pref64 at this
>     stage (even with a little bit more overhead). This will save a lot
>     of energy for both the standard work and more important, the
>     upgrading work for supporting different OSs.
>
>     Thanks,
>
>     xing
>
>
>
>
>         Regards,
>
>         Jordi
>
>          
>
>          
>
>          
>
>         *De: *ipv6 <[email-masked]>
>         <mailto:[email-masked]> en nombre de Xing Li
>         <[email-masked]> <mailto:[email-masked]>
>         <mailto:[email-masked]>
>         *CC: *Xing Li <[email-masked]>
>         <mailto:[email-masked]>, IETF IPv6 Mailing List
>         <[email-masked]> <mailto:[email-masked]>, congxiao
>         <[email-masked]> <mailto:[email-masked]>
>             On Wed, Nov 7, 2018 at 5:18 PM Lorenzo Colitti
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>                 Xing,
>
>                  
>
>                 can you explain how the device would use the prefix
>                 that it has learned? How the bits in the suffix are
>                 used, etc.?
>
>
>                 On Wed, Nov 7, 2018 at 4:58 PM Xing Li
>                 <[email-masked] <mailto:[email-masked]>> wrote:
>
>                     (1) We have been using RFC6052 non-/96 prefix
>                     length in most of the cases, because of the
>                     historical reasons (some old routers are still be
>                     used).
>
>                     (2) We are happy that RFC7050 supports non-/96
>                     prefix length in the standard. We hope that the
>                     new versions of Andriod, iOS (and Win10) can
>                     implement non-/96 prefix length, since that will
>                     give ISP more operation freedom.
>
>                     (3) The major reason that CERNET needs non-/96
>                     prefix length now is that we lack the public IPv4
>                     addresses, so we use suffix defined in RFC6052 to
>                     embed PSID (see Figure) for sharing the public
>                     IPv4 addresses among IPv6 servers.. In this case,
>                     non-/96 prefix length is required.
>
>                     Note that in the case of IPv6-to-IPv6
>                     communication, it will not go to the translator.
>                     However, if for some reason the DNS64 uses A
>                     record to generate the AAAA record, then we want
>                     the pref64 be the same as the real IPv6 address
>                     For the stateless translation, DNS64 is not
>                     required for the IPv6-only servers, but DNS64 is
>                     required for the clients to access the global IPv4
>                     Internet.
>
>                     In summary, we would like this RA pref64 extension
>                     to be compatible with RFC7050 and allow non/96
>                     prefix length. Thank you verymuch!
>
>                     Regards,
>
>                     xing
>
>
>
>                     Lorenzo Colitti 写道:
>
>                             > Ok. Then I suppose better questions
>                             would be: why does this work with non-/96
>                             prefixes? Doesn't any prefix length have
>                             the problem that the host doesn't need to
>                             I think for most cases there are a small
>                             number of translators in the network;
>                             certainly, anyone that thinks a
>                             well-known-prefix is a good idea isn't
>                             normally dealing with more than one or
>                             two. I would make the same comment about
>                             /96 prefixes. How often have we argued
>                             about the length of an IID? We had to
>                             issue at RFC to tell a certain chip vendor
>                             that a routing prefix longer than 64 bits
>                             was a reality. Now we're suggesting that
>                             the routing prefix in CERNET might be 96+n
>                             bits in length - the IPv6 prefix and part
>                             of the IPv4 address.
>
>                          
>
>                         designed to process prefixes of any length up
>                         to /128". BCP 198.
>
>                          
>
>                             Remember that CERNET started the IPv6-only
>                             path in 2008, not 2018. Building stuff
>                             with today's hardware might be possible;
>                             I'm pretty sure it wasn't ten years ago.
>                             You first asked why CERNET did what they
>                             did; I think you understand that now.
>                             Could they renumber their network to do it
>                             your favorite way? Hmmm, maybe. Who's
>                             compatible with previous deployments?
>                             Removing a capability that is not used,
>                             and I think there are several in 6052,
>                             probably makes sense. If there is a
>                             capability that is in use, I'd like to
>                             argue in favor of backward compatibility.
>
>                          
>
>                         For historical reasons related to hardware
>                         From a standards perspective, those reasons
>                         Current NAT64 detection techniques (e.g., RFC
>                         7050) allow detecting non-/96 prefixes.
>                         However, Xing's testing indicates that current
>                         defining this new way of doing NAT64
>                         detection, should we support non-/96 prefixes?
>
>                          
>
>                         If we think the reasons for non-/96 prefixes
>                         are no longer relevant today, then it's not
>                         likely we'll see new networks use them in the
>                         future.
>
>                         Therefore, it's likely that existing
>                         implementations, which today support RFC7050
>                         but not non-/96, are not likely to support
>                         If implementations aren't going to implement
>                         this, then there seems little point allowing
>                         them in this new option.
>
>         IETF IPv6 working group mailing list [email-masked]
>         <mailto:[email-masked]> Administrative Requests:
>         This electronic message contains information which may be
>         privileged or confidential. The information is intended to be
>         for the exclusive use of the individual(s) named above and
>         further non-explicilty authorized disclosure, copying,
>         distribution or use of the contents of this information, even
>         if partially, including attached files, is strictly prohibited
>         and will be considered a criminal offense. If you are not the
>         intended recipient be aware that any disclosure, copying,
>         distribution or use of the contents of this information, even
>         if partially, including attached files, is strictly
>         prohibited, will be considered a criminal offense, so you must
>         reply to the original sender to inform about this
>     This electronic message contains information which may be
>     privileged or confidential. The information is intended to be for
>     the exclusive use of the individual(s) named above and further
>     non-explicilty authorized disclosure, copying, distribution or use
>     of the contents of this information, even if partially, including
>     attached files, is strictly prohibited and will be considered a
>     criminal offense. If you are not the intended recipient be aware
>     that any disclosure, copying, distribution or use of the contents
>     of this information, even if partially, including attached files,
>     is strictly prohibited, will be considered a criminal offense, so
>     you must reply to the original sender to inform about this

---

From: Xing Li <[email-masked]>
Date: Sun, 11 Nov 2018 11:17:44 +0800

Hi, Jordi,

JORDI PALET MARTINEZ 写道:
> RFC7050 was only meant for stateful NAT64 prefix discovery and you 
> want to use it for stateless (or use draft-pref64folks-6man-ra-pref64, 
> which is also -now- meant as a better choice than RFC7050). Is a 
> matter of what we have defined “today” not that I disagree to change that.
>
My understanding is that:
(1) RFC7050 can both used for stateful and stateless, even it is 
originally designed for stateful. BTW, CERNET has been using RFC7050 for 
stateless with /96, it works for iOS. (The problem is non-optimal 
routing for stateless when only /96 is supported by the current OSs).
(2) We hope draft-pref64folks-6man-ra-pref64 can also support non-/96 
(sync with RFC7050), even it is designed for stateful.
> protocol for both, internal CERNET communication and communication to 
> outside Internet, which I think it makes it more complex.
>
>  
>
> You can just keep in the client LANs a regular CLAT function, while 
> the servers use the mechanisms that you are already using, and ad the 
> same time solve the literal problems, etc. for clients.
>

That is our current practice, in the case of communication via IPv6, 
there is no problem.
>
>  
>
> Communication inside CERNET network will be IPv6, clients will have 
> full support of IPv4-Internet by means of the CLAT (regardless of 
> using SLAAC or DHCPv6), and servers will keep using your actual setup. 
> In the worst case, may be is not needed, servers need to have 
> different addresses (may be in different interfaces, or by means of 
> load balances, or firewall rules, etc.), depending on if the 
> communication is inside CERNET or to/from Internet.
>
If in the case of via IPv4, it will be through two translators. See the 
mail reply to Lorenzo.

> support both choices, but may be if your scenario is the only case, 
> and is sorted out as I suggested, there is no need for that.
>
Let's see if there are other cases.
> exist. Clearly this is a matter of correctly configuring the DNS64, 
> should not happen.
>
The beauty of the Internet is that it can work in the nonperfect case 
(-: and the IETF standards are somehow designed for the nonperfect cases.

Best regards,

xing

> *CC: *Lorenzo Colitti <[email-masked]>, IETF IPv6 Mailing List 
> <[email-masked]>, congxiao <[email-masked]>, Xing Li 
> <[email-masked]>
>     The major reason that CERNET needs non-/96 prefix length now is
>     that we lack the public IPv4 addresses, so we use suffix defined
>     in RFC6052 to embed PSID (see Figure) for sharing the public IPv4
>     addresses among IPv6 servers.. In this case, non-/96 prefix length
>     is required.
>     ......
>     Note that in the case of IPv6-to-IPv6 communication, it will not
>     go to the translator. However, if for some reason the DNS64 uses A
>     record to generate the AAAA record, then we want the pref64 be the
>     same as the real IPv6 address and therefore double translation can
>     be avoided.
>
>     So, it looks like draft-pref64folks-6man-ra-pref64 should not be
>     used, as well as RFC7050, because the provisioning of the prefixes
>     in your case, is done by means of DHCPv6 (RFC7598).
>
>      
>
>     clarification about all this to better understand the need and if
>     may be RFC7050 should be modified to support stateless NAT64, etc.
>
>
> See above examples.
>
>     *De: *ipv6 <[email-masked]> <mailto:[email-masked]>
>     en nombre de Xing Li <[email-masked]> <mailto:[email-masked]>
>     *CC: *Xing Li <[email-masked]> <mailto:[email-masked]>,
>     IETF IPv6 Mailing List <[email-masked]> <mailto:[email-masked]>,
>     congxiao <[email-masked]> <mailto:[email-masked]>
>             can you explain how the device would use the prefix that
>             it has learned? How the bits in the suffix are used, etc.?
>
>
>                 (1) We have been using RFC6052 non-/96 prefix length
>                 in most of the cases, because of the historical
>                 reasons (some old routers are still be used).
>
>                 length in the standard. We hope that the new versions
>                 of Andriod, iOS (and Win10) can implement non-/96
>                 prefix length, since that will give ISP more operation
>                 freedom.
>
>                 length now is that we lack the public IPv4 addresses,
>                 so we use suffix defined in RFC6052 to embed PSID (see
>                 Figure) for sharing the public IPv4 addresses among
>                 Note that in the case of IPv6-to-IPv6 communication,
>                 it will not go to the translator. However, if for some
>                 reason the DNS64 uses A record to generate the AAAA
>                 record, then we want the pref64 be the same as the
>                 For the stateless translation, DNS64 is not required
>                 for the IPv6-only servers, but DNS64 is required for
>                 the clients to access the global IPv4 Internet.
>
>                 In summary, we would like this RA pref64 extension to
>                 be compatible with RFC7050 and allow non/96 prefix
>                 length. Thank you verymuch!
>
>                 Regards,
>
>                 xing
>
>
>
>                 Lorenzo Colitti 写道:
>
>                         > Ok. Then I suppose better questions would
>                         be: why does this work with non-/96 prefixes?
>                         Doesn't any prefix length have the problem
>                         that the host doesn't need to know what
>                         translator to send the packet to?
>
>                         would make the same comment about /96
>                         prefixes. How often have we argued about the
>                         length of an IID? We had to issue at RFC to
>                         tell a certain chip vendor that a routing
>                         prefix longer than 64 bits was a reality. Now
>                         we're suggesting that the routing prefix in
>                         CERNET might be 96+n bits in length - the IPv6
>                         path in 2008, not 2018. Building stuff with
>                         today's hardware might be possible; I'm pretty
>                         sure it wasn't ten years ago. You first asked
>                         why CERNET did what they did; I think you
>                         understand that now. Could they renumber their
>                         network to do it your favorite way? Hmmm,
>                         maybe. Who's paying? Is there intent for the
>                         specifications to remain backward compatible
>                         with previous deployments? Removing a
>                         capability that is not used, and I think there
>                         are several in 6052, probably makes sense. If
>                         there is a capability that is in use, I'd like
>                         to argue in favor of backward compatibility.
>
>                      
>
>                     defining this new way of doing NAT64 detection,
>                     should we support non-/96 prefixes?
>
>                      
>
>                     If we think the reasons for non-/96 prefixes are
>                     no longer relevant today, then it's not likely
>                     implementations, which today support RFC7050 but
>                     not non-/96, are not likely to support non-/96
>                     If implementations aren't going to implement this,
>                     then there seems little point allowing them in
>                     this new option.
>