On May 24, 2013, at 05:30 , Anders Brandt <Anders_Brandt <at> sigmadesigns.com> wrote:

Hi Lorenzo

 

> So you can use any type of address, not only ULA. So this is not a use case for ULA.

 

The ULA reasoning starts elsewhere. It is tied to a deployment use case:

 

When nodes are installed in a new house, there may be no internet connectivity - and even more importantly:
Even if there is internet connectivity, then you can be certain that at some time, the ISP will change your
assigned prefix.

Why can you be certain of that? I understand why you cannot be certain that they won't. But I do not understand or believe that you can be certain that they will.

However, even in such a case, the router should provide the ULA in an RA. There is no need to preconfigure ULA into the node in question rather than use autoconfiguration.

So in the homenet context we're listening to what the people building the constrained devices are telling us.

The ISPs are saying that it is very unlikely that the homenet's prefix will be persistent.  Certainly not in all cases.

The homenet arch assumes the use of ULAs for internal communications and stablity, and that ULA prefixes will be used in RAs.  Alongside GUA prefixes where they are also in use.

It may be that certain home gateways generate their own ULA /48's. The homenet arch talks about multiple ULA /48's potentially being in use.

This is critical to certain 6LoWPAN applications such as home automation.

Remote controls, sensors and wall controllers are spread all over the house.
They control lights, garage doors and aircon devices.

That doesn't mean that they don't need to support RA or that they cannot autoconfigure an address. There is no valid reason these devices should have burned-in ULA. Such an addressing scheme would, in fact, be quite dysfunctional.

Do all 6lowpan devices support RA in the conventional sense?  Or when sleeping?

The addresses of the lights, garage doors and aircon devices MUST NOT change since the

remote controls, sensors and wall controllers are permanently paired to the IPv6 addresses of
lights, garage doors and aircon devices on the application level.

That's just really, REALLY bad application design. How do all of these ULA prefixes get properly routed when the devices are moved from one segment in the home to another? Do you add a giant layer of MIP complexity to the ULA in order to make that all work?

The smaller devices need to be paired with the oversight application(s). Those application(s) should provide the required directory services for them to obtain the IPv6 address(es) of other devices they need to communicate with. (The oversight application could be as simple as a dynamic DNS server or as complex as a centralized home automation management application. Whether support for pairing with more than one oversight application is required is left as an exercise for the device manufacturers.

So this would be the desired model of course, but what are the actual constraints?

Only ULA prefixes provide that stability, yet ability to route within the home.

The lights, garage doors and aircon devices MAY also have global prefixes for external use by
portals and advanced clients.

ULA prefixes can't provide that stability, either. Burning a prefix into a device is just bad juju from start to end.

It will lead to some of the same problems we have with similar systems in IPv4 where applications have built-in assumption that the network is not segmented and therefore do not function in environments where it is.

If you burn a pre-determined ULA prefix into devices, then you either:

1)

a) Presume all devices that should talk to each other are on the same link.

b) Presume that all devices on the same link should talk to each other.

c) Break installations where multiple parts of the system are on different segments.

or

2)

a) Require significant overhead and additional facilities (such as MIP) to make communication possible.

b) Create unnecessary external dependencies

c) Complicate and expand the codebase on resource constrained nodes.

But again, I agree that "burnt in" addresses are highly undesirable, but are there scenarios where they are unavoidable? Perhaps we're asking in the wrong list.

Tim

Owen

 

Thanks,

  Anders

 

 

From: v6ops-bounces-EgrivxUAwEY@public.gmane.org [mailto:v6ops-bounces-EgrivxUAwEY@public.gmane.org] On Behalf Of Lorenzo Colitti
Sent: 24. maj 2013 13:42
To: Liubing (Leo)
Cc: v6ops-EgrivxUAwEY@public.gmane.org; draft-ietf-v6ops-ula-usage-recommendations-nZLwadvX8BDR74oF6e/6QQ@public.gmane.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

 

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <leo.liubing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:

 V. "the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual address assignment? How is it possible that a sensor doesn't support automatic address assignment due to lack of resources, but has enough resources to implement a UI for manual address assignment?

[Bing] The lack of resources mainly regarding the network environment, there might not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in the embedded system, like the MAC addresses in every single NIC or self-generating a ULA, then they could make ad-hoc networking without address provisioning procedures.

How are those nodes going to find the MAC address of the link router to communicate off-link? If they can't do this, then you don't need ULA, you can just use link-local. If they can do this, then they must support router advertisements or similar. If they support router advertisements, then they can use autoconfiguration. 

[Bing] Surely they need to support SLAAC, it’s a basic IPv6 function , the draft specifically noted this point.  But if the sensors are in a MANET, then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA is suitable for this scenario, however, current text seems not sufficient/clear, will modify later.

 

If they support SLAAC, then they don't need to be pre-configured, because they can just use SLAAC to autoconfigure addresses. And if they can autoconfigure an address, they can use a global address. So there is no need to use ULA.

 

[Bing] The reasoning is flawed. Let’s do not mix the concepts of global addr-provisioning and autoconfiguration together.

 

Why is it flawed? You said that a use case for ULA is resource-constrained nodes, because you can pre-assign addresses to them, and that this simplifies the nodes. But it doesn't simplify the nodes, because even if you pre-assign addresses, the nodes still need some mechanism (e.g., RA) in order to find out who you can communicate to. So the nodes have to support RAs. And if the nodes support RA, you can use autoconfiguration and you don't need to pre-assign addresses. So you can use any type of address, not only ULA. So this is not a use case for ULA.

 

And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2

 

That draft expired in 2008, so it's not really relevant. Do you have a more up-to-date document?

 

On Fri, May 24, 2013 at 8:01 PM, Liubing (Leo) <leo.liubing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:

Hi, Lorenzo

 

From: Lorenzo Colitti [mailto:lorenzo-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org] 
Sent: Friday, May 24, 2013 5:44 PM

To: Liubing (Leo)
Cc: v6ops-EgrivxUAwEY@public.gmane.org; draft-ietf-v6ops-ula-usage-recommendations-nZLwadvX8BDR74oF6e/6QQ@public.gmane.org
Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

 

On Tue, May 21, 2013 at 6:34 PM, Liubing (Leo) <leo.liubing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:

No, the probability is much higher than you think. See RFC 4193 section 3.2.3. If I'm reading that section correctly, if you generate 10000 ULAs you'll get a collision 1 in 500k times. If you generate 100000 (e.g., if you regenerate them once a second, for one day) you'll get a collision once in 1000 times. And so on.

[Bing] In theory, I agree with you. But the point here is where do we need to change the ULA so frequently? For random draw? I can hardly imagine a use case of that.

 

This is a technical document meant to provide guidance, so I'd say that it's not appropriate to use vague words like regularly "regularly", without stating what they mean to state what it means. Can I generate 10000 ULAs per second, as long as I do it "regularly"? Likely not.

 

So you either remove the text, or state that if ULAs are generated regularly, then collisions are possible, and perhaps provide provide an example that calculates the probability of collision with some reasonal value of the regeneration interval.

 

[Bing] OK, I’ll refine the word.

 

 V. "the network needs ULA as the on-demand and stable addressing which doesn't need much code to support address assignment mechanisms like DHCP or ND." I don't think this makes sense. Are you saying such nodes only support manual address assignment? How is it possible that a sensor doesn't support automatic address assignment due to lack of resources, but has enough resources to implement a UI for manual address assignment?

[Bing] The lack of resources mainly regarding the network environment, there might not be a comprehensive network provisioning environment for the nodes. If they can be pre-configured with ULA, say, hard-coded in the embedded system, like the MAC addresses in every single NIC or self-generating a ULA, then they could make ad-hoc networking without address provisioning procedures.

How are those nodes going to find the MAC address of the link router to communicate off-link? If they can't do this, then you don't need ULA, you can just use link-local. If they can do this, then they must support router advertisements or similar. If they support router advertisements, then they can use autoconfiguration. 

[Bing] Surely they need to support SLAAC, it’s a basic IPv6 function , the draft specifically noted this point.  But if the sensors are in a MANET, then the autoconfiguration is different with the traditional wired SLAAC, since MANET is based on a multi hop topology. ULA is suitable for this scenario, however, current text seems not sufficient/clear, will modify later.

 

If they support SLAAC, then they don't need to be pre-configured, because they can just use SLAAC to autoconfigure addresses. And if they can autoconfigure an address, they can use a global address. So there is no need to use ULA.

 

[Bing] The reasoning is flawed. Let’s do not mix the concepts of global addr-provisioning and autoconfiguration together. And in MANET, the SLAAC is not (fully)applicable, see http://tools.ietf.org/html/draft-ietf-autoconf-statement-04.html#section-5.2

 

VI. "there always be some argument that in practice the ULA+PA makes terrible operational complexity. But it is not a ULA-specific problem; the multiple- addresses-per-interface is an important feature of IPv6 protocol. Running multiple prefixes in IPv6 might be very common, and we need to adapt this new operational model than that in IPv4." This text does not make sense. Just because having multiple global-scope addresses is a feature of IPv6 doesn't mean that you must have multiple global-scope addresses. For example, you can use only global addresses and have no routing complexity.

[Bing] The ULA+PA operational complexity contains two aspect.

One is the common issue as described in the texts, running multiple prefixes in a network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.

No, because having multiple prefixes introduces operational complexity even if the admins understand multiple prefixes. All things being equal, having only one prefix (e.g., a global prefix) is always going to be simpler than having two.

 

In other words: what you're saying is "let's create complexity, because admins will need to understand the complexity anyway". What I'm saying is that while they need to understand the complexity, we don't have to create the complexity if we don't need it.

[Bing] No, I’m not say that. ULA+PA is identified as beneficial use case in 6renum and Homenet. So the admins need to adapt the complexity if they want the benefit.

 

Ok, so then just cite those documents, say that there is a trade off between complexity and functionality, and leave it at that?

[Bing] A brief complexity hint would be valuable. Thanks.

 

B.R.

Bing

 

_______________________________________________
v6ops mailing list
v6ops-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops-EgrivxUAwEY@public.gmane.org
https://www.ietf.org/mailman/listinfo/v6ops

On Wed, May 22, 2013 at 5:21 AM, Brian E Carpenter <brian.e.carpenter-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

That's correct, of course. The underlying problem here is that the

notion of concentric circles of scope that was originally described
for IPv6 is simply broken. We can't fix that in the context of
describing ULA usage scenarios, so let's not try.

Actually, I think the underlying problem as regards this specific draft is that ULAs were not well thought-out. They came out of a compromise where no side got what it wanted and what we got was a poorly-understood, possibly unusable hybrid.

Obviously that ship has sailed, but still, what we're doing here might be putting lipstick on a pig.

Well, the homenet ship is just sounding its horn, with Mark and Ray about to toss the ropes to shore, weigh anchor and sail off.

If you disagree with the rationale for ULA usage in homenet, now's a good time to shout.

The argument in favour includes constrained devices (perhaps with ULAs "burnt in"), connectivity inside routed homenets prior to external ISP connectivity, internal connectivity during sustained ISP outages, and internal connectivity stability when external prefixes change.

An argument against is the ULA (no IPv6 GUA) + IPv4/NAT scenario. But wider implementation of 4191/6724, to enable support of the recommendations in 6204/6204-bis, would help address tha t concern.

Tim

On Tue, May 21, 2013 at 6:54 PM, Tim Chown <tjc-jaJdc+oKuOm+cE1VCfRBVw@public.gmane.org> wrote:

Which reminds me, I would like to see this document do some deeper analysis of the issue raised after IETF86, regarding "ULAs on by default" alongside IPv4/NAT. That thread, discussing the practical issues, ran to 150+ emails before fizzling out without any specific proposed text, either for Bing's draft or the homenet arch. I recall that Ole's point on this was that *if* hosts supported RFC4191 RIO, then ULA routes could be added without a default route, and dependencies/timeouts on ICMPv6 redire cts avoided. And RFC6204bis ULA-5 recommends that behaviour (along with L-3). The little snag is that current OSes certainly don't all support RFC4191.

Agreed. Though since this document is about usage guidelines, then there is nothing much it can do except saying "currently, ULA+IPv4 or ULA+IPv4+IPv6 GUA doesn't work in the general case because OSes don't all support RFC 4191 and RFC 6724". Right?

Sounds fine to me. In my view, that's the type of analysis, and the type of implicit recommendations that this type of document can usefully make. i.e. If you are thinking about using ULAs for a specific use case, these are the considerations. If that can be used as some extra encouragement for vendors to support 4191 and 6724, that's a bonus.

I must admit that I had thought there was wider implementation of 4191 than it seems there is.

Tim

On Tue, May 21, 2013 at 4:13 PM, Liubing (Leo) <leo.liubing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:

[Bing] The ULA+PA operational complexity contains two aspect.

One is the common issue as described in the texts, running multiple prefixes in a network is new to the traditional IPv4 model, the admins need to be familiar with it in the future.

No, because having multiple prefixes introduces operational complexity even if the admins understand multiple prefixes. All things being equal, having only one prefix (e.g., a global prefix) is always going to be simpler than having two.

It will of course be simpler, the open question being what is meant by "all things being equal".

In a homenet, there may be cases where there is no external connectivity, in some cases where none has yet been established (rather than it having been there and gone away). There may be devices that have ULAs "burnt in", for which those ULAs need to be routed around the scope of the homenet.  And there is an argument for ULAs for stable connectivity internally in the face of whatever happens to external prefix(es)/connectivity.

In a dual-stack homenet, there will be at least two prefixes, one IPv4, one IPv6.

Which reminds me, I would like to see this document do some deeper analysis of the issue raised after IETF86, regarding "ULAs on by default" alongside IPv4/NAT. That thread, discussing the practical issues, ran to 150+ emails before fizzling out without any specific proposed text, either for Bing's draft or the homenet arch. I recall that Ole's point on this was that *if* hosts supported RFC4191 RIO, then ULA routes could be added without a default route, and dependencies/timeouts on ICMPv6 redirects avoided. And RFC6204bis ULA-5 recommends that behaviour (along with L-3). The little snag is that current OSes certainly don't all support RFC4191.

In other words: what you're saying is "let's create complexity, because admins will need to understand the complexity anyway". What I'm saying is that while they need to understand the complexity, we don't have to create the complexity if we don't need it.

Well, in a home network there will be no admins. Plug and play is what we want. But connection timeouts are equally what we do not want.

Tim