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

From: Jari Arkko <[email-masked]>
Date: Thu, 01 Jul 2010 23:30:21 +0300

I wanted to send a follow-up for two reasons. First, I received a 
proposal for slightly changed text from Mark and I wanted to get it out 
for your review as well. Please see the changed text at the end of this 
e-mail. Secondly, I understand that some people have had (as they 
should) concerns over the process of making late changes to an already 
approved document.

In general, we try to not make any substantive changes to documents once 
they are approved, and the bar for making changes is definitely high. 
Almost all documents have some editorial changes as they go through the 
RFC Editor and the author's final reviews. In a small number of 
documents there's a technical issue that we detect after approval. We 
would normally not make any changes even in these cases unless there was 
a clear error. Minor obvious fixes may get done through a discussion of 
the chairs, authors, and ADs, but for anything of substantial nature we 
try to bring the issue to the working group. If the issue is really 
severe and requires large changes we cancel the approval and bring the 
document back to the working group, redoing last calls and other reviews 
so that the new version can be approved again.

In this case we approved the document during IETF-77 but a few days 
later Erik Nordmark brought up an issue which in his mind was serious, 
at [email-masked] mailing list. During the meeting we had some discussion 
about it on the list but never closed the issue. I talked to Erik face 
to face and did come to an agreement, but since I was busy I did not 
find time to follow up with concrete text proposal until much later. Two 
weeks ago I finally had text to send out, the same text proposal that I 
posted to the WG mailing list in this thread. In the meantime the RFC 
Editor has done their share of the work and the document is now in 
AUTH48, only waiting for the resolution of this issue to be published.

We have not had a substantial discussion of the proposal yet with Erik 
-- he has acknowledged that he's seen the proposal but has been too busy 
at day job to do a detailed review. He has promised to provide feedback 
in the next few days. In the meantime I wanted to bring the issue up 
with the working group so that you know what is going on. Ultimately, it 
is your call to make changes. No single person's opinion can change the 
document at this stage, be it Erik, the ADs, or the authors. That being 
said, we do try to fix problems if there are some.

In this particular issue, I personally believe that despite's Erik's 
concern the document as approved was factually correct. However, at the 
same time I think that the document could have been clearer about what 
it is saying about routing protocols and what it is not. That was the 
basis of my suggested edit. I think this edit, if agreed, is somewhere 
between an editorial and technical change and something that can be done 
in AUTH48 with the working group's acceptance. In other words, it is not 
necessary to redo the approval process.

Jari

---------------

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]). Routing protocols that do not require unique IP 
addresses within the
  routing domain utilize a separate unique identifier within the routing
  protocol itself that must also be configured in some manner.

  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, the following principle allows for IP autoconfiguration to
  apply to the widest array of routing protocols:

  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 by the routing
     protocol for which IP address autoconfiguration is being provided.

OLD:
  Therefore, autoconfiguration solutions should be encouraged to
  primarily focus on configuring IP addresses that are not IPv6 link-
  local.
NEW:
  Therefore, an autoconfiguration solution which provides a mechanism for
  assigning addresses with a wider scope than IPv6 link-local alone will
  be more generally useful than one that does not.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 08 Jul 2010 00:34:32 +0300

Just a reminder that we have to decide what to do here. We will 
determine what to do based on WG feedback. Absent any significant 
opposition, the default action will be to adopt the current proposal 
(posted earlier to the list) and publish the RFC. I would like to decide 
one week from now, i.e., please send comments by Wednesday, July 14th.

Jari

---

From: Henning Rogge <[email-masked]>
Date: Thu, 8 Jul 2010 07:57:13 +0200

> one week from now, i.e., please send comments by Wednesday, July 14th.
Absence of opposition ????

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Teco Boot <[email-masked]>
Date: Thu, 8 Jul 2010 09:09:38 +0200

My remarks made before. 

On the document:
1) IMHO the remarks on link-local are not that important.
2) My biggest problem is the /128 mask, this makes L3 communication dependent
on the MANET protocol, even for nodes with perfect L2 connectivity. Using a 
/64 on the MANET interface, and using the /128 for the routing protocol, 
does not have this problem. This method is used quite often (at least in some
olsr and ospf implementations).
Issue can be tackled in other documents, e.g. a problem statement, or MANET 
addressing version 2.
In other words, try to publish the document soon.

On the charter:
I suggest to accept some documents as WG documents:
 - draft-bernardos-manet-autoconf-survey
 - draft-baccelli-multi-hop-wireless-communication
I support the two-step approach, where the second (getting prefix and optionally
other parameters) will be based on DHCPv6.
I think the first step could be based on SLAAC (ND-approach) and / or DHCPv6.
I say it is to early to decide.
I am against working on a solution based on a single central node.

Regards, Teco

Op 7 jul 2010, om 23:34 heeft Jari Arkko het volgende geschreven:

> Just a reminder that we have to decide what to do here. We will determine what to do based on WG feedback. Absent any significant opposition, the default action will be to adopt the current proposal (posted earlier to the list) and publish the RFC. I would like to decide one week from now, i.e., please send comments by Wednesday, July 14th.
> 
> Jari
> 
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 8 Jul 2010 09:55:24 +0100

It still seems odd, at the least, to be back at the WG in AUTH48.
But having said that, there are three suggested edits. Bottom line
either version of each is acceptable. There is however a difference
in the third one. The first two are clarifying technical comments.
I'm not sure they really add anything, but they don't hurt. The
third is different though, it changes the actual meaning, from
"this is preferred", to "this is more useful", which are not the
same thing. I think the old version is what got consensus everywhere,
and changing it is a bit more than editorial. But as I said, either
is acceptable in itself.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jari Arkko
Sent: 07 July 2010 22:35
To: [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new
AUTOCONF charter proposal)

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Jari

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 8 Jul 2010 11:01:24 +0200

> and changing it is a bit more than editorial. But as I said, either

I agree with Chris. I am fine with the first two edits. The last seems
to change the content on which the WG has agreed upon. I don't think
we should change this in AUTH48, unless there is a very strong new
argument, which the WG has missed or not correctly understood.

Ulrich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Jul 2010 10:28:14 -0700

Hello Jari,

I support the publication of RFC 5889 with the inclusion of
the revisions as you and Erik have suggested below.

Regarding the last edit, I am also O.K. with that, but
with the understanding that link-local solutions are
neither favored or disfavored per se.  Wide applicability
and performance issues (for example) are (to me at least)
much more important.

Regards,
Charlie P.

On 6/29/2010 2:55 PM, Jari Arkko wrote:
> 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:
> 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.
>
> stringent requirements of uniqueness within the routing domain. As
> a result, many current deployments have chosen to employ the following
> simplifying principle:
>
> reliably identify routers, should this be necessary in the chosen
> routing protocol.
>
> OLD:
> Therefore, a common theme in many autoconfiguration solutions is to
> focus on configuring IP addresses that are not IPv6 link-
> local.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 08 Jul 2010 19:42:29 +0200

> reliably identify routers, should this be necessary in the chosen

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

---

From: Stan Ratliff <[email-masked]>
Date: Thu, 8 Jul 2010 13:45:24 -0400

Jari,

+1 on what Charlie said.

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 08 Jul 2010 19:48:26 +0200

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 - I am ready to spend time reading and trying to understand.  I am
ready to give my oppinion about this last point - the IPv6 link-local
addresses.

If asked whether I agree with the NEW text on LLs then I say no, I do
not agree with it.  It is better than the old text but still makes
little sense to my reading (e.g. "IPv6 ll addresses are not unique
across links" is a statement which makes little sense, an answer to
something nobody doubted; worst, to derive conclusions saying that LL
addresses are not useful in "MANET ad-hoc" networks because of their
lack of uniqueness is even less sense.)

My two cents worth,

Alex

> 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.
>
>  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.
>
> 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.
>
> 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]).
>
> 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.
>
> OLD: Therefore, autoconfiguration solutions should be encouraged to
> 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 [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 08 Jul 2010 20:21:37 +0200

Le 08/07/2010 19:28, Charles E. Perkins a écrit :
> neither favored or disfavored per se.

That sounds as a "MAY LL" which is more positive to my reading than 
"There is no mechanism to ensure uniqueness LL ... hence ... cannot ..."

Writing "There MAY be link-local solutions" is something I could easily 
agree with.

Alex

  Wide applicability

---

From: Zach Shelby <[email-masked]>
Date: Fri, 9 Jul 2010 10:58:29 +0300

+1 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Jul 2010 16:15:32 +0200

>      least within the routing domain.

ACK to this section.

>      protocol for which IP address autoconfiguration is being provided.

I think this is still too strong.
"There is no mechanism to ensure..." does sound as there never will be one. If 
we cannot find a mechanism/protocol to do this, we cannot find one that 
creates routing unique adresses (because the later would do the former too).

I think it should start with something like this:
"The default mechanisms of IPv6 cannot ensure that..."
(instead of "There is no mechanism to ensure that...")

>   be more generally useful than one that does not.

ACK to this.

Any autoconfiguration sollution that solves the "routing unique" case can 
easily be adapted to solve the "linklocal" one.

Henning Rogge
-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Jul 2010 18:12:45 +0200

> (instead of "There is no mechanism to ensure that...")

Although I think the document should not kept waiting, I don't agree on this.
There is no mechanism to detect duplicate globals on different links.
The ND DAD mechanism does not work in a MANET for LL, and _also_ not for globals !!
A mechanism that ensures unique Interface-IDs ensures unique LLs.

We all agreed on that we shall not work on a new protocol for autoconfiguring LLs.
It is globals and MANET-locals (ULAs) that we are looking for.
That is in the document, in old and new text.

I would use unique LLs as router-IDs. I don't get what is wrong with this, as long as LLs are unique.
But LLs MUST NOT be used for multi-hop forwarded traffic.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 9 Jul 2010 18:46:19 +0200

Am Freitag 09 Juli 2010, 18:12:45 schrieb Teco Boot:
> > "There is no mechanism to ensure..." does sound as there never will be
> > one. If we cannot find a mechanism/protocol to do this, we cannot find
> > one that creates routing unique adresses (because the later would do the
> > former too).
> > 
> Although I think the document should not kept waiting, I don't agree on
> this. There is no mechanism to detect duplicate globals on different
> links. The ND DAD mechanism does not work in a MANET for LL, and _also_
> not for globals !! A mechanism that ensures unique Interface-IDs ensures
> unique LLs.
> 
> We all agreed on that we shall not work on a new protocol for
> autoconfiguring LLs. It is globals and MANET-locals (ULAs) that we are
> looking for.
Yes... I just said that an autoconfiguration protocol that solves the 
configuration problem for global unique IPs or ULAs would be trivial to adapt 
for generating "link local" IPs, just by putting the LL-prefix to the 
generated ULAs.
 
> as long as LLs are unique.
There is nothing wrong with this. This strategy will solve the LL-generation.
Which instantly contradicts the statement "there is no mechanism to ensure..." 
part.

> But LLs MUST NOT be used for multi-hop forwarded traffic.
No problem with this one.

Henning Rogge

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 09 Jul 2010 13:52:57 -0700

> necessary to redo the approval process.

I do think the document is misleading and confused.
That starts with the discrepancy between the title
	IP Addressing Model in Ad Hoc Networks
and the abstract, which limits itself to configuring IP addresses for 
router interfaces and not for the whole of an ad hoc network.

I was under the impression that the WG was looking at a document that 
addressed the scope that is implied by the title.

I find the more limited scope odd, since we existing routing protocols 
like IS-IS that can operate (exchange routing information, forward IP 
packets) without any IP addresses configured on the routers' interfaces. 
(Even though a router needs some IP addresses to be manageable with SNMP 
and to be able to send ICMP errors.)

The implied conclusion that IPv6-link local addresses are undesirable 
for router's interfaces is even odder, since RIPng and OSPFv3 both 
require routers to use IPv6 link-local addresses for the routing 
protocol exchanges.

The document seems to assume that the uniqueness scope of link-local 
addresses is limited to a single link, when it is the routability scope 
which is limited to the link. There is a class of link-local addresses 
with U=1 (those derived from EUI-64) that are globally unique - but 
still is not routable outside of the link.

The result is that the document can easily be construed as discouraging 
approaches that make a lot of sense, which seems counterproductive.
An example of such an approach is a routing protocol which uses IEEE MAC 
addresses as router ids, assigns IPv6 link-local addresses to the 
router's interfaces and uses that in the routing protocol exchanges, and 
configures global addresses for use by applications.

I think the exercise here is to try to correct some minor wording in the 
recommendations in the document, but even if we succeed in doing so the 
premises expressed in the introduction and elsewhere will be a bit odd, 
since they focus on the configuration of router interfaces and not on 
the addressing model of the Ad Hoc network.

> in [RFC1136]). Routing protocols that do not require unique IP addresses
> within the

With IS-IS one doesn't configure the router id; it is a factory assigned 
MAC address. Such an approach is perfectly valid for Ad Hoc routing 
protocols as well.

Note that a router (as opposed to routing protocol) require IP addresses 
to be managable and to be able to send ICMP errors. But the above 
paragraph is trying to derive recommendations from the latter.

I suggest the wording
Routing protocols that do not require unique IP addresses within the
routing domain utilize a separate unique identifier within the routing
protocol itself; such identifiers could be based on factory assignment 
or configuration.

> stringent requirements of uniqueness within the routing domain. As a
> result, the following principle allows for IP autoconfiguration to

According to RFC 4291 EUI-64-based interface identifiers have global 
scope when created from a universal token. A result of this is that 
link-local addresses formed from such interface identifiers have global 
scope. Hence the "no mechanism" above seems factually incorrect.

Thus I think section 6.1 needs to differentiate between the global and 
local scope for the interface identifiers for it to make sense.
Should I suggest replacement text?

This paragraph seems like a non seqiteur:
    o  Routers cannot forward any packets with link-local source or
       destination addresses to other links (as per [RFC4291]) while most
       of the time, routers need to be able to forward packets to/from
       different links.
Clearly the application traffic needs to use non-link-local addresses to 
work across multiple links, but that has nothing to do with what IP 
addresses are configured on the interfaces of routers as we see from the 
requirement for RIPng and OSPFv3 to use IPv6 link-locals on router 
interfaces.

Instead the issue is that link-local addresses are not useful for 
applications *other than routing protocols*, and that is the motivation 

> be more generally useful than one that does not.

That misses the point. It is the motivation for this recommendation 
which is confused and misleading, and not the conclusion itself. The 
motivation is that applications (other than routing protocols) most 
likely desire to communicate across the whole Ad Hoc network, if not 
across the whole Internet, which makes link-local addresses of limited use.

But they can still be quite useful as for the purposes of routing 
protocols, and bootstrapping address autoconfiguration protocols.

This confusion is related to the odd scope mismatch between the title 
and the abstract. Clearly we want to be able to autoconfigure 
non-link-local addresses for applications, but the abstract limits the 
scope of the document to IP addressed assigned to router interfaces, and 
there link-local address might be just fine.

Note that the last sentence in the first paragraph in section 4 is also 
misleading (I'm assuming that paragraph is about configuring router 
interfaces and not host interfaces) in saying
    Note that while link-local addresses are assumed to be "on link", the
    utility of link-local addresses is limited as described in Section 6.
when in fact using link-local address, in particular those based on 
global scope interface identifiers, might be just fine for router 
interfaces.

    Erik

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Jul 2010 14:30:33 +0300

> IP Addressing Model in Ad Hoc Networks

Erik is right that the title and content don't match. So why not update the name slightly:

"Router Addressing Model in Ad Hoc Networks"

Zach

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 19 Jul 2010 22:57:10 -0700

Hi Erik,

Thanks for comments. It will be nice to have your proposed texts.
As you know, AUTOCONF WG has long discussion of Link-Local address treatment. 
Due to the special characteristics of ad-hoc links, the uniqueness of link-local is hardly achieved.   
The link characteristics of ad-hoc network is quite different from the fixed link.

http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt

I'm not quite sure how we can handle your comments, because some of comments just reset our 5 yrs achievements. 
I would like to see the comments from AUTOCONF members. 

thanks,
ryuji

On 2010/07/09, at 13:52, Erik Nordmark wrote:

> and the abstract, which limits itself to configuring IP addresses for router interfaces and not for the whole of an ad hoc network.
> 
> I was under the impression that the WG was looking at a document that addressed the scope that is implied by the title.
> 
> I find the more limited scope odd, since we existing routing protocols like IS-IS that can operate (exchange routing information, forward IP packets) without any IP addresses configured on the routers' interfaces. (Even though a router needs some IP addresses to be manageable with SNMP and to be able to send ICMP errors.)
> 
> The implied conclusion that IPv6-link local addresses are undesirable for router's interfaces is even odder, since RIPng and OSPFv3 both require routers to use IPv6 link-local addresses for the routing protocol exchanges.
> 
> The document seems to assume that the uniqueness scope of link-local addresses is limited to a single link, when it is the routability scope which is limited to the link. There is a class of link-local addresses with U=1 (those derived from EUI-64) that are globally unique - but still is not routable outside of the link.
> 
> The result is that the document can easily be construed as discouraging approaches that make a lot of sense, which seems counterproductive.
> An example of such an approach is a routing protocol which uses IEEE MAC addresses as router ids, assigns IPv6 link-local addresses to the router's interfaces and uses that in the routing protocol exchanges, and configures global addresses for use by applications.
> 
> 
> I think the exercise here is to try to correct some minor wording in the recommendations in the document, but even if we succeed in doing so the premises expressed in the introduction and elsewhere will be a bit odd, since they focus on the configuration of router interfaces and not on the addressing model of the Ad Hoc network.
> 
>> OLD:
> With IS-IS one doesn't configure the router id; it is a factory assigned MAC address. Such an approach is perfectly valid for Ad Hoc routing protocols as well.
> 
> Note that a router (as opposed to routing protocol) require IP addresses to be managable and to be able to send ICMP errors. But the above paragraph is trying to derive recommendations from the latter.
> 
> I suggest the wording
> protocol itself; such identifiers could be based on factory assignment or configuration.
> 
> According to RFC 4291 EUI-64-based interface identifiers have global scope when created from a universal token. A result of this is that link-local addresses formed from such interface identifiers have global scope. Hence the "no mechanism" above seems factually incorrect.
> 
> Thus I think section 6.1 needs to differentiate between the global and local scope for the interface identifiers for it to make sense.
> Clearly the application traffic needs to use non-link-local addresses to work across multiple links, but that has nothing to do with what IP addresses are configured on the interfaces of routers as we see from the requirement for RIPng and OSPFv3 to use IPv6 link-locals on router interfaces.
> 
> Instead the issue is that link-local addresses are not useful for applications *other than routing protocols*, and that is the motivation for the subsequent paragraph:
> 
>> OLD:
> That misses the point. It is the motivation for this recommendation which is confused and misleading, and not the conclusion itself. The motivation is that applications (other than routing protocols) most likely desire to communicate across the whole Ad Hoc network, if not across the whole Internet, which makes link-local addresses of limited use.
> 
> But they can still be quite useful as for the purposes of routing protocols, and bootstrapping address autoconfiguration protocols.
> 
> This confusion is related to the odd scope mismatch between the title and the abstract. Clearly we want to be able to autoconfigure non-link-local addresses for applications, but the abstract limits the scope of the document to IP addressed assigned to router interfaces, and there link-local address might be just fine.
> 
> Note that the last sentence in the first paragraph in section 4 is also misleading (I'm assuming that paragraph is about configuring router interfaces and not host interfaces) in saying
> when in fact using link-local address, in particular those based on global scope interface identifiers, might be just fine for router interfaces.
> 
>   Erik

---

From: Ryuji Wakikawa <[email-masked]>
Date: Mon, 19 Jul 2010 22:57:57 -0700

I think if the title is misleading, we should update it.
However, can we change the title at this document stage? Jari?

ryuji

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Jul 2010 11:12:10 +0200

I'd be OK with the slight title alteration proposed by Zach: "Router
Addressing Model in Ad Hoc Networks". I think it would be fine.
Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Jul 2010 11:58:19 +0200

Hi Erik,

On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark <[email-masked]>wrote:

> ...

> addresses as router ids, assigns IPv6 link-local addresses to the router's
> interfaces and uses that in the routing protocol exchanges, and configures
> global addresses for use by applications.
>
>

Using MAC addresses for unique identifier is considered dangerous by many
people, as MAC addresses are not always unique. There were several cases
where an order of several thousands of devices where shipped with the exact
same MAC address, by mistake. Moreover, MAC addresses can be altered almost
at will. This is why relying on MAC addresses for unique identifiers is not
sufficient in my mind. It's merely another way to say: "let other people
worry about our problems". This rarely works reliably.

As to using link local addresses, there are many cases where it is not
appropriate, as discussed over and over in this working group and elsewhere.
If you have any comments on
http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt
 please let us know. The fundamental properties of multi-hop wireless
communications described in that document make it difficult to use
link-local addresses in many cases.

And again, the goal of RFC5889 is not to describe all possible addressing
models for each specific scenario, but rather to describe one specific model
with which we have experience in multi-hop wireless contexts, and which has
proven to work OK. In that respect, I think RFC5889 does the job.

Regards,
Emmanuel

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Jul 2010 16:02:00 +0300

I too would be fine with a title change to "Router Addressing Model in 
Ad Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc Networks"...

Jari

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 21 Jul 2010 15:04:18 +0200

On Wed, Jul 21, 2010 at 3:02 PM, Jari Arkko <[email-masked]> wrote:

> I too would be fine with a title change to "Router Addressing Model in Ad
> Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc Networks"...

I think the latter is a good idea.

Ulrich

---

From: Jari Arkko <[email-masked]>
Date: Wed, 21 Jul 2010 17:40:24 +0300

Erik,

> addressed the scope that is implied by the title.

OK, though I suspect that Section 1 paragraph 3 and Section 6.1 bullet 2 
still says almost everything there is to say about the rest, too. 
Nevertheless, there is a proposal for title change. Perhaps a critical 
issue was not making it clear enough in the document that its not just 
about router addressing, but also just _a_ model, not _the_ model. I 
asked the working group to document one practical model for addressing 
rather than cover all possible options, as their work in trying to do 
the latter had stalled.

> packets) without any IP addresses configured on the routers' 
> interfaces. (Even though a router needs some IP addresses to be 
> manageable with SNMP and to be able to send ICMP errors.)
>

This may have been an issue in the document as approved, but I do not 
think there is an implication left in the text with the proposed changes 
folded in.

More importantly, as the document correctly states there are differences 
in the requirements that routing protocols place on available addresses. 
I think the document makes a very pragmatic model choice in this light.

> addresses is limited to a single link, when it is the routability 
> scope which is limited to the link. There is a class of link-local 
> addresses with U=1 (those derived from EUI-64) that are globally 
> unique - but still is not routable outside of the link.

I agree about the distinction, of course. But I re-read the document 
today but cannot see where the document claims otherwise.

> The result is that the document can easily be construed as 
> discouraging approaches that make a lot of sense, which seems 
> counterproductive.
> An example of such an approach is a routing protocol which uses IEEE 
> MAC addresses as router ids, assigns IPv6 link-local addresses to the 
> router's interfaces and uses that in the routing protocol exchanges, 
> and configures global addresses for use by applications.

Again, I do not believe that the changed document can be construed as 
discouraging.

> I think the exercise here is to try to correct some minor wording in 
> the recommendations in the document, but even if we succeed in doing 
> so the premises expressed in the introduction and elsewhere will be a 
> bit odd, since they focus on the configuration of router interfaces 
> and not on the addressing model of the Ad Hoc network.
>
>> OLD:
> With IS-IS one doesn't configure the router id; it is a factory 
> assigned MAC address. Such an approach is perfectly valid for Ad Hoc 
> routing protocols as well.

Agreed.  I think that case is covered by "configured in some manner", 
however.

> Note that a router (as opposed to routing protocol) require IP 
> addresses to be managable and to be able to send ICMP errors. But the 
> above paragraph is trying to derive recommendations from the latter.
>
> I suggest the wording

We can make this change.

>> routing
> link-local addresses formed from such interface identifiers have 
> global scope. Hence the "no mechanism" above seems factually incorrect.
>

There is a difference between an intent to create addresses with a 
particular scope, and our ability to test that they really are unique. 
The text says "no mechanism to ensure" and I take that it means the 
testing part. This seems correct, though I do agree that it might have 
been confusing.

> Clearly the application traffic needs to use non-link-local addresses 
> to work across multiple links, but that has nothing to do with what IP 
> addresses are configured on the interfaces of routers as we see from 
> the requirement for RIPng and OSPFv3 to use IPv6 link-locals on router 
> interfaces.
>
> applications *other than routing protocols*, and that is the 
> motivation for the subsequent paragraph:

This section talks about the limited utility of link-local addresses. I 
agree that the paragraph above is relevant in an application context.

> across the whole Internet, which makes link-local addresses of limited 

We agree so far.

> protocols, and bootstrapping address autoconfiguration protocols.

And no one is disputing that. However, as stated in the document there 
are routing protocols that _do_ require non-link local addresses. So 
while I agree with your "can be still quite useful" claim I do not see a 
basis for claiming that link local addresses should be the one and only 
form of address configuration for routing protocols, or even that such 
addresses must be available as part of an addressing model.

> scope of the document to IP addressed assigned to router interfaces, 
> and there link-local address might be just fine.

See above.

> Note that the last sentence in the first paragraph in section 4 is 
> also misleading (I'm assuming that paragraph is about configuring 
> router interfaces and not host interfaces) in saying

See above.

Jari

---

From: Teco Boot <[email-masked]>
Date: Wed, 21 Jul 2010 18:15:24 +0200

Op 21 jul 2010, om 16:40 heeft Jari Arkko het volgende geschreven:

> And no one is disputing that. However, as stated in the document there are routing protocols that _do_ require non-link local addresses. So while I agree with your "can be still quite useful" claim I do not see a basis for claiming that link local addresses should be the one and only form of address configuration for routing protocols, or even that such addresses must be available as part of an addressing model.

Some say NHDP / OLSR need non-link local addresses. I don't agree on this. They use link-local destination address and all messages are hop-by-hop forwarded. Source IP Address could (Chris Dearlove) / should (Henning Rogge) be link local. 
Originator Address must be unique in the MANET (OLSR) or two hops (NHDP).
See http://www.ietf.org/mail-archive/web/manet/current/msg11004.html

What routing protocols _do_ require non-link local addresses?
<answer>
  DYMO OrigNode.Address must be non-link local, but DYMO packets 
  to LL-MANET-Routers would use link local source address.
  And of course we need non-link locals for apps.
</answer>

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 21 Jul 2010 18:57:36 +0200

Emmanuel,

Let's solve the duplicate unique MAC address problem. You bring the cards, I'll take the hammer. Then, we (IETF) can stop solving others problems.

DHCP fully relies on a client provided token, which must be unique.
An overwhelming majority of clients use MAC addresses.
I don't say there are no problems, but many of us accept the risk.

Posted before, I dealt with a DAD DOS attack. It is proven that it is broken.
I don't want to accept this risk.
Ideas?

Teco

Op 21 jul 2010, om 11:58 heeft Emmanuel Baccelli het volgende geschreven:

> Hi Erik,
> 
> 
> On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark <[email-masked]> wrote:
> ...
>  
> Using MAC addresses for unique identifier is considered dangerous by many people, as MAC addresses are not always unique. There were several cases where an order of several thousands of devices where shipped with the exact same MAC address, by mistake. Moreover, MAC addresses can be altered almost at will. This is why relying on MAC addresses for unique identifiers is not sufficient in my mind. It's merely another way to say: "let other people worry about our problems". This rarely works reliably.
> 
> As to using link local addresses, there are many cases where it is not appropriate, as discussed over and over in this working group and elsewhere. If you have any comments on http://ietfreport.isoc.org/all-ids/draft-baccelli-multi-hop-wireless-communication-04.txt please let us know. The fundamental properties of multi-hop wireless communications described in that document make it difficult to use link-local addresses in many cases.
> 
> And again, the goal of RFC5889 is not to describe all possible addressing models for each specific scenario, but rather to describe one specific model with which we have experience in multi-hop wireless contexts, and which has proven to work OK. In that respect, I think RFC5889 does the job.
> 
> Regards,
> Emmanuel
> 
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 21 Jul 2010 19:05:39 +0200

Am Mittwoch 21 Juli 2010, 18:57:36 schrieb Teco Boot:
> Emmanuel,
> 
> Let's solve the duplicate unique MAC address problem. You bring the cards,
> I'll take the hammer. Then, we (IETF) can stop solving others problems.
I think the problem would be network hardware without the concept of a layer 2 
address. Just pure broadcast.

Duplicate MACs can be a pain in the ass, but most times they are defective 
hardware (or misconfigured eprom/flash).

> I don't say there are no problems, but many of us accept the risk.
If we have an unique number for each device, autoconfiguration gets nearly 
trivial.
 
> Posted before, I dealt with a DAD DOS attack. It is proven that it is
> broken. I don't want to accept this risk.
> Ideas?
Attacking parts of the IP stack of a node sounds interesting... is there a 
paper about this ?

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 21 Jul 2010 20:02:22 +0200

> address. Just pure broadcast.

Sure, this type of radios exist. But there is no dup unique MAC address problem.
Often, the device has another interface with an unique MAC address. 
But yes, there would be stuff without such. I suggest to leave those out of scope for now. I never saw a business case for supporting these dumb objects right now.

> Attacking parts of the IP stack of a node sounds interesting... is there a 

I didn't say it was IP.
See Section 4.1.3 of RFC 3756 and SeND (RFC3971).
Also mentioned in SLAAC (RFC4862).

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jul 2010 20:32:44 +0200

Side note...

Le 21/07/2010 16:40, Jari Arkko a écrit :
[...]
>> counterproductive. An example of such an approach is a routing
>> protocol which uses IEEE MAC addresses as router ids, assigns IPv6
>> link-local addresses to the router's interfaces and uses that in
>> the routing protocol exchanges, and configures global addresses
>> for use by applications.
>
> Again, I do not believe that the changed document can be construed
> as discouraging.

Again, in my reading the document discourages the use of link-local
addresses.  It is this draft text:

> in general link-local addresses are of limited utility on links with
> undetermined connectivity
>
> [...]
>
> unique across multiple links, hence they cannot be used to reliably
> identify routers (it is often desirable to identify a
>
> [...]
>
> destination addresses to other links
>
> [...]
>
> Note that the use of IPv4 link-local addresses [RFC3927] in this
> context should be discouraged for most applications, as the
> limitations outlined in Section 6.1 for IPv6 link-local addresses
> also concern IPv4 link-local addresses.

There is no place in the draft talking positively about the use of
link-local addresses, despite the numerous agreements on this list that
link-local addresses can and are being used by routing protocols.

This difference between list statements and draft text is huge.

It could be solved by simply saying that "link-local addresses can and
are being used by routing protocols and stateless and stateful address
auto-configuration" and "IPv4 link-local addresses are in widespread use
on e.g. Bluetooth with ActiveSync on numerous small wireless mobile
devices; OSs in widespread use self-configure IPv4 and IPv6 link-local
addresses upon startup, w/o means to forbid this self configuration".

Alex

>
>> I think the exercise here is to try to correct some minor wording
>> in the recommendations in the document, but even if we succeed in
>> doing so the premises expressed in the introduction and elsewhere
>> will be a bit odd, since they focus on the configuration of router
>> interfaces and not on the addressing model of the Ad Hoc network.
>>
>>>  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:
>>>
>>> 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]).
>>> Routing protocols that do not require unique IP addresses within
>>> the routing domain utilize a separate unique identifier within
>>> the routing protocol itself that must also be configured in some
>>> manner.
>>
>> assigned MAC address. Such an approach is perfectly valid for Ad
>> Hoc routing protocols as well.
>
>> addresses to be managable and to be able to send ICMP errors. But
>> the above paragraph is trying to derive recommendations from the
>> latter.
>>
>> I suggest the wording Routing protocols that do not require unique
>> IP addresses within the routing domain utilize a separate unique
>> identifier within the routing protocol itself; such identifiers
>> could be based on factory assignment or configuration.
>
> We can make this change.
>
>>> 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, the following principle allows
>>> for IP autoconfiguration to apply to the widest array of routing
>>> protocols:
>>>
>>> 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 by the routing
>> According to RFC 4291 EUI-64-based interface identifiers have
>> global scope when created from a universal token. A result of this
>> is that link-local addresses formed from such interface identifiers
>> have global scope. Hence the "no mechanism" above seems factually
>> incorrect.
>>
>> Thus I think section 6.1 needs to differentiate between the global
>> and local scope for the interface identifiers for it to make sense.
> particular scope, and our ability to test that they really are
> unique. The text says "no mechanism to ensure" and I take that it
> means the testing part. This seems correct, though I do agree that
> it might have been confusing.
>
>> This paragraph seems like a non seqiteur: o Routers cannot forward
>> any packets with link-local source or destination addresses to
>> other links (as per [RFC4291]) while most of the time, routers
>> need to be able to forward packets to/from different links. Clearly
>> the application traffic needs to use non-link-local addresses to
>>  addresses are configured on the interfaces of routers as we see
>> from the requirement for RIPng and OSPFv3 to use IPv6 link-locals
>> on router interfaces.
>>
> This section talks about the limited utility of link-local
> addresses. I agree that the paragraph above is relevant in an
> application context.
>
>>> OLD: Therefore, autoconfiguration solutions should be encouraged
>>> to primarily focus on configuring IP addresses that are not IPv6
>>> link- local. NEW: Therefore, an autoconfiguration solution which
>>> provides a mechanism for assigning addresses with a wider scope
>>> than IPv6 link-local alone will be more generally useful than one
>>> that does not.
>>
>> That misses the point. It is the motivation for this
>> recommendation which is confused and misleading, and not the
>> conclusion itself. The motivation is that applications (other than
>> routing protocols) most likely desire to communicate across the
>> whole Ad Hoc network, if not across the whole Internet, which makes
>> link-local addresses of limited use.
>
> We agree so far.
>
> And no one is disputing that. However, as stated in the document
> there are routing protocols that _do_ require non-link local
> addresses. So while I agree with your "can be still quite useful"
> claim I do not see a basis for claiming that link local addresses
> should be the one and only form of address configuration for routing
> protocols, or even that such addresses must be available as part of
> an addressing model.
>
>> This confusion is related to the odd scope mismatch between the
>> title and the abstract. Clearly we want to be able to
>> autoconfigure non-link-local addresses for applications, but the
>> abstract limits the scope of the document to IP addressed assigned
>> to router interfaces, and there link-local address might be just
>> fine.
>
> See above.
>
>> router interfaces and not host interfaces) in saying Note that
>> while link-local addresses are assumed to be "on link", the
>> utility of link-local addresses is limited as described in Section
>> 6. when in fact using link-local address, in particular those based
>> on global scope interface identifiers, might be just fine for
>> router interfaces.
>
> See above.
>
> Jari
>
> _______________________________________________ Autoconf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Jul 2010 20:35:07 +0200

Le 21/07/2010 11:58, Emmanuel Baccelli a écrit :
> Hi Erik,
>
>
> On Fri, Jul 9, 2010 at 10:52 PM, Erik Nordmark <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     ...
>
>     MAC addresses as router ids, assigns IPv6 link-local addresses to
>     the router's interfaces and uses that in the routing protocol
>     exchanges, and configures global addresses for use by applications.
>
>
> Using MAC addresses for unique identifier is considered dangerous by
> many people, as MAC addresses are not always unique. There were several
> cases where an order of several thousands of devices where shipped with
> the exact same MAC address, by mistake. Moreover, MAC addresses can be
> altered almost at will. This is why relying on MAC addresses for unique
> identifiers is not sufficient in my mind. It's merely another way to
> say: "let other people worry about our problems". This rarely works
> reliably.
>
> appropriate,

Sure, and there are many cases where they are appropriate.  Why 
mentioning only the negative part?

> as discussed over and over in this working group and
> elsewhere. If you have any comments on

Hmmm... sure, in that particular draft deployment.

In the multi-hop wireless communications system I build the link-local 
addresses are very useful and actually can't work without them.

Alex

>
> And again, the goal of RFC5889 is not to describe all possible
> addressing models for each specific scenario, but rather to describe one
> specific model with which we have experience in multi-hop wireless
> contexts, and which has proven to work OK. In that respect, I
> think RFC5889 does the job.
>
> Regards,
> Emmanuel
>
>
>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 09:47:51 +0100

Alexandru
(But I'm just quoting this for convenience. It's not really specific
to this text.)
> addresses upon startup, w/o means to forbid this self configuration".

This is a very worrying trend. This document is in AUTH48, it's been
accepted by the WG and the IESG. Even the original edits proposed
(especially the third) were beyond what I understand what AUTH48 is
about, which is minor editorial changes. Now we are discussing a
title change and fundamental wording that took years to thrash out
a compromise that can't possibly be overturned in an AUTH48 context.
I think it's time to make either the original first two edits, or no
edits at all, and issue. Anyone who wants to propose an alternative
addressing model can write a new Internet Draft and push it down the
Independent Submission track.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 11:07:11 +0200

Le 22/07/2010 10:47, Dearlove, Christopher (UK) a écrit :
> Alexandru (But I'm just quoting this for convenience. It's not really
> specific to this text.)
>> It could be solved by simply saying that "link-local addresses can
>> and are being used by routing protocols and stateless and stateful
>> address auto-configuration" and "IPv4 link-local addresses are in
>> widespread
> use
>> on e.g. Bluetooth with ActiveSync on numerous small wireless
>> mobile devices; OSs in widespread use self-configure IPv4 and IPv6
>> link-local addresses upon startup, w/o means to forbid this self
>> configuration".
>
> This is a very worrying trend. This document is in AUTH48,

48... 48 hours you mean?

> it's been accepted by the WG and the IESG. Even the original edits
> proposed (especially the third) were beyond what I understand what
> AUTH48 is about, which is minor editorial changes. Now we are
> discussing a title change and fundamental wording that took years to
> thrash out a compromise that can't possibly be overturned in an
> AUTH48 context. I think it's time to make either the original first
> two edits, or no edits at all, and issue. Anyone who wants to propose
> an alternative addressing model can write a new Internet Draft and
> push it down the Independent Submission track.

Sure.

And an RFC is a Request For Comments.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 10:14:09 +0100

AUTH48 is a formal RFC Editor state, as you should know. I
believe that 48 did originally refer to 48 hours, but that's
not the point (though it is a strong hint). The point is what
AUTH48 covers, which is not a technical rewrite. 

What RFC did or does stand for is irrelevant to this.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 10:07
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

48... 48 hours you mean?

Sure.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 22 Jul 2010 11:16:29 +0200

Alex,

>> This is a very worrying trend. This document is in AUTH48,

Please have a look at http://www.rfc-editor.org/pubprocess.html (in
particular at the bottom of the webpage)

>> push it down the Independent Submission track.

I fully agree with Chris. Changing major content of a document in
AUTH48 is not a good idea.

> And an RFC is a Request For Comments.

yes, so? You may also be interested in reading
http://www.ietf.org/rfc/rfc2026.txt

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 11:36:20 +0200

Could you positively say what an AUTH48 _does_ cover?

I understand what it does _not_ cover.

I also understand that 48hours is _not_ the point.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 10:42:00 +0100

See the reference quoted. And you've been an RFC author, you've
been through it.

The text concentrates on editorial stuff (getting references right,
that sort of thing). And my experience was largely about grammar,
punctuation and capitalisation (lots of that one). But as I read
it technical errors would probably be in scope. But rewriting the
recommendations is definitely not if I am any judge at all.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 10:36
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 11:50:05 +0200

> Ad Hoc Networks" or even "*A* Router Addressing Model in Ad Hoc

I disagree.  There are Ad-Hoc Networks which don't use that Addressing 
Model.

The way link-local addresses are formed is specifically to work in 
ad-hoc unplanned networks... or, this draft discourages them.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 11:50:22 +0200

> particular at the bottom of the webpage)

Sure, it says "Upon request or because of temporary unavailability of an 
author, the nominal 48 hours will be extended."

Earlier it says "to look over their document for errors, editorial and 
otherwise."

To me this does not restrict the spread of potential change.

> AUTH48 is not a good idea.

What _is_  a good idea in this situation where the emails on the list 
differ largely from the draft text (with respect to link-local addresses)?

> yes, so?

So there were my comments.

> You may also be interested in reading

Ulrich... ok, sure... "Not all specifications of protocols or services 
for the Internet
    should or will become Internet Standards or BCPs.  Such non-standards
    track specifications are not subject to the rules for Internet
    standardization.  Non-standards track specifications may be published
    directly as "Experimental" or "Informational" RFCs at the discretion
    of the RFC Editor in consultation with the IESG (see section 4.2)."

One could thus write anything non-Internet in an Informational RFC.  In 
that case I wonder why do we still debate it.  There must be some 
reason... I guess it is because of the huge pretensions claimed by the 
title...

Just call it "An Informational Document about Some Addresses" - I could 
live with it that way.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 11:52:22 +0200

There must a good reason why AUTH48 comments are discussed on the WG list.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 22 Jul 2010 11:52:50 +0200

On Jul 22, 2010, at 11:50 , Alexandru Petrescu wrote:

> I disagree.  There are Ad-Hoc Networks which don't use that Addressing Model.
> 
> The way link-local addresses are formed is specifically to work in ad-hoc unplanned networks... or, this draft discourages them.

Alex, I think you still don't capture that we're talking about multi-hop networks here.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 11:56:04 +0200

Le 22/07/2010 11:52, Thomas Heide Clausen a écrit :
>>> I too would be fine with a title change to "Router Addressing
>>> Model in Ad Hoc Networks" or even "*A* Router Addressing Model in
>>> Ad Hoc Networks"...
>>

Thomas - by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop
network using link-local addresses exclusively between MRs.

I hope we capture each other's oppinion ok.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 22 Jul 2010 11:58:26 +0200

> network using link-local addresses exclusively between MRs.

I have no idea what LFN-MR-MR-LFN is. 

This working group is concerned with configuring  MANET routers, specifically the interfaces hereof over which MANET routing protocols operate.

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 13:36:50 +0200

Le 22/07/2010 11:58, Thomas Heide Clausen a écrit :
>>>>> Model in Ad Hoc Networks" or even "*A* Router Addressing
>>>>> Model in Ad Hoc Networks"...
>>>>
>>>> The way link-local addresses are formed is specifically to
>>>> work in ad-hoc unplanned networks... or, this draft
>>>> discourages them.
>>>
>> Thomas - by multi-hop networks I mean: LFN--MR--MR--LFN is a
>> multi-hop network using link-local addresses exclusively between
>> MRs.
>>
>

Are you interested to learn?  The LFN--MR--MR--LFN topology and its
multi-hop network nature is not strange to a co-Chair.

There is a draft and I would like to present it during the next WG
meeting - that could show that I do capture that we talk about multi-hop
networks.

> This working group is concerned with configuring  MANET routers,
> specifically the interfaces hereof over which MANET routing
> protocols operate.

Hmmm... this is something you would wish, right?  Because the current
Charter proposal stays "...independent on operation of any specific
MANET routing protocol"...

I currently agree with that way of using the word MANET in the current
Charter proposal; but I'd suggest to remove "MANET" entirely from
the Charter proposal, use instead agreed words.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 15:21:59 +0100

Alexandru

> To me this does not restrict the spread of potential change.

Clearly it does restrict changes. To of errors.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 16:28:54 +0200

> Clearly it does restrict changes. To of errors.

It says "editorial and otherwise".  It does not say "restrict changes to
of errors".

"Otherwise" means other than editorial, in my reading.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 15:29:22 +0100

Alexandru
> by multi-hop networks I mean: LFN--MR--MR--LFN is a multi-hop

Right this moment, I can't expand LFN (leaf node?). But no matter,
I assume it's a non-routing endpoint.

Now consider the network:

LFN - MR - MR - MR - MR - MR - LFN

That's a multi-hop network. Add more MRs if you like.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 15:30:27 +0100

Errors otherwise than editorial, yes. But not changes otherwise
than errors.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 15:29
To: Dearlove, Christopher (UK)
Cc: Ulrich Herberg; [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 17:05:27 +0200

> I assume it's a non-routing endpoint.

Right, LFN is a "Local Fixed Node", non-routing endpoint.

> Now

So you agree that LFN--MR--MR--LFN _is_ a multi-hop network?

> consider the network:
> That's a multi-hop network.

Yes, that too is a multi-hop network, I agree.

Between each MR only link-local addresses are used.

What do you think?

Alex

> Add more MRs if you like.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 17:07:48 +0200

Le 22/07/2010 16:30, Dearlove, Christopher (UK) a écrit :
> Errors otherwise than editorial, yes. But not changes otherwise than
> errors.

Discouraging link-local addresses is an error other than editorial.

It is an error compared to the reality of existing routing protocols.

The presence of the discouraging text is an error compared to the
presence of encouraging emails on this WG list.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 17:10:01 +0200

Le 22/07/2010 13:36, Alexandru Petrescu a écrit :
>>>>>> I too would be fine with a title change to "Router
>>>>>> Addressing Model in Ad Hoc Networks" or even "*A* Router
>>>>>> Addressing Model in Ad Hoc Networks"...
>>>>>
> meeting - that could show that I do capture that we talk about
> multi-hop networks.

I have been asked privately about the draft in question - here it is:

http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00

    "Router Advertisements for Routing between Moving Networks"

I believe it adapted to AUTOCONF WG discussion as well, but not sure
whether Chairs accept that I present it.

I am scheduled to present it in MEXT WG too, Monday, 16h15
http://www.ietf.org/proceedings/78/agenda/mext.txt

Alex
> I currently agree with that way of using the word MANET in the
> current Charter proposal; but I'd suggest to remove "MANET" entirely
> from the Charter proposal, use instead agreed words.
>
> Alex
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 22 Jul 2010 16:41:19 +0100

And then those link local addresses are visible beyond their
local link. For some that is a problem. For others not.

All of which is irrelevant to the matter in the subject line,
where the decision is long (though longer would have been
better) made. Re-hashing the last N years debate gets no one
anywhere.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 16:05
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

What do you think?

Alex

---

From: Teco Boot <[email-masked]>
Date: Thu, 22 Jul 2010 20:05:29 +0200

> http://www.ietf.org/proceedings/78/agenda/mext.txt

Isn't this draft about routing?
So I doubt on relation with Autoconf.

If it described an interesting addressing model for MANETs, I support a small slot for a presentation.
But after a quick look, I didn't see such.

I'm opposed to single prefix sharing on multiple mobile networks (the 2001:00xx/24 example).
I guess it is a flaw. 

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 21:15:30 +0200

Chris - allow me to Cc the list, thanks.

A number of messages on the email list (at least 4 persons) said that
link-local addresses could be used and they said they are not
necessarily against them.

Being against me is a typical behavior and I'm fine with it.  But if one
checks the emails one sees that personal opinions are tolerant with
respect to link-local addresses, and not necessarily discourages them.

It is the stubordness to update the draft which is not normal - a plain
error.

Alex

Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit :
> No, it's not an error. It's a design decision. One you disagree
> with, but broad consensus was against you. That does not make it an
> error.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 21:19:09 +0200

Le 22/07/2010 17:41, Dearlove, Christopher (UK) a écrit :
> And then those link local addresses are visible beyond their local
> link.

No, my point is not understood.  The link-local addresses are not
visible beyond their local link.

When the MRs in LFN--MR--MR--MR--LFN use their link-local addresses
these are not visible beyond their respective local link.

> For some that is a problem. For others not.

If they were visible - yes, it would have been a problem, but they are not.

> All of which is irrelevant to the matter in the subject line, where
> the decision is long (though longer would have been better) made.
> Re-hashing the last N years debate gets no one anywhere.

How about if during the last N years my message could not get read?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jul 2010 21:29:20 +0200

Le 22/07/2010 20:05, Teco Boot a écrit :
>>> There is a draft and I would like to present it during the next
>>> WG meeting - that could show that I do capture that we talk
>>> about multi-hop networks.
>>
>>
>> I believe it adapted to AUTOCONF WG discussion as well, but not
>> sure whether Chairs accept that I present it.
>>

YEs... depends how one interprets 'routing'.  The prefixes received in
the RA are installed in the routing table - that sounds as routing. 
However, the use of link-local addresses in order to exchange RAs is 
less about routing and more about addressing model.

> So I doubt on relation with Autoconf.

I have a similar doubt too... however the RA-based routing uses
link-local addresses, and the deployment is a typical multi-hop mobile
wireless network.  Why would AUTOCONF addressing model forbid them?

> If it described an interesting addressing model for MANETs, I support
> a small slot for a presentation. But after a quick look, I didn't see
> such.

Well, this figure from the draft depicts an addressing model:
>                            egress|              |egress
>              ----     ----    ----              ----     ----    ----
>             | LFN|   |LFN |  | MR |            | MR |   |LFN |  |LFN |
>              ----     ----    ----              ----     ----    ----
>                |        | ingress|              |ingress   |      |
>               ---------------------             ---------------------
>                    2001:1::/24                       2001:2::/24

In addition, this text from the same draft needs link-local addresses on 
the egress interfaces:
>    o  When receiving the special RA from another MR, a MR parses the
>       packet for the link-local address of the sending MR, for the MNP
>       sent by that MR and for the lifetime.  It then installs the
>       corresponding entry into the data structure mentioned earlier.

These messages from the draft need to be exchanged by using link-local 
addresses:
>                  MR1                MR2                MR3
>                      |                  |                  |
>                      | MLD REPORT (LL1) |                  |
>                      |----------------->|----------------->|multicast
>                      |                  |MLD REPORT (LL3)  |
>                      |<-----------------|<-----------------|
>                      |               MLD|REPORT (LL2)      |
>                      |<-----------------|----------------->|
>                      |                  |                  |
>                      |    Special RA    |                  |
>                      |----------------->|----------------->|
>                      |   (MNP1-LL1)     |                  |
>                      |                  |    Special RA    |
>                      |<-----------------|<-----------------|
>                      |                  |   (MNP3-LL3)     |
>                      |                  |                  |
>                      |           Special|RA                |
>                      |<-----------------|----------------->|

[...]

> I'm opposed to single prefix sharing on multiple mobile networks
> (the 2001:00xx/24 example). I guess it is a flaw.

WEll, if it were a single prefix shared then yes, it would have been a
flaw, I agree with you. But there actually two different prefixes in
that figure: 2001:1::/24 and 2001:2::/24.

Thanks for the remark, I am going to scan the draft make sure that there
is no single prefix sharing on multiple mobile networks.

I can say that in my implementation there is no single prefix sharing
across multiple mobile networks.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Fri, 23 Jul 2010 07:23:53 +0200

> these are not visible beyond their respective local link.

You just have shown that you don't understand what a wireless MANET (with 
multihop links, without most people would not consider it a MANET) is.

if each of the MRs use a wireless interface, the linklocals WILL BE VISIBLE 
outside their direct link. There is no way to prevent this. Because multiple 
links share interfaces in a non-transitive manner (see 
http://en.wikipedia.org/wiki/Transitive_relation).

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 09:43:02 +0200

Le 23/07/2010 07:23, Henning Rogge a écrit :
>>> local link.
>> When the MRs in LFN--MR--MR--MR--LFN use their link-local
>> addresses these are not visible beyond their respective local
>> link.
>
> You just have shown that you don't understand what a wireless MANET
> (with multihop links, without most people would not consider it a
> MANET) is.

Ulrich, I do make efforts to understand what you understand.  PArt of
this effort is to refrain the temptation of claiming you don't 
understand what I don't understand.

> if each of the MRs use a wireless interface, the linklocals WILL BE
> VISIBLE outside their direct link.

Well, the link local addresses will not be visible outside their direct
link, because the different links are on different ESSIDs and moreover
on different channels.  Using wireshark on IP packets on these different
links shows that the link local addressess are not visible from one link
to another.

When you say visible - what do you mean?  I mean "not visible" to the IP
stack.

> There is no way to prevent this.

YEs there is - use different ESSIDs and, for more insurance, use
different channels and different keys.  That is for WiFi.  For other
technologies (3G+, LTE, Bluetooth) there are other link layer means such
as pdp context and more.

> Because multiple links share interfaces in a non-transitive manner

Well yes, at link layer level.  But link layers have their protocols
which help build understandable links to the IP stack.

> (see http://en.wikipedia.org/wiki/Transitive_relation).

Uh?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jul 2010 09:47:28 +0200

On Jul 23, 2010, at 09:43 , Alexandru Petrescu wrote:

> this effort is to refrain the temptation of claiming you don't understand what I don't understand.
> 
> on different channels.

That is the crux of your misunderstanding. They may, in your case, be -- in most MANET cases, they're not.

Thomas

>  Using wireshark on IP packets on these different

---

From: Henning Rogge <[email-masked]>
Date: Fri, 23 Jul 2010 09:51:45 +0200

> links shows that the link local addressess are not visible from one link
This would only work with preplanned links, because otherwise you would have 
trouble to do neighborhood detection. How do you detect new nodes coming into 
range if they cannot announce their presence with a broadcast, because they 
got no unique ESSID to their neighbors ?

MANET routing protocols are specially designed for the case of unplanned 
networks. You have a single shared medium which the routing protocol use for 
it's work, to do neighborhood/link detection.
If you push this down to link layer, you just move the whole problem down one 
layer, because you need unique addresses on the link layer to do neighborhood 
detection and link establishment.

If you already have a unique link-layer address, just use it to generate a 
unique linklocal-IP.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 23 Jul 2010 09:53:20 +0200

Alex,

> this effort is to refrain the temptation of claiming you don't understand

It was Henning, who said that, not me :-) (even though in this particular
example, I agree with him).

> links shows that the link local addressess are not visible from one link

Yes, but this is not the general case of a MANET. This is your very
particular lab setting, which will only work in well-known, predefined
constraints.

> technologies (3G+, LTE, Bluetooth) there are other link layer means such

Then tell me, how Henning should manage the FunkFeuer Netzwerk. Using a
different channel and ESSID for every link? And even worse, consider a
setting where routers actually move in an unknown patterns (i.e. are
"mobile"); how would you update ESSIDs and channels?

> which help build understandable links to the IP stack.

Yes, but then you are wrong in the MANET WG, because we are not talking
about L2 meshes (like 802.11s). We are talking about multihop communication
on L3.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:00:41 +0200

Le 23/07/2010 09:47, Thomas Heide Clausen a écrit :
>>>> No, my point is not understood.  The link-local addresses are
>>>> not visible beyond their local link.
>>>>
>>> You just have shown that you don't understand what a wireless
>>> MANET (with multihop links, without most people would not
>>> consider it a MANET) is.
>>
>> Ulrich, I do make efforts to understand what you understand.  PArt
>>  of this effort is to refrain the temptation of claiming you don't
>>> if each of the MRs use a wireless interface, the linklocals WILL
>>>  BE VISIBLE outside their direct link.
>>
>> Well, the link local addresses will not be visible outside their
>> direct link, because the different links are on different ESSIDs
>> and moreover on different channels.
>

Thomas - help me remove this crux.

Could we make an AUTOCONF non-MANET case where the link local addresses
are not visible across different wireless links.

Otherwise, could we be stating in the Charter that AUTOCONF deals _only_
with MANET cases where link local addresses are visible in all radio
ranges, links undefined, no WiFi ESSID nor similar.  Which by your
definition is 'most MANET cases'.  You mentioned it several times - it
deserves being in the Charter.

Both ways would help me a lot: in the first I stay in the group, present
at meeting.  In the second I go away.

Alex

>
> Thomas
>
>
>> Using wireshark on IP packets on these different links shows that
>> the link local addressess are not visible from one link to
>> another.
>>
>> When you say visible - what do you mean?  I mean "not visible" to
>> the IP stack.
>>
>> different channels and different keys.  That is for WiFi.  For
>> other technologies (3G+, LTE, Bluetooth) there are other link layer
>> means such as pdp context and more.
>>
>> Well yes, at link layer level.  But link layers have their
>> protocols which help build understandable links to the IP stack.
>>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 23 Jul 2010 10:05:22 +0200

> at meeting.  In the second I go away.
Quote from the charter of the autoconf WG:

The main purpose of the AUTOCONF WG is to describe the addressing model
for --ad hoc networks-- and how nodes in these networks configure their
addresses.

"ad hoc networks" is the ANET part of MANET...

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:11:26 +0200

Le 23/07/2010 09:51, Henning Rogge a écrit :
>> and moreover on different channels.  Using wireshark on IP packets
>> on these different links shows that the link local addressess are
>> not visible from one link to another.
>
> This would only work with preplanned links,

Most deployments have a high degree of planning.

> because otherwise you would have trouble to do neighborhood
> detection. How do you detect new nodes coming into range if they
> cannot announce their presence with a broadcast, because they got no
> unique ESSID to their neighbors ?

Well good question - and I have tried.  The difficult thing is the first
detection - the "wifi scan" phase; once the drivers have their data set
up then re-detection is very fast, in the order of tens of milliseconds.
  We could use that to signal between two approaching vehicles.

More specifically, on WiFi, a beacon is sent periodically, but there are
also periodic requests replied with a beacon.  These help a lot to
detect presence of a neighbor previously learned, and fast.

> MANET routing protocols are specially designed for the case of
> unplanned networks. You have a single shared medium which the routing
> protocol use for it's work, to do neighborhood/link detection.

Well very good.  Is there a case where wireless multi-hop networks are
possible _without_ MANET routing protocols?  I believe yes, and I
prototyped and demo.

Besides, there exist deployments where even though the MRs are mobile
they stay relatively fixed with respect to each other, in some very
simple topology: truck convoy, wagons in a train, etc.  These things
stay formed for long hours and reform right after.  These things don't
need the power of MANET routing protocols because there are never loops
formed at link layer, the topology is really simple.

> If you push this down to link layer, you just move the whole problem
> down one layer, because you need unique addresses on the link layer
> to do neighborhood detection and link establishment.

WEll yes... I tend to agree.

However, one would avoid to bring existing link layer mechanisms up to
the IP stack too.  These link layer mechanisms are there and work very
well in their domain.

The IP stack is not fast enough on the CPU to work at vehicular speeds,
interruptable by some GUI or heavy TCP.

The link layer driver executing on a dedicated chipset is much more
reliable for these kinds of movements.

> If you already have a unique link-layer address, just use it to
> generate a unique linklocal-IP.

Hmmm... right, that's how link local addresses are generated.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jul 2010 10:12:17 +0200

> are not visible across different wireless links.

No, I don't see how we could make a valid case like that. 

In part, because [autoconf] targets MANETs, trying to make a "non-MANET case" would be quite out of scope.

> definition is 'most MANET cases'.

The reference to 2501 should make it clear that we were talking about MANETs, and so should be familiar with what that entails -- which is (among other things) that the above "link" characteristics are true (and I just see Henning chipped in, and want to +1 to his remark as well). But, I would guess that if adding the keyword "MANET" to the charter is what this discussion is about, then that can be done too.

Thomas

> You mentioned it several times - it
> deserves being in the Charter. Both ways would help me a lot: in the first I stay in the group, present

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Jul 2010 10:15:33 +0200

> Most deployments have a high degree of planning.

Then, they're (by definition) not ad-hoc networks.

> possible _without_ MANET routing protocols?  I believe yes, and I

Very well, but then that's not a MANET.

> formed at link layer, the topology is really simple.

Very well, but then that's not a MANET.

Alex, can we agree that things that are not MANETs tautologically are not MANETs?

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:23:00 +0200

Le 23/07/2010 09:53, Ulrich Herberg a écrit :
> Alex,
>
> On Fri, Jul 23, 2010 at 9:43 AM, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
>  wrote:
>
> It was Henning, who said that, not me :-) (even though in this
> particular example, I agree with him).

I made a mistake, I am sorry Henning and Ulrich.  I actually know you
Ulrich, not Henning.  I need a mental image about who I talk to.

> direct link, because the different links are on different ESSIDs and
>  moreover on different channels.  Using wireshark on IP packets on
> these different links shows that the link local addressess are not
> visible from one link to another.
>
>
> particular lab setting, which will only work in well-known,
> predefined constraints.

WEll I disagree.  WiFi is designed to use ESSIDs meaningfully, it is in
the manual.  WiFi deployments use ESSIDs.  I'd say that one's refusal to
use ESSIDs is refusal to abide to the manual, build broken things and
then blame IP.

> When you say visible - what do you mean?  I mean "not visible" to the
> IP stack.
>
>
> technologies (3G+, LTE, Bluetooth) there are other link layer means
> such as pdp context and more.
>
>
> Then tell me, how Henning should manage the FunkFeuer Netzwerk.

How much would Henning pay me to build a consistent plan for FunkFeuer
Netzwerk?  Then I'll say.

> Using a different channel and ESSID for every link?

Yes, different ESSID and channel for links in proximity where there may
be a risk of visibility of link layer addresses.  It's like the map
colouring problem - there are solutions.  Internet too has different IP
subnets on different links.

> And even worse, consider a setting where routers actually move in an
>  unknown patterns (i.e. are "mobile"); how would you update ESSIDs
> and channels?

Does such a setting really exist (pure random movements like  in
Brownian)?  Example?

For some wireless deployments studies have been performed to identify
patterns: vehicular, urban citizen, more.  For each there are possible
plans on which WiFi would work good.

Even the most arbitrary movements like in a battlefield have a very high
degree of planning - the command and control is very centralized.

> Yes, but then you are wrong in the MANET WG, because we are not
> talking about L2 meshes (like 802.11s). We are talking about multihop
> communication on L3.

I am in AUTOCONF not in MANET, right?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:40:12 +0200

Le 23/07/2010 10:05, Henning Rogge a écrit :
>> Could we make an AUTOCONF non-MANET case where the link local
>> addresses are not visible across different wireless links.
>>
>> Otherwise, could we be stating in the Charter that AUTOCONF deals
>> _only_ with MANET cases where link local addresses are visible in
>> all radio ranges, links undefined, no WiFi ESSID nor similar.
>> Which by your definition is 'most MANET cases'.  You mentioned it
>> several times - it deserves being in the Charter.
>>
>> Both ways would help me a lot: in the first I stay in the group,
>> present at meeting.  In the second I go away.
>
> The main purpose of the AUTOCONF WG is to describe the addressing
> model for --ad hoc networks-- and how nodes in these networks
> configure their addresses.
>

To me "specs for ad-hoc networks" is a contradiction in itself.

One would genuinely use the "ad-hoc" term after fact - I couldn't say
"I will build an ad-hoc network" but rather
"I have built an ad-hoc network".

A few famous ad-hoc happenings were actually planned.

And yes - you will quote me wikipedia about what A is in ANET is in MANET.

And yes - I will quote you wikipedia saying how "vehicular ad-hoc
networks" is about vehicles in constant close range, and how MANET is
probably more University Research and VANET is probably more promissing.

For some reason, I like that WiFi don't call themselves "ad-hoc" yet 
it's in widespread use.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:42:48 +0100

If you are using the addresses even in NHDP, or even in a
single neighbour cut-done NHDP that has link bidirectionality
checking then they are so visible. And the point of this work
is to create addresses that are so usable.

Whether the visibility matters can be argued. That the visibility
occurs is not the case.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 20:19
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:44:09 +0100

Sorry, hit return to quickly. My second paragraph should have
said 

occurs cannot.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 20:19
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:45:02 +0100

Not in AUTH48. You are talking about earlier stages of the process.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 22 July 2010 20:16
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:49:44 +0100

> Well, the link local addresses will not be visible outside their
direct
> link, because the different links are on different ESSIDs and moreover

Not in our networks. Furthermore "ESSID" is specific to a particular
lower layer technology and we are not constraining ourselves to it,
as has been said many times. And even then this doesn't ensure lack
of visibility.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:52:16 +0200

Le 23/07/2010 10:12, Thomas Heide Clausen a écrit :
>>>>>>> And then those link local addresses are visible beyond
>>>>>>> their local link.
>>>>>>
>>>>>> No, my point is not understood.  The link-local addresses
>>>>>> are not visible beyond their local link.
>>>>>>
>>>>>> addresses these are not visible beyond their respective
>>>>>> local link.
>>>>>
>>>>> You just have shown that you don't understand what a
>>>>> wireless MANET (with multihop links, without most people
>>>>> would not consider it a MANET) is.
>>>>
>>>> Ulrich, I do make efforts to understand what you understand.
>>>> PArt of this effort is to refrain the temptation of claiming
>>>> you don't understand what I don't understand.
>>>>
>>>>> if each of the MRs use a wireless interface, the linklocals
>>>>> WILL BE VISIBLE outside their direct link.
>>>>
>>>> Well, the link local addresses will not be visible outside
>>>> their direct link, because the different links are on different
>>>> ESSIDs and moreover on different channels.
>>>
>>> That is the crux of your misunderstanding. They may, in your
>>> case, be -- in most MANET cases, they're not.
>>
> In part, because [autoconf] targets MANETs, trying to make a
> "non-MANET case" would be quite out of scope.
>
>> all radio ranges, links undefined, no WiFi ESSID nor similar. Which
>> by your definition is 'most MANET cases'.
>
> The reference to 2501 should make it clear that we were talking about
> MANETs, and so should be familiar with what that entails -- which is
> (among other things) that the above "link" characteristics are true
> (and I just see Henning chipped in, and want to +1 to his remark as
> well). But, I would guess that if adding the keyword "MANET" to the
> charter is what this discussion is about, then that can be done too.

Thomas - FWIW, you seem to it's easy for AUTOCONF Charter to be MANET 
RFC2501 only.

If so - add "MANET" in the Charter, rfc2501, make that be the exclusive 
AUTOCONF cases and I go away.

I will not call my deployments MANET.

Alex

>
> Thomas
>
>> You mentioned it several times - it deserves being in the Charter.
>>>> Using wireshark on IP packets on these different links shows
>>>> that the link local addressess are not visible from one link
>>>> to another.
>>>>
>>>> When you say visible - what do you mean?  I mean "not visible"
>>>> to the IP stack.
>>>>
>>>> YEs there is - use different ESSIDs and, for more insurance,
>>>> use different channels and different keys.  That is for WiFi.
>>>> For other technologies (3G+, LTE, Bluetooth) there are other
>>>> link layer means such as pdp context and more.
>>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:53:19 +0200

> Alex, can we agree that things that are not MANETs tautologically are not MANETs?

Sure!

Make the Charter tautologically MANET and then we're all clear.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:57:36 +0200

Le 23/07/2010 10:42, Dearlove, Christopher (UK) a écrit :
> checking then they are so visible.

Hmmm... I have just tried two WiFi networks nearby (ad-hoc more, ha!) 
with different ESSIDs and channels and the link-locally addressed 
messages from one to another are invisible on Wireshark (from one link 
to another).

Besides, in some cases even in Access Point mode the messages from STA 
to BS are invisible between STAs on same ESSID, but that's particular.

Any other experience enlightening.

Alex

And the point of this work

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 10:58:25 +0200

> Whether the visibility matters can be argued. That the visibility

Well - you won't argue and I will, my IP testbed contradicts your argument.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 23 Jul 2010 09:59:29 +0100

That's because you weren't running a MANET. 

I'm going to stop spending time on this discussion now.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 23 July 2010 09:58
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; [email-masked]
Subject: Re: [Autoconf] RFC 5889 (Was: Call for comments to a new AUTOCONF charter proposal)

                    *** WARNING ***

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 11:01:09 +0200

> Not in AUTH48. You are talking about earlier stages of the process.

Someone on this list redirected me to that web page about which I talk, 
at the bottom of that page.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 11:01:35 +0200

> I'm going to stop spending time on this discussion now.

Well - I claim to run IP multi-hop wireless mobile networks without 
running MANET routing protocols.

I suggest to stop calling everything a MANET.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 11:06:12 +0200

Le 23/07/2010 10:49, Dearlove, Christopher (UK) a écrit :
>> link, because the different links are on different ESSIDs and
>> moreover on different channels.
>
> as has been said many times.

Tell me the name of your particular lower layer technology and I will
tell you the equivalent of ESSID.  This equivalence exists in other
than WiFi techs: pdp context for 3G, picocell ID for Bluetooth, etc.

I would be surprised the unknown link layer does not have such means of 
link separation...

> And even then this doesn't ensure lack of visibility.

Link layers have this typical functionality.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Fri, 23 Jul 2010 12:43:23 +0200

> use ESSIDs is refusal to abide to the manual, build broken things and
The typical usage for an 802.11 network in adhoc mode would be to set ALL 
nodes to the same ESSID. If you don't do so, you have trouble communicating 
with a node which you thought you would have no connection with (and did not 
reserved an ESSID).

Reserving an ESSID for each link of the network will waste a huge amount of 
airtime with beacons. In some cases it might be even better to switch of 
beacons off completely (ahdemo mode).

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Fri, 23 Jul 2010 12:54:04 +0200

> degree of planning - the command and control is very centralized.

Sorry, you disqualified yourself here.

Teco.

---

From: Teco Boot <[email-masked]>
Date: Fri, 23 Jul 2010 12:56:42 +0200

> detect presence of a neighbor previously learned, and fast.

Far out of context of this WG. But here a correction:
Only a subset of 802.11 nodes in a service set send beacons.
This is APs, or elected nodes in IBSS.
A beacon advertises a service set, not a station.

Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 14:08:07 +0200

Le 23/07/2010 12:43, Henning Rogge a écrit :
> nodes to the same ESSID.

All node in close range - yes.  Nodes further apart could form a 
different subnet.

 > If you don't do so, you have trouble communicating
> airtime with beacons.

Well - depends.  In a 50meter area - yes, a single ESSID is good.  It's 
the same area where a subnet can form and have a single ESSID and where 
link-local addresses are visible from each other.

That 50meter is a hard limit specified.

> In some cases it might be even better to switch of

Yes, in some cases yes.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Jul 2010 14:10:49 +0200

> Sorry, you disqualified yourself here.

? as if I tried to qualify myself to some form of competition??

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 04:49:29 -0700

> rather than cover all possible options, as their work in trying to do

OK

> think there is an implication left in the text with the proposed changes

Apart from the issue below related to link-locals that are globally unique.

> today but cannot see where the document claims otherwise.

It does say
and later

If we strike out the first cited paragraph, and clarify the second cited 
one to say:
    o  In general there is no mechanism to ensure that IPv6 link-local
       addresses are unique across multiple links, however link-local
       addresses using an IID that is of the modified EUI-64 form is
       globally unique. Thus if link-local addresses are used to reliably
       identify routers then they must be of the modified EUI-64 form.

> Again, I do not believe that the changed document can be construed as

I disagree. My proposed edit above would take care of the issue though.

>> protocol itself; such identifiers could be based on factory assignment

OK

> testing part. This seems correct, though I do agree that it might have

Which mechanism do we have to test that a global IPv6 address is in fact 
globally unique? I certainly don't know of one.

We rely on assumptions that the IPv6 prefixes are uniquely delegated by 
the IANA, RIRs, site subnet number allocating admin, etc down to each 
host. For the EUI-64 we rely on the assumption that the IEEE RAC and the 
vendors uniquely allocate EUI-64s. In neither case do we have a test.

> addresses must be available as part of an addressing model.

As I said, I have no issue with the final recommendation that
    Therefore, autoconfiguration solutions should be encouraged to
    primarily focus on configuring IP addresses that are not IPv6 link-
    local.

But the text that makes that argument is fundamentally confused about 
the uniqueness issues around link-locals, and also tries to argue things 
from a router perspective when the main argument is that applications 
want something wider than link locals.

I suggest splitting this item into two.
FROM
    o  Routers cannot forward any packets with link-local source or
       destination addresses to other links (as per [RFC4291]) while most
       of the time, routers need to be able to forward packets to/from
       different links.
TO
    o  Routers often need to be reachable at a global address for
       management purposes.

    o  Routers cannot forward any packets with link-local source or
       destination addresses to other links (as per [RFC4291]) while most
       of the time, applications assume that routers can forward packets
       to/from different links.

If you don't want to add the "management" bullet that is fine with me. 
But the second bullet should be about applications.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 05:05:09 -0700

I talked to Jari about this earlier in the week, and in the interest of 
trying to close this issue I've gathered together the earlier suggested 
changes, added the suggested title change, and included the edits I 
suggested a few minutes ago.

Note that I'm not particularly wedded to the title change.

    Erik

Change the title
FROM
                  IP Addressing Model in Ad Hoc Networks
TO
                  A Router Addressing Model in Ad Hoc Networks

In section 4
REMOVE

In section 5:
OLD:

In Section 6.1:
OLD:

OLD:

---

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 05:07:10 -0700

[I lost one of the suggested edits. This is the complete list.]

    Erik

Change the title
FROM

In section 4
REMOVE

In section 5:
OLD:

In Section 6.1:
OLD:

In section 6.1
FROM

Also in section 6.1
OLD:

---

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 Jul 2010 13:39:32 +0100

>     identify routers then they must be of the modified EUI-64 form.

That's a change in substance from something being discouraged (see the
following OLD quote) to telling you how to do that very something.

>   be more generally useful than one that does not.

That's more than an AUTH-48 error correction, it's a substantial change
in the document's intent. Or so it appears to me.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Jul 2010 05:44:05 -0700

> following OLD quote) to telling you how to do that very something.

Your observation is correct.

However, the recommendation of the draft doesn't change as a result of 
this. The arguments leading up to the recommendation were flawed IMHO, 
but the recommendation is fine.

> in the document's intent. Or so it appears to me.

FWIW I didn't suggest that change; it might have been Jari.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 30 Jul 2010 01:12:41 -0700

Please double-check this, but I think it has all the list of changes 
that Jari said verbally.

    Erik

----

Change the title
FROM

In section 5:
OLD:

In Section 6.1:
OLD:
     addresses using an IID that are of the modified EUI-64 form are

---

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 30 Jul 2010 10:19:30 +0100

I was trying to work out if this left the link local address references
coherent or not. These are, I believe, all the paragraphs that discuss
them. I think the first is irrelevant to this discussion, but I've
included it for completeness.

OLD:

   Note that routers may ultimately need additional IP prefixes for the
   diverse applications that could run directly on the routers
   themselves, or for assignment to attached hosts or networks.  For
   IPv6, these addresses may be global [RFC3587], Unique-Local [RFC4193]
   or Link-Local [RFC4291].  For IPv4, the addresses may be global
   (i.e., public) or private [RFC1918].  In general, global scope is
   desired over local scope, though it is understood that this may not
   always be achievable via automatic configuration mechanisms.  In this
   document however, automatic configuration of the prefixes used for
   general applications is considered as a problem that is separable
   from that of automatic configuration of addresses and prefixes
   necessary for routing protocols to function.  This document thus
   focuses on the latter: the type of IP address and subnet mask
   configuration necessary for routing protocols and data packet
   forwarding to function.

OLD:

NOTE: The next four paragraphs (all but the last) are consecutive.

OLD:

   Note that while an IPv6 link-local address is assigned to each
   interface as per [RFC4291], in general link-local addresses are of
   limited utility on links with undetermined connectivity, as
   connectivity to neighbors may be constantly changing.  The known
   limitations are:

NEW:

OLD:

   Note that the use of IPv4 link-local addresses [RFC3927] in this
   context should be discouraged for most applications, as the
   limitations outlined in Section 6.1 for IPv6 link-local addresses
   also concern IPv4 link-local addresses.  These limitations are
   further exacerbated by the smaller pool of IPv4 link-local addresses
   to choose from and thus increased reliance on Duplicate Address
   Detection (DAD).

The text before the bullet points indicates that they are about
"The known weaknesses are". The recommendation "Thus if link-local
addresses are used to reliably identify routers then they must be of
the modified EUI-64 form." doesn't really fit that, and also is a bad
fit with the primary focus referred to after the bullet points. What is
appropriate to say, that EUI-64 addresses are globally unique is said in
the previous sentence. I think the document would be more internally
consistent, and not adding a change in recommendations, if that sentence
were deleted from the new paragraph, which would be left as:

NEW:

      globally unique.

(Personally, I'd modify that a little further, to:

   o  In general there is no mechanism to ensure that IPv6 link-local
      addresses are unique across multiple links, however link-local
      addresses using an IID that are of the modified EUI-64 form
      ahould be globally unique.

but this is not the point of this email.)