Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

[Alexandru Petrescu <[e-mail]>]

Le 29/06/2010 23:55, Jari Arkko a écrit :
> Christopher,
>
>> Incidentally the charter refers to RFC 5889, which is not yet published.
>> I see that is in AUTH48, but noted as on hold for a technical issue.
>> AUTH48 seems rather late for a technical issue, unless meaning a
>> publication technical issue rather than an engineering technical issue.
>
> Yes it is late. We approved the document but after approval there was a
> comment on the IETF last call thread from Erik Nordmark. We are trying
> to resolve it but unfortunately it took a long time for me to do so. But
> we are now trying to do it. The standing proposal is below, comments
> appreciated.
>
> Jari
>
> -----
>
> We talked about this during Anaheim but never got to the end of it.
> Sorry -- I should have posted a suggestion back then but other business
> has kept me busy. I have now looked at the discussion again.
>
> The essence of Erik's complaint was twofold. First, the document claimed
> that routing protocols require a unique IP address (and not just a
> router ID), which is not true. Second, that the document unnecessarily
> dismisses link local identifiers as addresses.
>
> About the first issue: Erik is right that not all routing protocols
> require unique IP addresses at all. But at the same time, apparently
> some routing protocols in the MANET space do require it (e.g., OSLR in
> RFC 3626). In a way, the document is factually correct on this point as
> it states that some protocols do have these requirements. But it may
> also be misleading from another perspective, as we certainly do not want
> to claim that using unique IP addresses is a recommended design for a
> routing protocol or the only possible model.
>
> The second issue is partially related to the first one, as one of the
> reasons for using non-link-local addresses is to enable the use of
> unique addresses in routing protocols. In any case, the intent was never
> to claim that link local addresses cannot be used. The document merely
> makes one recommendation about a commonly used addressing model in adhoc
> networks. I would like to defend the working group's right to publish
> such an "example model" -- particularly after years of effort spent in
> trying to find the true universal model. As long as the working group is
> not making false claims, this is clearly appropriate. But I can see that
> the document could be clearer about its claims.
>
> Here's a possible rewrite of Section 5 to address these issues:
>
> OLD:
> Routing protocols running on a router may exhibit different
> requirements for uniqueness of interface addresses; some have no such
> requirements, others have requirements ranging from local uniqueness
> only, to uniqueness within, at least, the routing domain (as defined
> in [RFC1136]).
>
> Configuring an IP address that is unique within the routing domain
> satisfies the less stringent uniqueness requirements of local
> uniqueness, while also enabling protocols which have the most
> stringent requirements of uniqueness within the routing domain. This
> suggests the following principle:
>
> o an IP address assigned to an interface that connects to a link
> with undetermined connectivity properties should be unique, at
> least within the routing domain.
> NEW:
> Routing protocols running on a router may exhibit different
> requirements for uniqueness of interface addresses; some have no such
> requirements, others have requirements ranging from local uniqueness
> only, to uniqueness within, at least, the routing domain (as defined
> in [RFC1136]). Many modern routing protocols do not need to employ
> unique addresses at all, and theoretically, their only requirement is that
> some router identifier is unique.
>
> Nevertheless, configuring an IP address that is unique within the routing
> domain satisfies the less stringent uniqueness requirements of local
> uniqueness, while also enabling protocols which have the most
> stringent requirements of uniqueness within the routing domain. As
> a result, many current deployments have chosen to employ the following
> simplifying principle:
>
> o an IP address assigned to an interface that connects to a link
> with undetermined connectivity properties should be unique, at
> least within the routing domain.
>
> And in Section 6.1:
>
> OLD:
> o There is no mechanism to ensure that IPv6 link-local addresses are
> unique across multiple links, hence they cannot be used to
> reliably identify routers (it is often desirable to identify a
> router with an IP address).
> NEW:
> o There is no mechanism to ensure that IPv6 link-local addresses are
> unique across multiple links, hence they cannot be used to
> reliably identify routers, should this be necessary in the chosen
> routing protocol.

There is no mechanism to ensure that IPv6 global addresses are unique 
across multiple globes either.  They are globally unique across our 
globe, as the link-local addresses are unique across one link.

I don't see the sense of both OLD and NEW "There is no mechanism to 
ensure that IPv6 link-local addresses are unique across multiple links" 
- they don't need to.

 From that unnecessary statement to derive the conclusion "they cannot 
be used to reliably identify routers" is making even less sense.

For me it's hard to retrofit proper thinking into text making little 
sense to my reading, IMHO.

Alex

>
> OLD:
> Therefore, autoconfiguration solutions should be encouraged to
> primarily focus on configuring IP addresses that are not IPv6 link-
> local.
> NEW:
> Therefore, a common theme in many autoconfiguration solutions is to
> focus on configuring IP addresses that are not IPv6 link-
> local.
>
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf
>