Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations

[Brian E Carpenter <[e-mail]>]

On 21/05/2013 23:33, Owen DeLong wrote:
> On May 21, 2013, at 12:13 AM, Liubing (Leo) <[e-mail]> wrote:
> 
>> Hi, Lorenzo
>>  
>> Thanks for your careful review and comments. Please see replies inline.
>>  
>> From: Lorenzo Colitti [mailto:[e-mail]] 
>> Sent: Monday, May 20, 2013 3:50 PM
>> To: Liubing (Leo)
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [v6ops] A brief intro-//RE: new draft: draft-ietf-v6ops-ula-usage-recommendations
>>  
>> Bing,
>>  
>> a few comments:
>>  
>> I. "Notice that, as described in [RFC4864], in practice, applications may treat ULAs like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and ordinary GUA Global-scope Unicast Address) to ensure bidirectional communications."
>>  
>> 1. "In practice, applications may treat ULAs like global-scope addresses" is incorrect. ULAs are global-scope addresses, and we should state that they are. 
>> [Bing] They are designed intended to be globally unique, but they are clearly defined as “local IPv6 addresses”. And the sentence actually comes from RFC4193, see section 1.
>>  
> 
> There is a subtlety to the language here that is important.
> 
> SCOPE has a specific meaning WRT IPv6 addresses. While ULAs are "Local" USE addresses, they are not Local SCOPE addresses. They are most definitely global scope addresses as that is meant in IPv6.

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.

(For further thoughts on this see draft-carpenter-referral-ps-02
or even draft-carpenter-behave-referral-object-01.)

   Brian
> I don't see a reference to "local scope" in RFC 4193 section 1. However, even if there is, we should not duplicate that error here.
> 
> 
>> Suggested replacement text: "Note that, while ULAs are global-scope addresses, they do not have global reachability. Therefore, address selection algorithms distinguish between ULAs and GUA (Global Unicast Address) [RFC 6724]".
>> [Bing] As said above, I think the sentence would be good if delete “while ULAs are global-scope addresses”.
> 
> Why? ULAs ARE global scope addresses. While they are not globally routed, they are of global scope. Currently there are only two defined scopes in IPv6… { Global , Link-Local }. There was a third scope (Site-Local), but those were deprecated prior to the creation of ULA.
> 
>> IV. "Alternatively, it could be regenerated regularly, if desired for some reason." Can it? How regularly? If it is regenerated your ULA once a second, how soon before collisions become likely? What about 100, 1000 or 1000000 times per second? You probably want to qualify "regularly".
>> [Bing] Generally, “regularly regenerated” on-demand. Say, upper layer wants a new ULA for a new session id. I think maybe we don’t need to worry about the regeneration rate that might increase the collision probability significantly.  That might only concern in a scientific research of collision.
> 
> That really depends on whether or not there is a bound on regeneration rate. I'll leave out the obvious questions about dubious nature of rapid regeneration.
> 
>> 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.
>> And if they need to connect outside, then just add a NPTv6 gateway and make it as the default gateway. This is to achieve a minimal network environment/management burden.
> 
> I'm sorry, but this is just silly. SLAAC is extremely lightweight in its minimal implementation and if they self-generate a ULA, your "ad-hoc" network is going to need something (probably heavier) to allow the nodes to find each other. Indeed, once you implement enough of the ND process for two nodes to find each other even for link-local addressing, there's really not much left to complete the minimal implementation of SLAAC. I think this is an extremely poor use case and not one which should be deemed acceptable. Sensors are getting smarter and more capable. Existing sensors can and do (in many cases) implement SLAAC.
> 
>> 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.
> 
> This is only a minor complexity and, frankly, is not new. It happens in IPv4. If both prefixes are, in fact, globally routable and/or have similar reachability profiles, then there is usually no issue.
> 
> What is unique to ULA is that it is a globally scoped address without global reachability. Now software must account for the fact that these global scope addresses are special and have an undefined limitation compared to other global scope addresses.
> 
> (One of the many reasons I think ULA is of dubious value at best).
> 
>> The other is about the address selection, without the new rules in RFC6724, it might be problematic to run ULA+PA, when we discuss this in 6renum, Eric Vyncke reported they had a terrible experience of using this mode several years ago. In last IETF, we briefly discussed this issue again,  and we thought it was probably because of the old address selection algorithms that didn’t distinguish ULA from GUA.
> 
> Right… As near as I can tell, this statement pretty much makes Lorenzo's point.
> 
> Owen
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops