Subject: [v6ops] Major use cases for ULA

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

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: Nathan Ward <[email-masked]>
Date: Thu, 17 Nov 2011 23:59:01 +1300

> 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 provi…

Something similar to both of the above, internal DNS services where you have a dynamic prefix (say an ADSL line) but a routed internal network. An very very common example of an internal DNS service is Active Directory, or anything that does DNS updates after dynamic address assignment to end hosts.

I'm not familiar with the background to this discussion, but it sounds like someone is talking about taking it away, and that would be bad. I've taught a heap of IPv6 courses so have a wide view of weird and wonderful IPv6 deployments, and ULA is very much an important tool.

--
Nathan Ward

---

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: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Nov 2011 00:19:37 +1300

Fred,

> First, as Jari noted from the mike, there is no case in which a ULA is required.

Then how do we assign a prefix for a totally isolated network that includes
at least two subnets?

I realise that no such network will exist for ever without getting connected
to the Internet, but during the time that it does exist in isolation, ULA seems
a better solution than having people make up their own unicast prefix or
applying to ARIN for a PI prefix.

Beyond that I'm getting too sleepy to work through your analysis, but I think
Bing's model of documenting the full range of use cases in a neutral manner
is a good first step. The second step might well be guidelines about which
ones are viable and which ones are harmful.

As Nathan's comment shows, opinions may vary.

Regards
   Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Nov 2011 12:34:31 +0000

On Nov 17, 2011, at 6:38 PM, "Fred Baker" <[email-masked]> wrote:
> 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.

This is all very well and good as long as we believe we can count on detecting when this transition happens.   I would argue that we really can't.   Of course, I suppose in practice the way this would look would be that we would think we were still connected when we weren't, and would therefore expire the prefix, but the point is that the very simple solution you've suggested here really is not something that I would expect to be robust in wide deployment.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Nov 2011 06:37:54 -0600

Note as of circa 2007-2008, in v6ops discussion on the IPv6 CPE router
draft we clearly said the ULA in the home LAN serves as a stable prefix
for the computer at home to print to the printer at home with the SP
global link has gone down.  The ULA has already been specified in RFC
6204.  Thus at least no new document is needed to outline such a use
which has been already carried over to homenet.

The other use case of the ULA was also discussed around the same time as
above to configure the CPE router using a URL.  It was distinctly noted
that some web browsers will not serve a URL with a link-local address.
Then an IPv6 global is needed and the ULA has global scope. Soon as the
CPE router is powered up the ULA can be used to access the device over
the web when the user has not even connected the CPE WAN to the Internet
SP.  

The ULA document in RFC 4193 already specifies properties of the ULA
that make it relatively clear to a reader where the ULA can be used.
Thus why do we need a new document to document what the ULA can be used
for?  

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian E Carpenter
Sent: Thursday, November 17, 2011 7:20 PM
To: Fred Baker (fred)
Cc: [email-masked] WG; [email-masked]
Subject: Re: [v6ops] Major use cases for ULA

Fred,

> First, as Jari noted from the mike, there is no case in which a ULA is
required.

Then how do we assign a prefix for a totally isolated network that
includes
at least two subnets?

I realise that no such network will exist for ever without getting
connected
to the Internet, but during the time that it does exist in isolation,
ULA seems
a better solution than having people make up their own unicast prefix or
applying to ARIN for a PI prefix.

Beyond that I'm getting too sleepy to work through your analysis, but I
think
Bing's model of documenting the full range of use cases in a neutral
manner
is a good first step. The second step might well be guidelines about
which
ones are viable and which ones are harmful.

Regards
   Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 17 Nov 2011 21:53:06 +0800

> Then how do we assign a prefix for a totally isolated network that includes

You could probably completely make something up. Given Jari's assertion that one could use an expired prefix, I suspect he might support that. As long as it remains totally isolated, you're in your own little world.

That said, you'll note that you just described the first case for the use of a ULA. I think even Jari might prefer a ULA to bits pulled out of a dark place.

> ones are viable and which ones are harmful.

The concern I heard in today's discussion fell broadly into two categories. 

Part was the usual technology religion - "We MUST preclude NAT", "We MUST preclude ULA in any case", and "We MUST assume that because OUR network does/needs/experiences <X>, All Networks Are the Same, and we will filibuster at the mike to prevent any other view from being expressed, because 'That's Just Stupid'." Once upon a time, differences in viewpoint were accepted in the IETF as normal, and there was a certain professionalism that grudgingly accepted that the other guy might have a point in a case the speaker had not considered. I'm not sure we're that way any more.

The other concern, one I thought was valid, was that many of the use cases described in the slides (if not the draft) were in fact incorrect. A car and an airplane were listed, for example, as networks that don't connect to the Internet. In both cases, we have commercial instances of them connecting to the Internet.

My suggestion to Bing is to step away from the dubious examples, and simply describe networks that don't connect to the Internet, networks that do but..., and so on.

---

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

Hemant,

> Thus why do we need a new document to document what the ULA can be used

IMHO, because 4193 only makes it *relatively* clear, and there is news
coming back from customer land that people designing their IPv6
addressing plans do not find it sufficiently clear.

Regards
   Brian

---

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

---

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

Another practical ULA usage: a MIF case. An organization uses ULA for
inner communication and PI/PA for connections with external hosts on
the Internet. Own hosts on the Internet set up VPN tunnels for
connection with own internal hosts. On the VPN clients, the VPN tunnel
has an ULA address. A FC00::/7 route points to the VPN server. Easy to
understand, configure and troubleshoot.

With PI, advantage is less than PA, or near to zero.

Teco

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 17 Nov 2011 07:58:47 -0800

required.
includes
connected
think
manner
> ones are viable and which ones are harmful.

+1 that Bing has a good approach and this work is valuable , with the ideal
outcome that the known-good use cases are documented. Yes, ula is useful in
some cases.

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Fri, 18 Nov 2011 02:48:14 +0000

Hi, Hemant

The RFC6204 is for the CPE requirement, but the ULA topic discussed in Homenet is whether it is a good idea for the hosts within a home network to be configured with ULA along with the global PA addresses. Pro is ULA can provide stable local communication regardless of the PA renumbering from the ISP; con is adding operation complexity of running multiple prefixes. It is still controvercial and I don't think the RFC6204 can drive a conclusion for it.

I agree that RFC4193 has provided some clear guidlines of using ULA. But they are *principle* and *general*, and the fact is that there's few deployment of ULA and in some cases it is controvercial. The document intends to move forward on this topic. We tried to make a comprehensive analysis of ULA usecases as a start and hope to provoke discussion so that we may achieve consensus to make some recommendations. Besides, there are some good practise of using ULA as a useful tool, which I belive is worth to be documented and valuable for the readers, and we've received several feedbacks of such stuff after submitting the draft. 

So, there are people do care about using ULA. And I believe the discussion is needed and valuable.

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Hemant Singh (shemant) [[email-masked]]
发送时间: 2011年11月17日 20:37
到: Brian E Carpenter; Fred Baker (fred)
Cc: [email-masked]; [email-masked]
主题: Re: [v6ops] Major use cases for ULA

Hemant

-----Original Message-----

Fred,

required.

Regards
   Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 Nov 2011 21:46:11 -0600

-----Original Message-----
From: Leo Liu(bing) [mailto:[email-masked]] 
Sent: Friday, November 18, 2011 10:48 AM
To: Hemant Singh (shemant); Brian E Carpenter; Fred Baker (fred)
Cc: [email-masked]; [email-masked]
Subject: re: [v6ops] Major use cases for ULA

>The RFC6204 is for the CPE requirement, but the ULA topic discussed in
Homenet is whether it is a good idea for the hosts within a home
>network to be configured with ULA along with the global PA addresses.
Pro is ULA can provide stable local communication regardless of the >PA
renumbering from the ISP; con is adding operation complexity of running
multiple prefixes. It is still controvercial and I don't think >the
RFC6204 can drive a conclusion for it.

RFC 6204 already specifies use of the ULA and a GUA (Globally Unique
Address) prefix from the SP to run concurrently in the home.  Thus the
hosts in the home served by the CPE router will already support
concurrent use of at least two IPv6 address.  

Hemant

---

From: Doug Barton <[email-masked]>
Date: Sun, 20 Nov 2011 20:03:52 -0800

> 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 c…

Personally I think this is the "killer app" for ULA. My opinion is that
a lot of SMBs that can't/won't get their own PI will opt for this
combination.

Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 20 Nov 2011 22:57:04 -0800

as an individual rather than as a chair.

> applying to ARIN for a PI prefix.

The condition may also be ephemeral, e.g. a ula might be retained only
for the duration of the condition where an alternative does not exist.
networks that can facilely renumber in the course of normal operation
might have little trouble using and discarding a ula prefix.

> ones are viable and which ones are harmful.

as an individual rather than as a chair.

It would be if it were neutral, it justifies the usage of a ula behind a
translator in the interest of topology hiding or enhanced security, it
also refers to ula central.

the later doesn't exist and former doesn't seem like the basis for
consensus onthe document.

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Mon, 21 Nov 2011 10:00:10 +0000

Hi, Joel

> consensus onthe document.

My thought of including ULA-C is that, it can be considered as a use case rather than normative reference. Since this draft is all about ULA, we just include the recently discussed ULA-C topic to provoke more discussion. However, if nobody cares about ULA-C, that's OK, we would probably drop it out of the document.

For the former issue, I did not intend to preach people adopting ULA in the interest of security. But for my little understanding, I just doubt that is ULA for security really totally meaningless? I'd like to discuss it in the WG, if there has been strong consensus about this topic, excuse me for my not knowing it.

---

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

> Of Fred Baker

> when renumbering a network". However, it doesn't actually do so.
[WEG] snip
> 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.

---

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

> My suggestion to Bing is to step away from the dubious examples, and
> simply describe networks that don't connect to the Internet, networks
> that do but..., and so on.
>
[WEG] Agree - I already provided similar feedback to the authors directly when I read the review. I would add to that some discussion of when ULA really *isn't* a good idea - to give us an opportunity to reiterate that we don't think it's a good idea to make ULA + a NAT66 GW into the second coming of NAT44 + RFC1918, for example.

Wes George