Subject: [homenet] Fwd: Major use cases for ULA

From: Fred Baker <[email-masked]>
Date: Thu, 17 Nov 2011 18:38:52 +0800

FYI:

This is a note I sent to v6ops regarding ULAs, but as there is some discussion of them in Homenet, it make also be of interest here.

Begin forwarded message:

> From: Fred Baker <[email-masked]>
> Date: November 17, 2011 6:37:54 PM GMT+08:00
> To: [email-masked]
> Cc: "[email-masked] WG" <[email-masked]>
> Subject: Major use cases for ULA
> 
> Trying to summarize at least my thoughts from the discussion this afternoon. Working group, tell me what I'm missing in this.
> 
> First, as Jari noted from the mike, there is no case in which a ULA is required. If one is willing to only have connectivity in the link-local environment, one can communicate between two directly connected systems using a link-local address. If one has in the past had the use of a prefix allocated by someone else, but are right now not connected to the Internet, there is no harm in using that prefix even if it is expired. Reason: there will be no confusion. As soon as one reconnects, the expiration of the prefix needs to take effect, however.
> 
> To my mind, there are three valid uses of a ULA. The choice of use cases center on the word "local".
> 
> 1) if one is in a network that does not have service from someone that will allocate it a prefix and wants to either use addresses that are not link-local or addresses that will allow for routing, a ULA provides a way to generate a prefix for the purpose. One example of such an environment is a Smart Grid HAN in a home that doesn't have an ISP. To me, this is a textbook case for the use of a ULA.
> 
> 2) if one is in a network that DOES have service from someone that will allocate it a prefix but wants to use addresses that are not in that prefix and are not routed anywhere else, a ULA can provide such a prefix. There are a number of possible examples. 
> 
> At Cisco, to pick one, we have a number of systems with names like http://wwwin.cisco.com - systems that offer no services outside Cisco but provide some interior service. There are at least two ways to implement that policy. One obvious one would be to put some ACL in the routers/firewalls at the edge of the network that drop traffic to or from those addresses. Another, which I would only want to implement in the presence of that firewall ACL, would be to not advertise the names outside the company in DNS (probably by implementing a split DNS). A third would be to give them ULA addresses, which are not advertised outside the company and are therefore something folks outside can't route to.
> 
> Another example is the one I mentioned in RFC 6296; if you choose to use such a translator, you're going to need an interior prefix. That could be ULA or global. If it is global and you decide to change away from that carrier, you will have to renumber the network. If you find that scary, you might choose a ULA as your internal prefix.
> 
> The key point is not "6296", nor is it "internal-only policy". It's "In my addressing plan, I want to use a *different* prefix that is not routed outside". If you have that policy, one of the options (and not the only option) would be to use a ULA.
> 
> 3) If you have a special routing scenario, of which draft-baker-v6ops-b2b-private-routing is an example, for various reasons you might want to have routing that you control and is separate from other routing. In the b2b case, even though two companies each have at least one ISP, they might choose to ALSO use direct connectivity that only connects stated machines, such as a silicon foundry with client engineers that use it. A ULA provides a simple way to obtain such a prefix that would be used in accordance with an agreement between the parties.
> 
> 
> 
> To my mind, the renumbering scenario is a red herring. Thomas Narten wanted desperately for me to put it into RFC 4192 as "A ULA could help when renumbering a network". However, it doesn't actually do so.
> 
> Case 1) suppose I am now using prefix 2001:dba:1::/48 and want to change to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, whatever) outside of my network. What RFC 4192 suggests is bringing up the two prefixes in parallel (eg, I am now using both 2001:dba:1::/48 and 2001:dba:2:8000::/49 throughout my network), and then take the old one down. The effect: during some part of the procedure, my external services have first one address, then two addresses, and finally one, but the one is the new one. I completely changed my address space, but my service never went down.
> 
> Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, whatever) outside of my network. What the ULA advocates suggest that I have a ULA up in parallel, either all the time or brought up for the purpose. I am in effect now using 2001:dba:1::/48 and the ULA. I now take down 2001:dba:1::/48, and either simultaneously or subsequently bring up 2001:dba:2:8000::/49. If I do the two sequentially, I have an interval in which my services are only reachable via the ULA; if I change them at the same time, the ULA allows me to maintain control of my network (my network management system and other internal uses can use it to access equipment and applications within my network), but the disrupted routing makes my services unavailable in either global prefix for some period of time. The effect: during some part of the procedure, the various systems in my network might have one, two, or three addresses, but during any period in which only the ULA has stable routing, my services are down as far as any external user is concerned.
> 
> Hence, a ULA is helpful for folks within my own network, but does not help keep my externally-facing services running. To my small mind, that makes a ULA a nice fallback in case something gets screwed up, but it is not a renumbering solution. It fails to prevent a service outage during renumbering.

---

From: Anders Brandt <[email-masked]>
Date: Thu, 17 Nov 2011 10:57:04 +0000

May I suggest variant 1b) :

A home control installation with some powerline devices and some wireless devices each part of a lighting control system that MUST ALWAYS work.
Both subnets are installed in autonomous fashion by two different technicians. Later, their border routers are interconnected via the homenet backbone.
We may argue if a ULA prefix is needed in the homenet backbone but both of the home control networks need ULA addresses

A: because the devices need stable addresses so that they know where to send On/Off commands to the other subnet without depending on DNS servers, etc.

B: because there is no infrastructure to coordinate the assignment of prefixes in the two home control subnets

C: because LLNs often do use coordinated assignment of short link-layer addresses to get shorter frames and to improve header compression.
    These short link-layer would often lead to duplicate IPv6 addresses if in the same subnet. 

Thanks,
  Anders Brandt

________________________________________
From: [email-masked] [[email-masked]] on behalf of Fred Baker [[email-masked]]
Sent: Thursday, November 17, 2011 11:37
To: [email-masked]
Cc: [email-masked] WG
Subject: [v6ops] Major use cases for ULA

Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change to 2001:dba:2:8000::/49. Suppose that I am offering a service (web, email, whatever) outside of my network. What the ULA advocates suggest that I have a ULA up in parallel, either all the time or brought up for the purpose. I am in effect now using 2001:dba:1::/48 and the ULA. I now take down 2001:dba:1::/48, and either simultaneously or subsequently bring up 2001:dba:2:8000::/49. If I do the two sequentially, I have an interval in which my services are only reachable via the ULA; if I change them at the same time, the ULA allows me to maintain control of my network (my network management system and other internal uses can use it to access equipment and applications within my network), but the disrupted routing makes my services unavailable in either global prefix for some period of time. The effect: during some part of the procedure, the various systems in my network might have one, two, or three addres
 ses, but during any period in which only the ULA has stable routing, my services are down as far as any external user is concerned.

Hence, a ULA is helpful for folks within my own network, but does not help keep my externally-facing services running. To my small mind, that makes a ULA a nice fallback in case something gets screwed up, but it is not a renumbering solution. It fails to prevent a service outage during renumbering.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Don Sturek <[email-masked]>
Date: Thu, 17 Nov 2011 06:24:37 -0800

Hi Anders,

+1 on what you wrote.  Here is another reason that ULAs are needed:
1)  If globals were used on the sub nets in your example, there would be a
dependence on the ISP serving the prefix that is unwanted for
communication within the home (eg, on/off for lighting within the home).
2)  For technologies like IEEE 802.15.4, link locals will not work in the
multi subnet scenario below.

It would also be nice within Homenet if we could provide an informational
draft providing guidance to the application development community around
using the proper scoped address type (ie, only use globals where you
really need global addressing, use ULAs for applications which are
designed to communicate within the home and use link locals where you are
sure the device you are trying to communicate with is on the same link as
the sender)

Don

On 11/17/11 2:57 AM, "Anders Brandt" <[email-masked]>
wrote:

>A home control installation with some powerline devices and some wireless
>devices each part of a lighting control system that MUST ALWAYS work.
>Both subnets are installed in autonomous fashion by two different
>technicians. Later, their border routers are interconnected via the
>homenet backbone.
>We may argue if a ULA prefix is needed in the homenet backbone but both
>of the home control networks need ULA addresses
>
>A: because the devices need stable addresses so that they know where to
>send On/Off commands to the other subnet without depending on DNS
>servers, etc.
>
>C: because LLNs often do use coordinated assignment of short link-layer
>addresses to get shorter frames and to improve header compression.
>Trying to summarize at least my thoughts from the discussion this
>afternoon. Working group, tell me what I'm missing in this.
>
>First, as Jari noted from the mike, there is no case in which a ULA is
>required. If one is willing to only have connectivity in the link-local
>environment, one can communicate between two directly connected systems
>using a link-local address. If one has in the past had the use of a
>prefix allocated by someone else, but are right now not connected to the
>Internet, there is no harm in using that prefix even if it is expired.
>Reason: there will be no confusion. As soon as one reconnects, the
>expiration of the prefix needs to take effect, however.
>
>1) if one is in a network that does not have service from someone that
>will allocate it a prefix and wants to either use addresses that are not
>link-local or addresses that will allow for routing, a ULA provides a way
>to generate a prefix for the purpose. One example of such an environment
>is a Smart Grid HAN in a home that doesn't have an ISP. To me, this is a
>textbook case for the use of a ULA.
>
>2) if one is in a network that DOES have service from someone that will
>allocate it a prefix but wants to use addresses that are not in that
>prefix and are not routed anywhere else, a ULA can provide such a prefix.
>There are a number of possible examples.
>
>At Cisco, to pick one, we have a number of systems with names like
>http://wwwin.cisco.com - systems that offer no services outside Cisco but
>provide some interior service. There are at least two ways to implement
>that policy. One obvious one would be to put some ACL in the
>routers/firewalls at the edge of the network that drop traffic to or from
>those addresses. Another, which I would only want to implement in the
>presence of that firewall ACL, would be to not advertise the names
>outside the company in DNS (probably by implementing a split DNS). A
>third would be to give them ULA addresses, which are not advertised
>outside the company and are therefore something folks outside can't route
>to.
>
>Another example is the one I mentioned in RFC 6296; if you choose to use
>such a translator, you're going to need an interior prefix. That could be
>ULA or global. If it is global and you decide to change away from that
>carrier, you will have to renumber the network. If you find that scary,
>you might choose a ULA as your internal prefix.
>
>The key point is not "6296", nor is it "internal-only policy". It's "In
>my addressing plan, I want to use a *different* prefix that is not routed
>outside". If you have that policy, one of the options (and not the only
>option) would be to use a ULA.
>
>3) If you have a special routing scenario, of which
>draft-baker-v6ops-b2b-private-routing is an example, for various reasons
>you might want to have routing that you control and is separate from
>other routing. In the b2b case, even though two companies each have at
>least one ISP, they might choose to ALSO use direct connectivity that
>only connects stated machines, such as a silicon foundry with client
>engineers that use it. A ULA provides a simple way to obtain such a
>prefix that would be used in accordance with an agreement between the
>parties.
>
>
>
>To my mind, the renumbering scenario is a red herring. Thomas Narten
>wanted desperately for me to put it into RFC 4192 as "A ULA could help
>when renumbering a network". However, it doesn't actually do so.
>
>Case 1) suppose I am now using prefix 2001:dba:1::/48 and want to change
>to 2001:dba:2:8000::/49. Suppose that I am offering a service (web,
>email, whatever) outside of my network. What RFC 4192 suggests is
>bringing up the two prefixes in parallel (eg, I am now using both
>2001:dba:1::/48 and 2001:dba:2:8000::/49 throughout my network), and then
>take the old one down. The effect: during some part of the procedure, my
>external services have first one address, then two addresses, and finally
>one, but the one is the new one. I completely changed my address space,
>but my service never went down.
>
>Case 2) suppose I am now using prefix 2001:dba:1::/48 and want to change
>to 2001:dba:2:8000::/49. Suppose that I am offering a service (web,
>email, whatever) outside of my network. What the ULA advocates suggest
>that I have a ULA up in parallel, either all the time or brought up for
>the purpose. I am in effect now using 2001:dba:1::/48 and the ULA. I now
>take down 2001:dba:1::/48, and either simultaneously or subsequently
>bring up 2001:dba:2:8000::/49. If I do the two sequentially, I have an
>interval in which my services are only reachable via the ULA; if I change
>them at the same time, the ULA allows me to maintain control of my
>network (my network management system and other internal uses can use it
>to access equipment and applications within my network), but the
>disrupted routing makes my services unavailable in either global prefix
>for some period of time. The effect: during some part of the procedure,
>the various systems in my network might have one, two, or three addres
> ses, but during any period in which only the ULA has stable routing, my
>services are down as far as any external user is concerned.
>
>Hence, a ULA is helpful for folks within my own network, but does not
>help keep my externally-facing services running. To my small mind, that
>makes a ULA a nice fallback in case something gets screwed up, but it is
>not a renumbering solution. It fails to prevent a service outage during
>renumbering.
>homenet mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/homenet