ietf
[Top] [All Lists]

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

2010-03-24 17:36:11
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:

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 and of any kind of address.

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
Ietf(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________ Ietf mailing list
Ietf(_at_)ietf(_dot_)org https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf