Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt - ULA deployment

From: <[email-masked]>
Date: Tue, 11 Mar 2014 09:13:15 +0100

We, Deutsche Telekom, are deploying (from the start of our IPv6 Roll-Out 1,5 years ago) home gateways to our customers, that announce also ULAs on the Home LAN side. Up to know I've not heard of any troubles created by using ULAs and GUAs in parallel, but I'll double-check with our operational units once more. The deployed customer base today is about 1.5 Mio Dual-Stack customers.
AFAI remember the original reason for deploying also ULAs was to make sure that IPv6 connectivity can easily be used between Home LAN systems also in the case when the uplink is not connected and there is no GUA available. LLAs had been considered as insufficient because of the need to add the interface identifier to the address when trying to establish a (link) local IPv6 connection.

Just my 2 cent.
Olaf

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von William Cerveny
Gesendet: Montag, 10. März 2014 20:50
An: [email-masked]
Betreff: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt

Posting onto the list with what I said at the v6ops meeting on Thursday:

I’ve been using a ULA in a test lab for perhaps 6 years.  They work fine and serve our requirement for having a block of addresses that can be routed within the test lab at a single location.  It is possible that at some point we will want to route with a different test lab, for which we wouldn’t want this traffic to leave either test lab. We aren’t routing the traffic outside of the test lab and for our application it is undesirable for our test traffic left the test lab.

I can think of two situations where ULAs would be more valuable in “isolated” networks than GUAs would be:
1) We don’t ever want the traffic addressed with ULAs to leave the test network. If we addressed with a GUA, it would be easier for the traffic to be accidentally routed outside the test lab (I think Fred spelled out this scenario).
2) There may be administratively complex or prohibitive challenges in acquiring GUAs for specific projects. If one were to need addresses (other than link-local addresses) for a small isolated network an assigned GUA is unavailable, it could be desirable to use a ULA instead of random address space.

Bill Cerveny

On Fri, Feb 14, 2014, at 05:13 AM, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
>  This draft is a work item of the IPv6 Operations Working Group of the  
> IETF.
> 
>         Title           : Recommendations of Using Unique Local Addresses
>         Authors         : Bing Liu
>                           Sheng Jiang
> 	Filename        : draft-ietf-v6ops-ula-usage-recommendations-02.txt
> 	Pages           : 15
> 	Date            : 2014-02-14
> 
> Abstract:
>    This document provides guidance of how to use ULAs. It analyzes ULA
>    usage scenarios and recommends use cases where ULA addresses might be
>    beneficially used.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-v6ops-ula-usage-recommenda
> tions/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-recommendations-
> 02
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ula-usage-recommenda
> tions-02
> 
> 
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: "Liubing (Leo)" <[email-masked]>
Date: Tue, 11 Mar 2014 09:13:03 +0000

Hi Olaf & Bill,

Thanks much for sharing the real deployment information which could be a good prove for the relevant use cases in the draft.

Best regards,
Bing

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Tuesday, March 11, 2014 4:13 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-ula-usage-recommendations-02.txt - ULA deployment
> 
> We, Deutsche Telekom, are deploying (from the start of our IPv6 Roll-Out 1,5
> years ago) home gateways to our customers, that announce also ULAs on
> the Home LAN side. Up to know I've not heard of any troubles created by
> using ULAs and GUAs in parallel, but I'll double-check with our operational
> units once more. The deployed customer base today is about 1.5 Mio
> Dual-Stack customers.
> AFAI remember the original reason for deploying also ULAs was to make sure
> that IPv6 connectivity can easily be used between Home LAN systems also in
> the case when the uplink is not connected and there is no GUA available.
> LLAs had been considered as insufficient because of the need to add the
> interface identifier to the address when trying to establish a (link) local IPv6
> connection.
> 
> Just my 2 cent.
> Olaf
> 
> Betreff: Re: [v6ops] I-D Action:
> draft-ietf-v6ops-ula-usage-recommendations-02.txt
> 
> I’ve been using a ULA in a test lab for perhaps 6 years.  They work fine and
> serve our requirement for having a block of addresses that can be routed
> within the test lab at a single location.  It is possible that at some point we
> will want to route with a different test lab, for which we wouldn’t want this
> traffic to leave either test lab. We aren’t routing the traffic outside of the
> test lab and for our application it is undesirable for our test traffic left the
> test lab.
> 
> 1) We don’t ever want the traffic addressed with ULAs to leave the test
> network. If we addressed with a GUA, it would be easier for the traffic to be
> accidentally routed outside the test lab (I think Fred spelled out this
> scenario).
> 2) There may be administratively complex or prohibitive challenges in
> acquiring GUAs for specific projects. If one were to need addresses (other
> than link-local addresses) for a small isolated network an assigned GUA is
> unavailable, it could be desirable to use a ULA instead of random address
> space.
> 
> Bill Cerveny
> 
> > 	Filename        :
> draft-ietf-v6ops-ula-usage-recommendations-02.txt
> > 	Pages           : 15
> > 	Date            : 2014-02-14
> >
> > Abstract:

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Mar 2014 19:40:15 -0700 (PDT)

----- Original Message -----
> From: "[email-masked]" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Sent: Tuesday, 11 March 2014 7:13 PM
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ula-usage-recommendations-02.txt - ULA deployment
> 
> years ago) home gateways to our customers, that announce also ULAs on the Home 
> LAN side. Up to know I've not heard of any troubles created by using ULAs 
> and GUAs in parallel, but I'll double-check with our operational units once 
> more. The deployed customer base today is about 1.5 Mio Dual-Stack customers.
> AFAI remember the original reason for deploying also ULAs was to make sure that 
> IPv6 connectivity can easily be used between Home LAN systems also in the case 
> when the uplink is not connected and there is no GUA available.

That "smells" a bit like you're using Frizbox CPE. Back in 2010 when I was doing some IPv6 residential CPE work, and dealing with these boxes, they really seemed to misunderstand that IPv6 supports multiple concurrent addresses such as ULAs + GUAs. When the GUA went away, e.g., when the WAN link went down,the CPE would try to actively deprecate the GUA and swap it for a ULA. Conversely, when a GUA came back, they would actively try to deprecate the ULA, swapping it for the recently learned GUA (!). The other issue was that they didn't read the ULA spec correctly, and were announcing a ULA with zeros in the random ID portion. RFC6204 hadn't been published at that time, hopefully their IPv6 implementation is much better in this area now.

That being said, I've been running a ULA on my home network in parallel with my GUA that I get from my upstream provider since at least May 5th 2013, and have had no issues (Fedora + Android hosts). One thing I was doing for a while was modifying the Fedora getaddrinfo() preferences to prefer ULAs (via /etc/gai.conf), however I haven't got around to doing that for the last few installs, so even with the older RFC3484 address selection preferences the ULA prefix hasn't caused me any problems.

> LLAs had been 

> considered as insufficient because of the need to add the interface identifier 
> to the address when trying to establish a (link) local IPv6 connection.
> 

This does seem to be an area of misunderstanding in some applications. If getaddrinfo() is used to query for an IPv6 host name that returns a set of IPv6 addresses, if a Link-Local address is returned, then the interface ifIndex that the Link-Local address is reachable on is supposed to be returned in the sin6_scope_id field of the returned sockaddr structure for the Link-Local address. 

For example, if the LL was received via multicast DNS, then the interface where the mDNS answer was received would be the one that should be placed in sin6_scope_id. If an application then uses the LL sockaddr structure to establish a connection, then the sockaddr structure will now hold all the information necessary to successfully use the LL address.

Regards,
Mark.

> serve our requirement for having a block of addresses that can be routed within 
> the test lab at a single location.  It is possible that at some point we will 
> want to route with a different test lab, for which we wouldn’t want this traffic 
> to leave either test lab. We aren’t routing the traffic outside of the test lab 
> and for our application it is undesirable for our test traffic left the test 
> lab.
> 
> 1) We don’t ever want the traffic addressed with ULAs to leave the test network. 
> If we addressed with a GUA, it would be easier for the traffic to be 
> 2) There may be administratively complex or prohibitive challenges in acquiring 
> GUAs for specific projects. If one were to need addresses (other than link-local 
> addresses) for a small isolated network an assigned GUA is unavailable, it could 
> be desirable to use a ULA instead of random address space.
> 
> Bill Cerveny
>