Re: [Autoconf] Last Call: draft-ietf-autoconf-adhoc-addr-model (IP Addressing Model in Ad Hoc Networks) to Informational RFC

[Alexandru Petrescu <[e-mail]>]

Le 24/03/2010 20:57, Ryuji Wakikawa a écrit :
> Hi Erik,
>
> Thanks for comments.
>
> You had two chances to make comments, i.e. during WGLC and IETF LC.
> It's way too late to send such comments. The document is now in RFC
> ed. queue.
>
> The link-local address is not banished from manet routers. You can
> configure it and use it for router id.

I read Erik's email as suggesting a decouple between the use of the
link-local address and of a Router ID. (his "deflate" to mean contrary
to "inflate").  It may be that the following paragraph in the draft led
to think so:

draft-ietf-autoconf-adhoc-addr-model:
> 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).

... because whereas it _is_ indeed desirable to identify a router with
an IP address, it is not necessarily the case that that IP address is
the address of an interface.  E.g. OSPF does so with a Router ID being
an address (an IPv4 address), and different than any IPv6 addresses it
may have on an interface (be them link-local addresses)

Why does the above paragraph suppose that the Router ID where the
link-local address?

> BUT, the document 'suggest' not to use the link-local address for
> routing protocols

That suggestion is a little daring because it goes against deployed 
OSPF, RIP, RFC4191, ICMPv6, DHCPv6, and more.

> and data packet forwarding.

Forwarding an ll-addressed packet across _known_ links should be indeed
forbidden.  Draft says so.

Minor aspect: it doesn't say what's a link other than having
undetermined connectivity properties, i.e. we don't know what is a link, 
hence get rid of Link-local addresses.

This reason of undetermined link properties is a little difficult to 
grasp for me.

Alex

>
> regards, ryuji
>
>
> On 2010/03/24, at 8:47, Erik Nordmark wrote:
>
>> On 02/19/10 05:42 AM, The IESG wrote:
>>> The IESG has received a request from the Ad-Hoc Network
>>> Autoconfiguration WG (autoconf) to consider the following
>>> document:
>>>
>>> - 'IP Addressing Model in Ad Hoc Networks '
>>> <draft-ietf-autoconf-adhoc-addr-model-02.txt>   as an
>>> Informational RFC
>>
>> I read this draft a few weeks back during the last call. But I
>> didn't send the comments because I wasn't up to speed with the WG
>> discussion, and I figured I could do that while talking to folks in
>> Anaheim. But then the draft was approved.
>>
>> I have two significant issues with the document.
>>
>> First of all it seems to conflate the notion of a router ID with
>> the IP addresses configured on the interfaces on a router. Second
>> of all it seems to discourage the use of IPv6 link-locals as the IP
>> addresses to configure on interfaces on routers.
>>
>> But this seems to be counter to the current set of existing
>> well-known Internet routing protocols.
>>
>> For instance, RIPng doesn't even use a notion of router IDs, and is
>> required to communicate using IPv6 link-local addresses.
>>
>> OSPv3 running on IPv6 also is required to use IPv6 link-local
>> addresses for the exchanges AFAIK, but the router ID is a 32 bit
>> number.
>>
>> ISIS has a router ID that is a NSAP address (derived from an IEEE
>> MAC address), and doesn't require IP addresses to be configured on
>>  the interfaces in order to run the protocol between the routers.
>>
>> Hence router IDs doesn't need to be an IP address, and there is no
>>  need to stay away from IPv6 link-local addresses for the above
>> protocols. Yet this draft has come to the conclusion that things
>> need to be different for links with undetermined connectivity,
>> which makes no sense.
>>
>> Regards, Erik
>>
>>
>> _______________________________________________ Ietf mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/ietf
>
> _______________________________________________ Ietf mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/ietf
>