Subject: [v6ops] IANA assigned prefix for IPv6 benchmarking

From: "GEORGESCU LIVIU MARIUS" <[email-masked]>
Date: Fri, 24 Jul 2015 11:16:56 +0200

Hello v6ops,

Related to the question that came up in Stuart Cheshire's presentation about the prefix used for benchmarking, RFC5180(with errata) "IPv6 Benchmarking Methodology for Network Interconnect Devices" (which might not apply here) states: "The IANA has assigned 2001:0002::/48 for IPv6 benchmarking, which is a 48-bit prefix from the RFC 4773 pool." 
I hope this helps.

Best regards,
Marius

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 24 Jul 2015 21:21:10 +0200

Le 24/07/2015 11:16, GEORGESCU LIVIU MARIUS a écrit :
> Hello v6ops,
>
> Related  to the question that came up in Stuart Cheshire's presentation
> about the prefix used for benchmarking, RFC5180(with errata) "IPv6
> Benchmarking Methodology for Network Interconnect Devices" (which might
> not apply here) states: "The IANA has assigned 2001:0002::/48 for IPv6
> benchmarking, which is a 48-bit prefix from the RFC 4773 pool."
> I hope this helps.

To me, this is an additional reason to think that it is good to use ULAs 
(not 2001:s or Teredos) behind any form of NATxy.

But I heard there may be good reasons to avoid ULA in NAT64.  Not sure 
which.

Alex

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

---

From: "GEORGESCU LIVIU MARIUS" <[email-masked]>
Date: Sat, 25 Jul 2015 12:37:15 +0200

If respecting the recommendations of RFC5180 is desired I think the following note in RFC5180 is relevant:

" Note: Similar to RFC 2544(https://tools.ietf.org/html/rfc2544) avoiding the use of RFC 1918(https://tools.ietf.org/html/rfc1918) address space

 for benchmarking tests, this document does not recommend the use of RFC 4193(https://tools.ietf.org/html/rfc4193) [4(https://tools.ietf.org/html/rfc5180#ref-4)] (Unique Local Addresses) in order to minimize the 

 possibility of conflicts with operational traffic."

which in my understanding does not recommend the use of ULA s.

Best regards,
Marius 

On 07/24/15, Alexandru Petrescu  <[email-masked]> wrote:
> To me, this is an additional reason to think that it is good to use ULAs (not 2001:s or Teredos) behind any form of NATxy.
> 
> But I heard there may be good reasons to avoid ULA in NAT64. Not sure which.
> 
> Alex
> 
> >
> >Best regards,
> >Marius
> >
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jul 2015 18:53:54 +1200

> which in my understanding does not recommend the use of ULA s.

No, but it's a strange argument precisely because ULAs are Unique with very high
probability, so conflict with operational traffic is very improbable.

    Brian

---

From: Erik Kline <[email-masked]>
Date: Sun, 26 Jul 2015 18:22:34 +0200

> probability, so conflict with operational traffic is very improbable.

Regardless of ULA or some other space, I think a useful property for
the GUA(-like) prefix used by Apple's NAT64 test network would be
randomness.

If, for instance, *every time a NAT64 test network was started* a new
random ULA was generated or, say, 2001:2:0:$RAND16::/64 were used,
then developers would be less likely to accidentally make assumptions
about the consistency of addresses.

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Jul 2015 20:20:33 +0200

On Jul 26, 2015, at 18:22, Erik Kline <[email-masked]> wrote:
> […]

I think it would be better not to use a single constant network prefix for the purpose Stuart described. The reason is that Stable and Opaque IIDs with SLAAC [RFC 7217] will never change on such networks. For the testing purpose Apple has in mind, I think it would be better to use a /48 prefix with a subnet that can be chosen as a configuration option in the Sharing preferences.

—james

---

From: Tore Anderson <[email-masked]>
Date: Mon, 27 Jul 2015 20:58:59 +0200

* Erik Kline

> about the consistency of addresses.

Same thing goes for NAT64/DNS64 translation prefix. This could be
tempting for developers to hard-code as well - my gut feeling tells me
that most NAT64 deployments in 3GPP networks out are using the WKP from
RFC6052 (64:ff9b::/96) for their translation prefix.

As I also mentioned in the WG session I think that Apple should simply
obtain a GUA prefix through the registry system for this purpose (never
to be advertised into the DFZ). That way they wouldn't have to squat on
prefixes reserved for other purposes (like 2001:2::/48), and they would
be able to document what the prefix is actually used for and link to
further information in the prefix' whois entry, so people who
accidentally find themselves connected to such a network has a chance
to figure out what's going on.

The cost would be negligible - a /48 PI costs only €50/year here.

Tore

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 31 Jul 2015 17:19:36 +0000

> On Jul 24, 2015, at 12:21 PM, Alexandru Petrescu <[email-masked]> wrote:
> 

</chair>, speaking as someone who communicates on the list.

I find the entire fixation on ULAs and GUAs bizarre. A ULA is a global scope prefix that is not advertised in routing (which one might describe as site-scope, except that we wouldn't want to confuse it with site-local). If someone has a use for a prefix that they don't plan to advertise in routing, that seems to be the poster child use case. If someone plans to speak globally using a given prefix, it should be a global prefix that *is* advertised in routing.

What's with the angst? Is it that someone sees "ULA" and thinks "NAT"? Yes, that would be one use case; if you don't like that use case, we have a library full of RFCs that say why one might not recommend it (RFCs 2993, 4864, and others). We also have other use cases.

Do we REALLY need to wrings our hands one more time?