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

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

FYI:

This is a note I sent to v6ops regarding ULAs, but as there is some discussion of them in renum, 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: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Nov 2011 23:55:19 +1300

Fred,

I will talk about this tomorrow in 6renum, but there is one use case
mentioned in draft-carpenter-6renum-static-problem-00 where the only
obvious solution is a ULA: see section 2 "Other Hosts Need Literal Address".

I tend to think you are underestimating the convenience of keeping the
same addresses for the management of network elements during a renumbering
event (especially a renumbering event that goes wrong). I think that the
6renum-static draft should discuss that point too.

Regards
   Brian

On 2011-11-17 23:40, Fred Baker wrote:
>> 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 ad
dr
>  esses, but during any period in which only the ULA has stable routing, my services are down as far as any external user is concerned.
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum
>

---

From: Teco Boot <[email-masked]>
Date: Thu, 17 Nov 2011 15:10:22 +0100

I agree with Brian. I don't like the idea that renum reconfig is preformed with connections that are subject for renum itself. And the impact of PA renum is lower if inner communication is untouched because of ULA.

License data based on ever changing PA addresses doesn't help renum either.

In case of PI addresses, the advantage of ULA is less (or zero).

Teco.

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Nov 2011 22:25:14 +0800

> 6renum-static draft should discuss that point too.

I tend to think that you are forgetting the fundamental premise of RFC 4192, and missing a fairly important bit in the remainder of the note.

In both cases I mentioned, there is a stable prefix in the network at the time the network operator is changing it. And, without changing any description of the cases, one could have 100 ULAs and 100 global prefixes in parallel in the network that were also stable. In the first case, the old prefix is stable while the new is being installed, and the new is stable and proven working before anyone THINKS about changing the old. In the second case, the ULA is stable.

In the first case, the services offered by the network are stable not only within it but outside. That is not true of the second case.

---

From: Teco Boot <[email-masked]>
Date: Thu, 17 Nov 2011 15:40:06 +0100

> In both cases I mentioned, there is a stable prefix in the network at the time the network operator is changing it. And, without changing any description of the cases, one could have 100 ULAs and 1…

OK, this helps. Assume that both management node and reconfigured node
have addresses from all 200 prefixes. Only 0.5% chance that reconfig
session breaks during removal of a prefix. What about a few less
globals on the management node?

Teco

>>> 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 add
>  resses, but during any period in which only the ULA has stable routing, my services are down as far as any external user is concerned.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 11:33:03 +1300

Fred - to be clear, I am a big fan of the 4192 approach. But I don't think
we should assume that Jo Average IT Manager will be fully comfortable with
it; he or she might prefer additional stability in the network management
system.

Regards
   Brian

On 2011-11-18 03:25, Fred Baker wrote:
>>> 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 a
ddresses, but during any period in which only the ULA has stable routing, my services are down as far as any external user is concerned.

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 20 Nov 2011 21:52:46 -0800

> it; he or she might prefer additional stability in the network management

I was not clear when describing management network whether we're
referring to the control plane or a genuinely OOB management network...
One of the properties of the later is that it's generally uncoupled from
the network it's managing, while it could use ula there's no requirement
to do so and if they're genuinely independent then one can be renumbered
without impacting the other.

---

From: "George, Wes" <[email-masked]>
Date: Mon, 21 Nov 2011 08:29:29 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fred Baker

> 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.
>
[WEG] snip
>
> 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.

[WEG] I think that your objection is based on more of a syntax problem (hair-splitting, really) than anything. ULA came up in the context of 6renum as a potential tool in the toolbox.
The thought is that in some cases it could:
1) reduce the number of hosts impacted by an external renumber by numbering internal-only things from ULA
2) keep internal services online during a renumber (as you have discussed)

It's not a solution to renumbering by itself by any means - no magic here. But reducing the number of hosts one has to renumber or reducing the services impacted by a renumber does make renumbering easier/more palatable. Therefore a discussion of how to make renumbering easier is incomplete without it, just as a discussion of reasons why ULA might make sense is incomplete without discussing ways that it might make renumbering easier.

Wes George, at least partially wearing my 6renum hat

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.