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

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Mar 2010 08:47:43 -0700

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

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 24 Mar 2010 12:57:20 -0700

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. 
BUT, the document 'suggest' not to use the link-local address for routing protocols and data packet forwarding.

regards,
ryuji

On 2010/03/24, at 8:47, Erik Nordmark wrote:

> 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.
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Teco Boot <[email-masked]>
Date: Wed, 24 Mar 2010 21:35:37 +0100

Ryuji,

What document are you referring to?
I cannot read in autoconf-adhoc-addr-model what you are saying.

Regards, Teco

Op 24 mrt 2010, om 20:57 heeft Ryuji Wakikawa het volgende geschreven:

> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Mar 2010 23:37:35 +0100

> 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
>>> The IESG has received a request from the Ad-Hoc Network
>>> Autoconfiguration WG (autoconf) to consider the following
>>> document:
>>>
>> 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.
>>
>> 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.
>>
>> 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
>> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>
> _______________________________________________ Ietf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/ietf
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Mar 2010 17:20:17 -0700

> Why does the above paragraph suppose that the Router ID where the

There is other text that conflate them such as this text in section 5
    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.
Similar text specific to IPv6 is in a later section.

The motivation for this seems to be to get a unique router ID across the 
domain, which I hopefully succeeded explaining is a separate issue from 
the IP addressed assigned to the router's interface(s).

> OSPF, RIP, RFC4191, ICMPv6, DHCPv6, and more.

Daring and inconsistent with existing practice.

> This reason of undetermined link properties is a little difficult to

I thought the WG had discussed this for a few years. I'm sorry if it is 
still not clear.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 24 Mar 2010 17:20:22 -0700

> may have on an interface (be them link-local addresses)

This is an aside, hence I'm not copying the IESG, but I think IS-IS got 
this right by using a MAC address as the router ID. Having factory 
assigned router IDs simply things a fair bit. Hence I don't think it is 
necessarily desirable to identify a router using an IP address.

    Erik

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 24 Mar 2010 17:40:26 -0700

> necessarily desirable to identify a router using an IP address.

This goes with what I have been saying to the LISP
guys for over a year now. An IP address identifies
an *interface*; it does not identify a node (router
or host).

Fred
[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Mar 2010 11:04:07 -0700

Erik,

First of all, the document is *an* addressing model for ad hoc networks. 
It does not claim to be the only model. For instance, during working 
group discussions it also became apparent that link local addresses 
could also be employed, albeit -- as stated in the document -- the 
working group prefers other types of addresses.

Note that this document talks about prefix and address configuration, 
not router IDs. You assume that we talk about router IDs because the 
document says that it would be beneficial to have the addresses be 
unique within a routing domain. But that's not the reason. The reason is 
that in an ad hoc network you may end up being a neighbor to any other 
device, and you want to avoid an address collision merely for the 
reasons of not getting a collision of two same addresses in the same link.

Jari

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 26 Mar 2010 11:23:07 -0700

> reasons of not getting a collision of two same addresses in the same link.

This paragraph talks about the requirements of the routing protocols, 
not about the need for routers to move around:
    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]).

The only requirement I know if in the *routing protocols* is around 
router ID uniqueness.
If you disagree, then can you please explain why there is a need to 
refer to routing protocols in the above paragraph?

    Erik

---

From: Jari Arkko <[email-masked]>
Date: Fri, 26 Mar 2010 11:40:21 -0700

Erik,

> refer to routing protocols in the above paragraph?

I can see why the text in the document may be confusing. But I think the 
primary reason we require uniqueness is the one that I explained in the 
previous e-mail. I would also like to point out that there are *some* 
routing protocols that *do* require unique IDs -- I'm told that this is 
the case with OLSR, for instance. So as far as I can tell the text is 
factually correct, even though I do agree with you that for most routing 
protocols its not the case.

Jari