Subject: Re: [Autoconf] updated MANET addressing model draft

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 9 Oct 2009 08:17:03 +0200

Emmanuel, Mark, all,

On Sep 29, 2009, at 5:42 PM, Emmanuel Baccelli wrote:

> Hi all,
>
> Please do let us know your feedback on the updated doc http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt
>
> Silence may be interpreted as violent agreement with its content ;)

Uhh, that's a threat. I wouldn't want to be taken as being silently  
agreeing (or disagreeing) with anything.

Speaking without any hats (specifically, I do not speak as chair in  
this email), and simply as someone building MANETs, hereby my comments  
to this document.

Overall:
=======

	I think that the document is in a decent shape and reflects the WG  
discussions
	and the issues that have been brought up thus far. I would therefore be
	supportive (as WG participant) of accepting this document as WG  
document.

	Also, I have some detailed comments, which I would be happy to see  
addressed
	(but whose address would not be a prerequisite for my support of this  
document as
	WG document).

Details:
========

	o	The title of the document contains "Ad Hoc Networks", but nowhere  
does it say
		"Ad Hoc Networks" inside the document. This is rather odd. I would  
suggest that
		it be said somewhere (e.g. in the applicability statement or  
introduction?) that:
		
		+	an "Ad Hoc Network" is a typical example of a network with
			"undetermined connectivity"; where

		+	MANET routing protocols have as their raison d'etre to "determine
			network-wide connectivity"; but that to do so

		+	MANET protocols require the interfaces to be configured with IP  
addresses

		The latter of these is already said in the Introduction. I would  
suggest that saying
		the two others would make it clear what this document is about. Note  
that the second
		point above is critical in that the goal is not to "hide" (or "fake  
out", in Townsley-
		terminology) the undetermined connectivity properties, but rather  
that there are routing
		protocols in existence in the IETF that are conceived explicitly to  
handle these
		properties.

	o	The introduction is a little murky with respect to links/topology/ 
assumptions/
		configurations. In my world-view:

		+	the network topology *is* -- is an undisputed fact.
	
		+	we may know something about this, or we may not. I.e. given a  
network, we
			may make use this knowledge to make assumptions about the  
properties of
			that network.

		+	those assumptions we use to *reflect* the topology in the network
			*configuration*.

		So I would suggest that the second paragraph of the introduction be  
revisited with
		this in mind. As it is, it appears a little roundabout, that the  
network topology is
		"designed" by the configuration (I realize that this to some extend  
also is true, but
		I do not think that this is the message in this paragraph?)

	o	Section 3:

		+	should we say in paragraph 1 that we're concerned with IP routers  
and their
			IP interfaces, to stamp out any ambiguity on L2 "routing"?

		+	should we say "between interfaces" rather than "to other  
interfaces on the link"
			in the second paragraph, to not be caught in the "what is a link"  
issue again?

	o	Section 4:
		
		+	First paragraph top of page 4, use "described in section 6.2"  
rather than
			"specified in section 6.2"

		+	Insert "direct" between "As" and "communication" in penultimate  
paragraph.

		+	Alsp penultimate paragraph, any way to get rid of "on that link"?  
I was
			playing around with "between which L2 communication is enabled" as an
			alternative. It avoids the issue that Thaler brought up of "IP  
Link" and
			"Data Link".

		+	Previous bullet applies in the ultimate paragraph of section 4 as  
well.

	o	Section 4 + 5, both:

		+	I suggest replacing "This translates in the following policy" by
			"This translate into the following principle" -- in part because  
"principle"
			is the term used for referencing these later

		+	The "principles", I would make into bullet-points in order to make  
them stand
			out and be easy to see among the text.

	o	Section 5:

		+	First paragraph last sentence after the comma, suggest:

				"....., to uniqueness within, at least, the routing domain".

	o	Section 6.1:

		+	Penultimate bullet, suggest replacing the comma before and by a  
semicolon
	
		+	Ultimate bullet, suggest replacing "A subnet" by "Any subnet"

	o	Section 6.2:

		+	Same considerations as in 6.1 for the first two bullet points.

		+	First paragraph after the two first bulletpoints, suggest:

			   "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:  
connectivity
			    to neighbors may be constantly changing.  The known
			    limitations are:"

			Reason: the original text talk about "mobility" ("moving in and out  
of
			reachability"), which is rather specific to one given type of  
interface.
			Logially, what matters is that being a neighbor at one given time
			does not guarantee that one is neighbor in the future, nor that such
			a change is detectable (to trigger reconfiguration).

		+	First bullet point in last block of bullets, suggest (for the same  
reasons as
			above):

    					"Even if tested for local uniqueness at one given time and  
using
				 	 Duplicate Address Detection (DAD) [RFC4862], a duplicate
					 link-local address might appear as a neighbor at any time  
thereafter.
					 Without an explicit event that would trigger DAD, such duplication
					 would go undetected".

		+	Ultimate paragraph in 6.2 reads more like a "problem statement".
			Suggest rephrasing to conclude that LLs are difficult to use in a  
coherent
			way under the conditions that this document present, and suggest that
			therefore non-LLs are encouraged [in part, because as this is not a  
WG
			document yet, it doesn't really reflect any official WG position on  
the
			matter...yet].

I'll conclude by expressing satisfaction that what is described in  
this document is compatible with the way I build MANETs -- or rather,  
that the configuration of the MANETs, which I am aware of, conforms to  
the principles laid out in this document.

Cheers,

Thomas

> Let's move on quickly with this, while we still have time before  
> Hiroshima!
>
> Cheers,
>
> Emmanuel
>
>
>
> On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli <[email-masked] 
> > wrote:
> Hi all,
>
> an updated version of the MANET addressing model draft has just been  
> published. It integrates comments received during and after the last  
> IETF meeting, including some advisory text about IPv6 Link Local  
> addresses, heavily inspired from Erik Nordmark's initial proposal on  
> this topic.
>
> http://www.ietf.org/id/draft-baccelli-autoconf-adhoc-addr-model-02.txt
>
> Please review it thouroughly, and give us some feedback.
>
> Regards,
>
> Emmanuel
>
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 9 Oct 2009 11:38:22 +0200

Hi Teco,
thanks for your feedback. Comments inline:

On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot <[email-masked]> wrote:

> Hi Emmanuel,
>
> Here some (not retired :-) comments.
>
>
> > 4.  IP Subnet Prefix Configuration
> >
> >   If the link to which an interface connects enables no assumptions of
> >   connectivity to other interfaces, the only addresses which can be
> >   assumed "on link", are the address(es) of that interface itself.
> >   Note that while IPv6 link-local addresses are assumed to be "on
> >   link", the utility of IPv6 link-local addresses is limited as
> >   specified in Section 6.2.
>
> I posted earlier that adding the link-local topic is not needed.
>

I disagree. The last months have shown that there is quite a lot to say
about Link-Locals, and such considerations are summarized later on in the
document, so it seems natural to me to reference it at this point.

> I suggested the text could be changed in:
>
>   If the link to which an interface connects enables no assumptions of
>   connectivity to other interfaces, the only addresses which can be
>   assumed reachable, are the address(es) of that interface itself.
>
> This circumvents the "on-link" discussion, which we can continue forever.
> We better don't.
>

> On 6.2 IPv6 Model:
>
> I am fine with:
> >   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 neighbors
> >   may be constantly moving in and out of reachability.  The known
> >   limitations are:
>  <skip>
> >   Therefore MANET autoconfiguration solutions will primarily focus on
> >   configuring IP addresses that are not IPv6 link-local.
>
>
>
OK.

>
> But I think the left out "known limitations" shall be verified for
> correctness and not being "opinions".
>
> >   o  Even if tested for local uniqueness at one moment using Duplicate
> >      Address Detection [RFC4862], a duplicate link-local address might
> >      appear as a neighbor the next moment and DAD would not detect
> >      that.
>
> This is very true for all unicast address types. Link-local is no exception
> at all!!!
>
>
I guess you are right, the point is not clearly expressed here. I think
Thomas expressed it better in his last email: it's about not having any
discrete on/off link event that would trigger DAD in our context, which is
an issue with regards to traditional use of Link Locals. So how about
saying:

"Even if tested for local uniqueness at one moment using Duplicate Address
Detection [RFC4862], a duplicate link-local address might appear as a
neighbor the next moment, without it being an explicit event that would
trigger DAD again. Such duplication would thus go undetected."

> To rephrase Charlie P. his comment on my recent posting:
> >I think we ought, generally speaking, to try to avoid (ii) at this point
> >in the discussion.
> (ii is DAD)
>
>
> >   o  There is no mechanism to ensure that IPv6 link-local addresses are
> >      unique across multiple links, hence they can not be used to
> >      reliably identify routers.
>
> I remember the RouterID topic was discussed shortly some time ago (IETF
> ??).
> The opinion was that we shall stay away from this topic.
>
> Also, I do not agree. Link-locals can perfectly be used as RouterID,
> as long as the Interface-ID is unique. And this can be ensured in
> many cases, if not all. One approach of Autoconf could be making sure
> Interface-IDs are unique. Then, these can be used for whatever unicast
> Address type. We have to deal with globals one day. The sooner the better.
>
>
>
I agree. I also think the goal of autoconf is to have unique interface IDs
within the routing domain at least (as stated in section 6).

>
> >   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.
>
> This is very true. True in every IPv6 network. I don't see a reason to
> repeat
> this here. Or I miss something.
>
> Maybe the intended limitation was providing reachability on links with
> "RFC4861 asymmetric reachability". When IPv6 routers do not forward packets
> with link-local source or destination, nodes on such a link may have or
> may not have connectivity using link-locals. The MANET protocol would not
> "repair" this. With MANET-local or globals, there is no such limitation in
> connectivity.
> On the other hand, some protocols or applications require that packets
> are not forwarded, even on the same link. Then, link-locals can be
> utilized.
> MANET routing protocols are a perfect example for this.
>
>
> Suggested text:
>
>  Routers cannot forward any packets with link-local source or
>  destination addresses to other links (as per [RFC4291]). In general,
>  routers do not forward such packets. This would limit connectivity
>  between MANET nodes. For this reason, link-local addresses shall be
>  used only for protocols that require one-hop limited delivery of packets.
>
>
> The complete text added in 6.2 would be:
>
>   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 neighbors
>   may be constantly moving in and out of reachability.
>
>   Routers cannot forward any packets with link-local source or
>   destination addresses to other links (as per [RFC4291]). In general,
>   routers do not forward such packets. This would limit connectivity
>   between MANET nodes. For this reason, link-local addresses shall be
>   used only for protocols that require one-hop limited delivery of packets.
>
>   MANET autoconfiguration solutions will primarily focus on
>   configuring IP addresses that are not IPv6 link-local.
>
> I hope everybody can agree on this text.
>
>
>

I personally agree with mentionning the fact that "the use of Link Locals
limits the connectivity between routers" in our context. It's an elegant way
of saying things ;) Now it may be OK in some special case to use a Link
Local address, even if they suffer from these limitations. One trivial
example is: for testing purposes, when a human operator is right next to the
router, why not use a LL to communicate with the router? But for a more
general applicability, including all the routing protocols we have to
accomodate, LLs are not suitable -- I see we agree on that. And that's why
the conclusion is: AUTOCONF should focus on configuring
other types of addresses. Now let's move on!

Cheers
Emmanuel

>
> Regards,
> Teco
>
>
>
> Van: [email-masked] [mailto:[email-masked]] Namens
> Emmanuel Baccelli
> Verzonden: dinsdag 29 september 2009 17:43
> Aan: [email-masked]
> Onderwerp: Re: [Autoconf] updated MANET addressing model draft
>
> Hi all,
>
> Please do let us know your feedback on the updated doc
> Let's move on quickly with this, while we still have time before Hiroshima!
>
> Cheers,
>
> Emmanuel
>
>
> On Thu, Sep 24, 2009 at 1:38 PM, Emmanuel Baccelli
> <[email-masked]> wrote:
> Hi all,
>
> published. It integrates comments received during and after the last IETF
> meeting, including some advisory text about IPv6 Link Local addresses,
> heavily inspired from Erik Nordmark's initial proposal on this topic.
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 9 Oct 2009 11:54:06 +0200

Hi Thomas,
thanks for the detailed comments. See inline:

> agreeing (or disagreeing) with anything.

I'm happy my ultimatum worked. I may use it again ;)

> Speaking without any hats (specifically, I do not speak as chair in this
> email), and simply as someone building MANETs, hereby my comments to this
> document.
>
> Overall:
> =======
>
>  supportive (as WG participant) of accepting this document as WG document.
>
>

Great.

> o The title of the document contains "Ad Hoc Networks", but nowhere does
> it say
> "Ad Hoc Networks" inside the document. This is rather odd. I would suggest
> that
> The latter of these is already said in the Introduction. I would suggest
> that saying
> the two others would make it clear what this document is about. Note that
> the second
>  point above is critical in that the goal is not to "hide" (or "fake out",
> in Townsley-
> terminology) the undetermined connectivity properties, but rather that
> there are routing

Agreed. It makes sense to mention this explicitely at this point.

>
> o The introduction is a little murky with respect to
> links/topology/assumptions/
>  + we may know something about this, or we may not. I.e. given a network,
> we
> may make use this knowledge to make assumptions about the properties of
>  that network.
>
> this in mind. As it is, it appears a little roundabout, that the network
> topology is
>  "designed" by the configuration (I realize that this to some extend also
> is true, but

OK. We will revise this paragraph. I think there is indeed a way to make
this point clearer.

> o Section 3:
>
> + should we say in paragraph 1 that we're concerned with IP routers and
> their
> + should we say "between interfaces" rather than "to other interfaces on
> the link"
> in the second paragraph, to not be caught in the "what is a link" issue
> again?
>
>

OK. Sounds good to me.

>  o Section 4:
>  + First paragraph top of page 4, use "described in section 6.2" rather
> than
> + Alsp penultimate paragraph, any way to get rid of "on that link"? I was
>  alternative. It avoids the issue that Thaler brought up of "IP Link" and
> "Data Link".
>
>  + Previous bullet applies in the ultimate paragraph of section 4 as well.
>

Doable too. I also think it is important to be clear that we are talking
about L2 connectivity here.

> + The "principles", I would make into bullet-points in order to make them
> stand

OK.

>     limited utility on links with undetermined connectivity: connectivity
> Reason: the original text talk about "mobility" ("moving in and out of
>  reachability"), which is rather specific to one given type of interface.
>    "Even if tested for local uniqueness at one given time and using
>   link-local address might appear as a neighbor at any time thereafter.

Agreed. See my email to Teco about this. I think you pinpoint right. We have
to mention the lack on on/off events which is the main difference here.

>  therefore non-LLs are encouraged [in part, because as this is not a WG
> document yet, it doesn't really reflect any official WG position on the
>  matter...yet].
>
>
Right. I guess the "will" in this paragraph is probably a little too
violent. It should be a "should" ;) or replaced by a "recommendation" at
this point.

> I'll conclude by expressing satisfaction that what is described in this
> document is compatible with the way I build MANETs -- or rather, that the
> configuration of the MANETs, which I am aware of, conforms to the principles
> laid out in this document.
>

OK!

Regards,

Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 9 Oct 2009 12:17:20 +0200

Hi Emmanuel,

I'll tag my comments, for better readability.

Van: [email-masked] [mailto:[email-masked]] Namens
Emmanuel Baccelli
Verzonden: vrijdag 9 oktober 2009 11:38
Aan: [email-masked]
Onderwerp: Re: [Autoconf] updated MANET addressing model draft

Hi Teco,

<Teco>
Please explain why LLs have to do with IP Subnet Prefix Configuration.
</Teco>

On 6.2 IPv6 Model:

 <skip>

OK.

I guess you are right, the point is not clearly expressed here. I think
Thomas expressed it better in his last email: it's about not having any
discrete on/off link event that would trigger DAD in our context, which is
an issue with regards to traditional use of Link Locals. 

<Teco>
Again, this is applicable to all types of addresses.
</Teco>

So how about saying:

<Teco>
Again, this is applicable to all types of addresses.
</Teco>

(ii is DAD)

>      reliably identify routers.

I remember the RouterID topic was discussed shortly some time ago (IETF ??).
The opinion was that we shall stay away from this topic.

<Teco>
We could have found some common ground here. 
This would be a break-through:-) 

Is this something to include in the document, section 6.2?
Discuss / get consensus @ next IETF?

By the way, the goal having unique interface IDs is nothing new.
It is related by a long list of proposals, inspired by 8+8/GSE.
</Teco> 

are not forwarded, even on the same link. Then, link-locals can be utilized.

Suggested text:

<Teco>

We can speed up by not arguing on why we focus on configuring other types
of addresses.
Please stay away from a need for routing protocols on not using LLs.
We definitely need the non-LLs for user applications. No one disputes this.

I read the posting from Thomas C., especially on this one:
>>>  MANET protocols require the interfaces to be 
>>>  configured with IP addresses

I can't understand why we focus so much on the MANET routing protocols.
The MANETs I am working with have real users. For them, it is totally
Irrelevant what the MANET protocol IP addresses are. As long as applications
work fine, also in the MANET, they are fine.
There is a problem here, I cannot connect the MANETs to The Internet 
dynamically with IETF protocols available today. I could use NAPT, 
but we IETF really want to kick this out.
We need a solution for connecting our MANETs to the Internet.

Regards, Teco

</Teco> 

Cheers
Emmanuel

Regards,
Teco

Hi all,

Cheers,

Emmanuel

Regards,

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 9 Oct 2009 13:06:22 +0200

Hi Teco,
inline:

> Please explain why LLs have to do with IP Subnet Prefix Configuration.
EB: Can I answer with a cryptic fe80:: ?

> Again, this is applicable to all types of addresses.

EB: I disagree: link local addresses are supposed to be managed
with DAD (RFC4862) which deals with link local signalling only and that
relies on on/off link events. So we have an issue with link-locals. For
other types of addresses, different signalling is at work, that is not
limited to the link, and that can work without on/off link events.

> It is related by a long list of proposals, inspired by 8+8/GSE.
EB: The document already says that the interfaces addresses should be unique
within the routing domain at least so that's fine as it is. I guess we've
been violently agreeing all this time then ;)

> We need a solution for connecting our MANETs to the Internet.
EB: We agree on this goal ;) For this we need routing protocols which work
on MANETs. This document describes a model that works for ALL the current
IETF protocols that work on MANETs, so everything's fine.

Regards
Emmanuel

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 9 Oct 2009 13:58:42 +0200

BOLD ITALIC Calibri J 

Van: [email-masked] [mailto:[email-masked]] Namens
Emmanuel Baccelli
Verzonden: vrijdag 9 oktober 2009 13:06
Aan: [email-masked]
Onderwerp: Re: [Autoconf] updated MANET addressing model draft

Hi Teco,

inline:

Hi Emmanuel,

Aan: [email-masked]

Hi Teco,

<Teco>

TB: Then we are done! Hard coded and no problem at all. 

On 6.2 IPv6 Model:

 <skip>

OK.

<Teco>

EB: I disagree: link local addresses are supposed to be managed with DAD
(RFC4862) which deals with link local signalling only and that relies on
on/off link events. So we have an issue with link-locals. For other types of
addresses, different signalling is at work, that is not limited to the link,
and that can work without on/off link events.

TB: All addresses are support to be managed with DAD. LLs are no special
case.

However, some implementations use DAD only for LLs and as a result, they
assume the InterfaceID is unique so DAD for other addresses with same,
assumed unique, InterfaceID is bypassed (this mechanism is broken). 

Even if true, and we remove the DAD for LLs, or simply ignore it, because it
would not work in all cases in our MANET, then we have the full problem for
making sure all types of addresses are unique.

I might miss something, but for now I assume I'm a messenger of bad news.

No one said we have an easy job L.

So how about saying:

<Teco>

(ii is DAD)

<Teco>

 

TB: InterfaceIDs not equals IP addresses. 

What do you mean with interface addresses? Are there other types of IP
addresses? Link layer addresses?

IP addresses can be identifiers and / or locators. We must be very careful
using right terminology.

Once more, there is something called anycast. IP addresses doesn't need to
be unique in all cases. For those who don't know, this raised in MANET ML
and is of scope for Autoconf.

Suggested text:

<Teco>

TB: I think the MANET protocols are a bit out of scope for Autoconf. It is
all about the other thing, getting addresses and being reachable.

The model in the document requires an update on all OSPF-MANET documents,
including that from yourself (or the STD track OSPF one).

This is unimportant and getting boring. Please do not say it works for all
protocols. It is broken already.

Regards, Teco

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 9 Oct 2009 09:08:26 -0700

Emmanuel,

Section 6.1 of your draft should say the same thing about IPv4 link-local
addresses [RFC3927] as was said about IPv6 link-local addresses in
Section 6.2. The only difference being that when (or rather if) an IPv4
interface configures a routable address the link-local one is typically
deprecated.

Fred
[email-masked]

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Thursday, September 24, 2009 4:39 AM
To: [email-masked]
Subject: [Autoconf] updated MANET addressing model draft

Hi all,

an updated version of the MANET addressing model draft has just been published. It integrates comments received during and after the last IETF meeting, including some advisory text about IPv6 Link Local addresses, heavily inspired from Erik Nordmark's initial proposal on this topic.

Regards,

Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 09 Oct 2009 19:33:25 +0200

Teco Boot a écrit :
> */BOLD ITALIC Calibri /**/J/**/ /*

As a side note: how about using a more traditional way of citing like:

   Mike said on 13th of Aug:
   Paul said on 15th of Aug:
   >> Bit 1 should be 0.
   > No, bit 0 should be 1.

The tools to achieve this ">" indentation and quotation are widely
available on software mailers for users ranging from hardcore
elm/mailx-ers to lazy thunderbird/eudora/outlook-ers.

You seem to be using outlook 2007, so to achieve this ">" effect do
this: Tools->Options->Emailoptions->"During answering a message" (the
2nd scrolling menu of the window) select item "Prefix each line of the
original message" (the last item in that menu).  The quotes are
translated from my French reader, I hope you get it.

Alex

> 
> 
> 
> *Van:* [email-masked] [mailto:[email-masked]] 
> *Namens *Emmanuel Baccelli *Verzonden:* vrijdag 9 oktober 2009 13:06 
> *Aan:* [email-masked] *Onderwerp:* Re: [Autoconf] updated MANET
> addressing model draft
> 
> 
> 
> Hi Teco,
> 
> 
> 
> inline:
> 
> 
> 
> On Fri, Oct 9, 2009 at 12:17 PM, Teco Boot <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Hi Emmanuel,
> 
> Van: [email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>]
> Namens Emmanuel Baccelli
> 
> Aan: [email-masked] <mailto:[email-masked]> Onderwerp: Re:
> [Autoconf] updated MANET addressing model draft
> 
> Hi Teco,
> 
> On Wed, Sep 30, 2009 at 2:19 PM, Teco Boot <[email-masked] 
> <mailto:[email-masked]>> wrote: Hi Emmanuel,
> 
>> If the link to which an interface connects enables no assumptions
>> of connectivity to other interfaces, the only addresses which can
>> be assumed "on link", are the address(es) of that interface itself.
> I disagree. The last months have shown that there is quite a lot to
> say about Link-Locals, and such considerations are summarized later
> on in the document, so it seems natural to me to reference it at this
> point.
> 
> <Teco> Please explain why LLs have to do with IP Subnet Prefix
> Configuration. </Teco>
> 
> 
> 
> 
> 
> */TB: Then we are done! Hard coded and no problem at all. /*
> 
> 
> 
> 
> 
> 
> This circumvents the "on-link" discussion, which we can continue 
> forever. We better don't.
> 
> 
> On 6.2 IPv6 Model:
> 
> I am fine with:
>> appear as a neighbor the next moment and DAD would not detect that.
>> 
> 
> This is very true for all unicast address types. Link-local is no 
> exception at all!!!
> 
> I guess you are right, the point is not clearly expressed here. I
> think Thomas expressed it better in his last email: it's about not
> having any discrete on/off link event that would trigger DAD in our
> context, which is an issue with regards to traditional use of Link
> Locals.
> 
> <Teco> Again, this is applicable to all types of addresses. </Teco>
> 
> 
> 
> 
> 
> 
> 
> EB: I disagree: link local addresses are supposed to be managed with
> DAD (RFC4862) which deals with link local signalling only and that 
> relies on on/off link events. So we have an issue with link-locals.
> For other types of addresses, different signalling is at work, that
> is not limited to the link, and that can work without on/off link
> events.
> 
> */TB: All addresses are support to be managed with DAD. LLs are no 
> special case./*
> 
> */However, some implementations use DAD only for LLs and as a result,
>  they assume the InterfaceID is unique so DAD for other addresses
> with same, assumed unique, InterfaceID is bypassed (this mechanism is
> broken). /*
> 
> */Even if true, and we remove the DAD for LLs, or simply ignore it, 
> because it would not work in all cases in our MANET, then we have the
>  full problem for making sure all types of addresses are unique./*
> 
> */I might miss something, but for now I assume I’m a messenger of bad
>  news./*
> 
> */No one said we have an easy job /**/L/**/./*
> 
> 
> 
> 
> 
> 
> So how about saying:
> 
> "Even if tested for local uniqueness at one moment using Duplicate
> appear as a neighbor the next moment, without it being an explicit
> event that would trigger DAD again. Such duplication would thus go
> undetected."
> 
> <Teco> Again, this is applicable to all types of addresses. </Teco>
> 
> 
> 
> I remember the RouterID topic was discussed shortly some time ago 
> (IETF ??). The opinion was that we shall stay away from this topic.
> 
>  Interface-IDs are unique. Then, these can be used for whatever
> unicast Address type. We have to deal with globals one day. The
> sooner the better.
> 
> 
> I agree. I also think the goal of autoconf is to have unique 
> interface IDs within the routing domain at least (as stated in
> section 6).
> 
> <Teco> We could have found some common ground here. This would be a
> break-through:-)
> 
> Is this something to include in the document, section 6.2? Discuss /
> get consensus @ next IETF?
> 
> By the way, the goal having unique interface IDs is nothing new. It
> is related by a long list of proposals, inspired by 8+8/GSE. </Teco>
> 
> 
> 
> 
> 
> 
> EB: The document already says that the interfaces addresses should be
>  unique within the routing domain at least so that's fine as it is. I
>  guess we've been violently agreeing all this time then ;)
> 
> */TB: InterfaceIDs not equals IP addresses. /*
> 
> */What do you mean with interface addresses? Are there other types of
> IP addresses? Link layer addresses?/*
> 
> */IP addresses can be identifiers and / or locators. We must be very
>  careful using right terminology./*
> 
> */Once more, there is something called anycast. IP addresses doesn’t
>  need to be unique in all cases. For those who don’t know, this
> raised in MANET ML and is of scope for Autoconf./*
> 
> 
> 
> 
> 
> 
> This is very true. True in every IPv6 network. I don't see a reason
> to repeat this here. Or I miss something.
> 
> Maybe the intended limitation was providing reachability on links
> with "RFC4861 asymmetric reachability". When IPv6 routers do not
> forward packets with link-local source or destination, nodes on such
> a link may have or may not have connectivity using link-locals. The
> MANET protocol would not "repair" this. With MANET-local or globals,
> there is no such limitation in connectivity. On the other hand, some
> protocols or applications require that packets are not forwarded,
> even on the same link. Then, link-locals can be utilized. MANET
> routing protocols are a perfect example for this.
> 
> 
> Suggested text:
> 
> MANET autoconfiguration solutions will primarily focus on configuring
> IP addresses that are not IPv6 link-local.
> 
> I personally agree with mentionning the fact that "the use of Link 
> Locals limits the connectivity between routers" in our context. It's
> an elegant way of saying things ;) Now it may be OK in some special
> case to use a Link Local address, even if they suffer from these
> limitations. One trivial example is: for testing purposes, when a
> human operator is right next to the router, why not use a LL to
> communicate with the router? But for a more general applicability,
> including all the routing protocols we have to accomodate, LLs are
> not suitable -- I see we agree on that. And that's why the conclusion
> is: AUTOCONF should focus on configuring other types of addresses.
> Now let's move on!
> 
> <Teco>
> 
> We can speed up by not arguing on why we focus on configuring other 
> types of addresses. Please stay away from a need for routing
> protocols on not using LLs. We definitely need the non-LLs for user
> applications. No one disputes this.
> 
>>>> MANET protocols require the interfaces to be configured with IP
>>>> addresses
> 
> I can't understand why we focus so much on the MANET routing
> protocols. The MANETs I am working with have real users. For them, it
> is totally Irrelevant what the MANET protocol IP addresses are. As
> long as applications work fine, also in the MANET, they are fine. 
> but we IETF really want to kick this out. We need a solution for
> connecting our MANETs to the Internet.
> 
> 
> 
> EB: We agree on this goal ;) For this we need routing protocols which
>  work on MANETs. This document describes a model that works for ALL
> the current IETF protocols that work on MANETs, so everything's fine.
> 
> 
> 
> 
> */TB: I think the MANET protocols are a bit out of scope for
> Autoconf. It is all about the other thing, getting addresses and
> being reachable./*
> 
> */ /*
> 
> */The model in the document requires an update on all OSPF-MANET 
> documents, including that from yourself (or the STD track OSPF
> one)./*
> 
> */This is unimportant and getting boring. Please do not say it works
> for all protocols. It is broken already./*
> 
> */ /*
> 
> */Regards, Teco/*
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Oct 2009 11:34:32 -0700

Hello Emmanuel,

I think it is a good draft.  I generally agree with Thomas's comments
for editorial improvement.  I still find the word "translates" unclear,
and would make the following changes:

>                                     This translates in the
>    following policy: 
-->

                                    This suggests the
   following policy: 

[two occurrences]
[BTW: "translates in" is not good idiomatic English anyway]

and
>                                                    The
>    following describes a practical translation for these
>    principles, respectively for IPv4 and IPv6.
>
>   
-->

                                                   The
   following describes guidelines that follow from these
   principles, respectively for IPv4 and IPv6.

Regards,
Charlie P.

Emmanuel Baccelli wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     an updated version of the MANET addressing model draft has just
>     been published. It integrates comments received during and after
>     the last IETF meeting, including some advisory text about IPv6
>     Link Local addresses, heavily inspired from Erik Nordmark's
>     initial proposal on this topic.
>