Subject: [Autoconf] IPv4 link-locals

From: Mark Townsley <[email-masked]>
Date: Wed, 21 Oct 2009 11:28:32 +0200

Fred wrote:
> 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

Fred, this is the text that ended up in -00:

   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.2 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 DAD.

However, I think that we need to say a little more here to your point. 
Also, I think that while it is reasonable to discourage link-local usage 
in IPv6 (as hopefully we are more able to readily autoconfigure a ULA or 
Global Ipv6 address) the situation in IPv4 is a bit different as 
obtaining a unique Global or Private IPv4 address may be quite a bit 
more difficult. Therefore, usage of IPv4 link-locals may be necessary in 
some cases (I'm thinking of mdns-based service discovery, for example). 
So, I'd like to propose something like this:

"The use of IPv4 link-local addresses [RFC3927] is discouraged for most 
applications. The limitations outlined in Section 6.2 for IPv6 
link-local addresses also concern IPv4 link-local addresses, and are 
further exacerbated by the smaller pool of IPv4 link-local addresses to 
choose from and thus increased reliance on DAD. However, given the 
increased difficulty of obtaining a Global or Private [RFC1918] IPv4 
address, use of IPv4 link-locals may be the only readily available 
option in some circumstances. Applications running in an ad-hoc 
environment must be well-aware that link-connectivity is constantly in 
flux, and if link-locals are used, ensure that this is not a detrimental 
factor to proper operation. An application that may be able to use IPv4 
link-locals effectively is one that consists of a stateless 
request-response action and no more. An application that may not operate 
with IPv4 link-locals effectively is one that relies on nodes to have a 
consistent or long-lived IPv4 address (e.g., connection-oriented 
communication bound to the IP address). In the event an interface 
obtains a non-link-local IPv4 address, the link-local IPv4 address 
should be deprecated."

- Mark

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Oct 2009 11:33:06 -0700

Hi Mark,

> -----Original Message-----
> From: Mark Townsley [mailto:[email-masked]]
> Sent: Wednesday, October 21, 2009 2:29 AM
> To: Templin, Fred L; [email-masked]
> Subject: IPv4 link-locals
> 
> 
> Fred wrote:
> > Emmanuel,
> >

Thanks for pointing this out.

> However, I think that we need to say a little more here to your point.

Yes, a bit more is needed.

> some cases (I'm thinking of mdns-based service discovery, for example).

Agreed.

> obtains a non-link-local IPv4 address, the link-local IPv4 address

I am fine with this, but it might benefit from a paragraph
break somewhere. It might also be worth checking RFC3927 to
see if anything that is being said here is redundant, but I
would not object to the wording as you have it.

Fred
[email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Oct 2009 15:32:44 +0200

Mark Townsley a écrit :
> 
> Fred wrote:
>> 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
> 
> However, I think that we need to say a little more here to your
> point. Also, I think that while it is reasonable to discourage
> link-local usage in IPv6 (as hopefully we are more able to readily
> autoconfigure a ULA or Global Ipv6 address) the situation in IPv4 is
> a bit different as obtaining a unique Global or Private IPv4 address
> may be quite a bit more difficult. Therefore, usage of IPv4
> link-locals may be necessary in some cases (I'm thinking of
> mdns-based service discovery, for example). So, I'd like to propose
> something like this:
> 
> "The use of IPv4 link-local addresses [RFC3927] is discouraged for
> most applications.

I disagree.  I have an example showing otherwise.  ActiveSync is run on
a large share of the current market devices pertaining to MANETs.  They
all do IPv4 link-local addresses for a very wide range of applications.

One can't "discourage" that.  One should first ack the widespread
deployment of IPv4 link-local address use.

> The limitations outlined in Section 6.2 for IPv6 link-local addresses
> also concern IPv4 link-local addresses, and are further exacerbated
> by the smaller pool of IPv4 link-local addresses to choose from and
> thus increased reliance on DAD.  However, given the increased
> difficulty of obtaining a Global or Private [RFC1918] IPv4 address,

Which difficulty?  I personally have the feeling it's more and more
easy to obtain public IPv4 addresses.  I had to struggle in 2000 for a
class C, but a few months ago I could get one very easily.  Maybe
because people rush to IPv6 deployment...

Maybe a reference should be given here to support the statement that
public IPv4 addresses are hard to get, and for whom.

(a fast reader would be tempted into thinking that the [RFC1918] is such
  a reference, but no).

> use of IPv4 link-locals may be the only readily available option in
> some circumstances. Applications running in an ad-hoc environment
> must be well-aware that link-connectivity is constantly in flux, and
> if link-locals are used, ensure that this is not a detrimental factor
> to proper operation. An application that may be able to use IPv4 
> request-response action and no more.

Er?  What is this?  My web browser on my PDA is such a "stateless 
request-response action"?  And my gps IP tools too?  Both use IPv4 
link-local addresses.

> An application that may not operate with IPv4 link-locals effectively
> is one that relies on nodes to have a consistent or long-lived IPv4
> address (e.g., connection-oriented communication bound to the IP
> address).

Why?

An IPv4 link-local address can be very long-lived.

Typically apps on devices with IPv4 link-local addresses live behind 
NATs.  These NATs may change their "CoA" address (if I can say so) and 
may have problems because of that.  But that is the problem of these 
NATs, not of the device using hte IPv4 link-local address.

> In the event an interface obtains a non-link-local IPv4
> address, the link-local IPv4 address should be deprecated."

Well, it depends for which purpose?  Which protocol?  Which application?

I think there are IPv4 apps and protocols which can only use IPv4 
link-local addresses, even if there is an IPv4 global address on the 
interface.  I think you already say so at the beginning (mDNS).  There's 
also ActiveSync app.

Alex

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

---

From: Mark Townsley <[email-masked]>
Date: Sun, 25 Oct 2009 10:35:00 +0100

Alexandru Petrescu wrote:
> a large share of the current market devices pertaining to MANETs.
We said "most" - one cited application does not contradict that.

In fact, I'd go so far as to say that "most" applications, even on a 
typical wired network, should avoid IPv4 link local if possible. That's 
clearly what they do today (on purpose or not) as once a non-link-local 
is available on the interface, the link-local is deprecated. Perhaps 
that is all the section should say and no more, as it certainly implies 
that link-local is to be avoided if another address is available.

This of course brings upon the additional dependency that the 
application be able to handle IPv4 address changes, rebinding from 
link-local to a different scope and perhaps back again. Again, this is 
certainly possible for some applications, but not all (at least not 
transparently to the user).
> They
The question is whether autoconf should put cycles into:

- Making sure IPv4 link-locals are stable and usable within a manet, or
- Making sure IPv4 Private addresses stable and usable within a manet, or
- Making sure IPv4 Global addresses stable and usable within a manet, or
... all of the above.

Success is dependent upon the address space you have to work with, the 
number of addresses needed for a deployment, the scope of the 
deployment, etc. ... not to mention the mechanisms for assignment.

I think that the confidence level of an address being stable, or at 
least unique, is likely higher as you move from link-local to private to 
global spaces in IPv4. That's a generalization, and depends on things 
like simply not camping out on global address space that hasn't actually 
been assigned, not to mention the number of and veracity of movement of 
devices relative to one another.

It's all fairly fuzzy, and that's sort of the point... That if your 
application or the operator of the device knows the environment it is 
working in, it can use whatever address it has, link-local or otherwise. 
If not, then perhaps its best to wait until a more "stable" address is 
available.

So, should autoconf focus on making Global, Private *and* link-local 
addresses stable and usable for "any" or even "most" applications, or 
should it pick a smaller subset? That's what this section is really 
trying to do. To scope the work for the autoconf mechanism. Certainly 
link-local addresses are available and can be used, the question is 
whether we need to go out of our way to make them even more available 
and usable, or if we should just focus on getting a (hopefully more 
stable) Private or Global address ASAP and push the link-local out of 
the way so that applications are not required to be resilient to their 
peculiarities.

- Mark

> interface.  I think you already say so at the beginning (mDNS).  
> There's also ActiveSync app.
>
> Alex
>
>>
>> - Mark
>>
>>
>>
>>
>>
>>
>>
>>

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 25 Oct 2009 14:17:48 +0100

>Mark Townsley wrote:

Or none of above. I prefer a focus on IPv6.

When we arrange IPv6 connectivity to a border router, it is easy to set up
a DHCP connection. It requires DHCP_v4 over DHCP_v6 or alternative. Doable.

Regards, Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Oct 2009 15:23:29 +0100

> - Making sure IPv4 Global addresses stable and usable within a manet, or

Of course, put that way, one would prefer the last, "make sure the 
global addresses are usable and stable"... because one thinks manet 
needs it.

But put it another way: make sure the AUTOCONF results still work with 
ad-hoc unaware nodes (as the Charter mentions too) - then one would 
prefer to simply not spend any cycles in forbidding something already 
deployed.

> global spaces in IPv4.

Yes, that sounds reasonable.  For IPv4, one would trust more that the 
global publicly routable address is unique than its LL or private address.

Except that the IPv4 LL is based on a pseudo-random thing and, moreover, 
tested for uniqueness (RFC 3927 probes), whereas the IPv4 global address 
is trusted unique either because adminsitratively assigned (very true 
for adhoc unaware nodes) or DHCP-assigned (sometimes leading to duplicates).

In this sense, one trusts more the uniqueness of IPv4 LL addresses than 
IPv4 global addresses.

Do you also intend to discard the RFC3927 probing (similar to IPv6 DAD)?

> That's a generalization, and depends on things 

This is something that touches on the future AUTOCONF designs.  Have we 
decided somehow that the AUTOCONF node keeps an address stable despite 
its movements?  Or will it prefer to change its address upon each movement?

I can tell about the adhoc unaware nodes.

The adhoc unaware hosts prefer to change their addresses when moving, 
i.e. when changing attachment to a different IP subnet.  For ad-hoc 
unaware routers, the behaviour facing changes due to physical movement 
depends on many factors.  There are a few types of adhoc unaware 
routers, such as NEMO mobile routers, static routers, and more.

> the way so that applications are not required to be resilient to their 

Getting dynamically an IPv4 public address... yes, but then it should be 
tested for uniqueness, especially in a highly mobile environment.  Are 
you going to design a mechanism similar to IPv4 LL probing RFC 3927 
(IPv4 LLs). ?

If it's not tested for uniqueness, there are risks of duplicate address 
use, a thing which I have seen very often on Windows screens and linux 
dmesg messages.

Are you going to test for uniqueness of IPv4 global addresses?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 25 Oct 2009 16:43:28 +0100

On Oct 25, 2009, at 3:23 PM, Alexandru Petrescu wrote:
> But put it another way: make sure the AUTOCONF results still work  
> with ad-hoc unaware nodes (as the Charter mentions too) - then one  
> would prefer to simply not spend any cycles in forbidding something  
> already deployed.
>

Alex,

Can you explain what in the current document will impact the behavior  
"ad hoc unaware nodes", and propose a way of rectifying this matter?

Thanks,

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Oct 2009 17:22:35 +0100

> "ad hoc unaware nodes", and propose a way of rectifying this matter?

Thomas, I have doubts with respect to the use of "discourage" in this text:

draft in question says:
>    context should be discouraged for most applications

Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware node 
by sending it ARP packets with its address and somebody else's MAC 
address? (thus making the adhoc unaware node, which implements rfc3927, 
  believe it can't use its IPv4 LL in that network.)

If yes - we have an impact problem, as per Charter.  It may read as a 
DoS for IPv4 LLs.

To address this potential problem I propose two alternative paragraphs:

"When IPv4 link-local addresses are available for use in a certain node, 
then they may prove useful for AUTOCONF mechanisms, as they are tested 
for uniqueness.  Future AUTOCONF mechanisms MAY use IPv4 link-local 
addresses, if RFC3927 implementation available, as a starting point in 
configuring publicly routable IPv4 addresses."

XOR

"Future AUTOCONF mechanims should allow the use of IPv4 LLs for adhoc 
unaware nodes and should not allow the use of IPv4 LLs for MANET nodes".

Is this inline with the intention of that [discourage] word?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 25 Oct 2009 18:35:47 +0100

On Oct 25, 2009, at 5:22 PM, Alexandru Petrescu wrote:

>>> global addresses are usable and stable"... because one thinks  
>>> manet needs it.
>>>
>>> would prefer to simply not spend any cycles in forbidding  
>>> something already deployed.
>>>
>> Alex,
>> Can you explain what in the current document will impact the  
>> behavior "ad hoc unaware nodes", and propose a way of rectifying  
>> this matter?
>
> Will an AUTOCONF network discourage the IPv4 LL of an adhoc-unaware  
> node by

Absolutely not. I am not reading the draft as mandating anything on  
"ad hoc unaware nodes". Rather, the draft is careful on stating that  
(I paraphrase): "If one knows something about the topology, i.e. one  
is not in an ad hoc network, USE THAT KNOWLEDGE"

> sending it ARP packets with its address and somebody else's MAC  
> address? (thus making the adhoc unaware node, which implements  
> rfc3927,  believe it can't use its IPv4 LL in that network.)
>
> If yes - we have an impact problem, as per Charter.  It may read as  
> a DoS for IPv4 LLs.

My read is, that for what you call "ad hoc unaware nodes", that  
document mandates absolutely nothing.

> "When IPv4 link-local addresses are available for use in a certain  
> node, then they may prove useful for AUTOCONF mechanisms, as they  
> are tested for uniqueness.

Disagree. This i the "wrong way around": a LL address (v4 or v6)  
cannot with existing mechanisms be tested for uniqueness and -- even  
if they could -- due to node mobility any uniqueness would not be  
guaranteed to exist over time.

Hence, if I have a LL address, generated "the usual way" (v4 or v6),  
then on an "ad hoc aware node" [to retake your terminology] I can not  
be sure that it is useful as I do not know of the properties of that  
address. IOW, IPv6 prescribes "thou shall have a LL address" -- which  
is fine. We observe that "in an ad hoc network, thy better be wary  
that the LL address may be of limited use". Which, I think, is also  
fine.

>  Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if  
> RFC3927 implementation available, as a starting point in configuring  
> publicly routable IPv4 addresses."
>
> XOR
>
> "Future AUTOCONF mechanims should allow the use of IPv4 LLs for  
> adhoc unaware nodes and should not allow the use of IPv4 LLs for  
> MANET nodes".
>

No, see above...

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Oct 2009 19:16:02 +0100

ThomasC - I suppose the draft should say something about how AUTOCONF 
addressing model doesnt cause problems to the adhoc unaware parts of the 
system, right? (it's a requirement in the Charter):

Charter:
> 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. It is required that such models do not cause problems for ad
> hoc-unaware parts of the system, such as standard applications running
> on an ad hoc node or regular Internet nodes attached to the ad hoc
> nodes. 

Thomas Heide Clausen a écrit :
> Absolutely not. I am not reading the draft as mandating anything on "ad 
> hoc unaware nodes".

Ok, how about about "regular Internet dones" (from the Charter).

> Rather, the draft is careful on stating that (I 
> paraphrase): "If one knows something about the topology, i.e. one is not 
> in an ad hoc network, USE THAT KNOWLEDGE"

Where in the draft?

Also - the important thing here (by the Charter) is to say what happens 
when one _is_ in the ad hoc network, and is adhoc unaware - make sure 
things dont break.

> My read is, that for what you call "ad hoc unaware nodes", that document 
> mandates absolutely nothing.

That sounds ok, but the draft should say something about how it doesnt 
impact the adhoc unaware parts.

>> node, then they may prove useful for AUTOCONF mechanisms, as they are 
>> tested for uniqueness.
> 
> Disagree. This i the "wrong way around": a LL address (v4 or v6) cannot 
> with existing mechanisms be tested for uniqueness and -- even if they 
> could -- due to node mobility any uniqueness would not be guaranteed to 
> exist over time.

In a sense, I agree, but there are also times where it could be 
guaranteed - for adhoc unaware nodes.

> then on an "ad hoc aware node" [to retake your terminology]

Ok, sorry, I meant "regular Internet nodes" - which is in the Charter too.

Adhoc unaware parts
regular Internet nodes

> I can not be 
> sure that it is useful as I do not know of the properties of that 
> address. IOW, IPv6 prescribes "thou shall have a LL address" -- which is 
> fine. We observe that "in an ad hoc network, thy better be wary that the 
> LL address may be of limited use". Which, I think, is also fine.

That interpretation is fine.  But the text starts by saying how it 
discourages the IPv4 LLs.

>> Is this inline with the intention of that [discourage] word?

What does that [discourage] mean with respect to the regular Internet nodes?

 >>>   context should be discouraged for most applications

Does the context==MANET?  If yes, I agree with the paragraph, provided 
it also says something about how a regular Internet node (adhoc unaware 
part of the System) _can_ use its IPv4 LL if it wants to.

Otherwise, the MANET nodes will never talk to the other parts of the 
system, the adhoc unaware parts - the regular Internet nodes.

Alex

---

From: Emmanuel Baccelli <[email-masked]>
Date: Sun, 25 Oct 2009 19:22:06 +0100

Hi Alex,
obviously, this topic is completely out of scope for the addressing model
document, and even for the whole working group!
Emmanuel

On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu <
[email-masked]> wrote:

>>>>> global addresses are usable and stable"... because one thinks manet needs
>>>>> it.
>>>>>
>>>>> ad-hoc unaware nodes (as the Charter mentions too) - then one would prefer
>>>>> to simply not spend any cycles in forbidding something already deployed.
>>>>>
>>>>>  Alex,
>>> by
>  Rather, the draft is careful on stating that (I paraphrase): "If one knows
>> something about the topology, i.e. one is not in an ad hoc network, USE THAT
>> KNOWLEDGE"
>>
>
> Where in the draft?
>
> when one _is_ in the ad hoc network, and is adhoc unaware - make sure things
> dont break.
>
>  sending it ARP packets with its address and somebody else's MAC address?
>>> (thus making the adhoc unaware node, which implements rfc3927,  believe it
>>> can't use its IPv4 LL in that network.)
>>>
>>> If yes - we have an impact problem, as per Charter.  It may read as a DoS
>>> for IPv4 LLs.
>>>
>>
>>> then they may prove useful for AUTOCONF mechanisms, as they are tested for
>>> uniqueness.
>>>
>>
>> with existing mechanisms be tested for uniqueness and -- even if they could
>> -- due to node mobility any uniqueness would not be guaranteed to exist over
>> time.
>>
>
> In a sense, I agree, but there are also times where it could be guaranteed
> - for adhoc unaware nodes.
>
>  Hence, if I have a LL address, generated "the usual way" (v4 or v6), then
>> on an "ad hoc aware node" [to retake your terminology]
>>
>
>  I can not be sure that it is useful as I do not know of the properties of
>> that address. IOW, IPv6 prescribes "thou shall have a LL address" -- which
>> is fine. We observe that "in an ad hoc network, thy better be wary that the
>   Future AUTOCONF mechanisms MAY use IPv4 link-local addresses, if RFC3927
>>> implementation available, as a starting point in configuring publicly
>>> routable IPv4 addresses."
>>>
>>> XOR
>>>
> Does the context==MANET?  If yes, I agree with the paragraph, provided it
> also says something about how a regular Internet node (adhoc unaware part of
> the System) _can_ use its IPv4 LL if it wants to.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 25 Oct 2009 19:29:56 +0100

Emmanuel Baccelli a écrit :
> Hi Alex,
> obviously, this topic is completely out of scope for the addressing 
> model document, and even for the whole working group!

But it's in the Charter, no?

Alex

> Emmanuel
> 
> 
> On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     ThomasC - I suppose the draft should say something about how
>     AUTOCONF addressing model doesnt cause problems to the adhoc unaware
>     parts of the system, right? (it's a requirement in the Charter):
> 
>     Charter:
> 
>                     Of course, put that way, one would prefer the last,
>                     "make sure the global addresses are usable and
>                     stable"... because one thinks manet needs it.
> 
>                     But put it another way: make sure the AUTOCONF
>                     results still work with ad-hoc unaware nodes (as the
>                     Charter mentions too) - then one would prefer to
>                     simply not spend any cycles in forbidding something
>                     already deployed.
> 
>                 Alex,
>                 Can you explain what in the current document will impact
>                 the behavior "ad hoc unaware nodes", and propose a way
>                 of rectifying this matter?
> 
> 
>             Will an AUTOCONF network discourage the IPv4 LL of an
>             adhoc-unaware node by
> 
> 
>         Absolutely not. I am not reading the draft as mandating anything
>         on "ad hoc unaware nodes".
> 
> 
>         Rather, the draft is careful on stating that (I paraphrase): "If
>         one knows something about the topology, i.e. one is not in an ad
>         hoc network, USE THAT KNOWLEDGE"
> 
> 
>     Where in the draft?
> 
>     Also - the important thing here (by the Charter) is to say what
>     happens when one _is_ in the ad hoc network, and is adhoc unaware -
>     make sure things dont break.
> 
>             sending it ARP packets with its address and somebody else's
>             MAC address? (thus making the adhoc unaware node, which
>             implements rfc3927,  believe it can't use its IPv4 LL in
>             that network.)
> 
>             If yes - we have an impact problem, as per Charter.  It may
>             read as a DoS for IPv4 LLs.
> 
> 
>     That sounds ok, but the draft should say something about how it
>     doesnt impact the adhoc unaware parts.
> 
>             "When IPv4 link-local addresses are available for use in a
>             certain node, then they may prove useful for AUTOCONF
>             mechanisms, as they are tested for uniqueness.
> 
> 
>         cannot with existing mechanisms be tested for uniqueness and --
>         even if they could -- due to node mobility any uniqueness would
>         not be guaranteed to exist over time.
> 
> 
>         Hence, if I have a LL address, generated "the usual way" (v4 or
>         v6), then on an "ad hoc aware node" [to retake your terminology]
> 
> 
>         I can not be sure that it is useful as I do not know of the
>         properties of that address. IOW, IPv6 prescribes "thou shall
>         have a LL address" -- which is fine. We observe that "in an ad
>         hoc network, thy better be wary that the LL address may be of
>         limited use". Which, I think, is also fine.
> 
> 
>              Future AUTOCONF mechanisms MAY use IPv4 link-local
>             addresses, if RFC3927 implementation available, as a
>             starting point in configuring publicly routable IPv4 addresses."
> 
>             XOR
> 
>             "Future AUTOCONF mechanims should allow the use of IPv4 LLs
>             for adhoc unaware nodes and should not allow the use of IPv4
>             LLs for MANET nodes".
> 
>     Does the context==MANET?  If yes, I agree with the paragraph,
>     provided it also says something about how a regular Internet node
>     (adhoc unaware part of the System) _can_ use its IPv4 LL if it wants to.
> 
>     [email-masked] <mailto:[email-masked]>
> ------------------------------------------------------------------------
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 25 Oct 2009 22:54:40 +0100

> parts of the system, right? (it's a requirement in the Charter):

Not really.

If I write that "all ThomasC's cars shall be blue" in a draft, do I  
then also need to also add a note insisting that "note, this doesn't  
apply to AlexP's cars", even thought this already was explicit that  
the "blue" statement applied only to ThomasC's cars?

Thomas

>>>>> Of course, put that way, one would prefer the last, "make sure  
>>>>> the global addresses are usable and stable"... because one  
>>>>> thinks manet needs it.
>>>>>
>>>>> But put it another way: make sure the AUTOCONF results still  
>>>>> work with ad-hoc unaware nodes (as the Charter mentions too) -  
>>>>> then one would prefer to simply not spend any cycles in  
>>>>> forbidding something already deployed.
>>>>>
>>>> Alex,
>>> Will an AUTOCONF network discourage the IPv4 LL of an adhoc- 
>>> unaware node by
>> "ad hoc unaware nodes".
>>> If yes - we have an impact problem, as per Charter.  It may read  
>>> as a DoS for IPv4 LLs.
>> even if they could -- due to node mobility any uniqueness would not  
>> be guaranteed to exist over time.
>
>> properties of that address. IOW, IPv6 prescribes "thou shall have a  
>> LL address" -- which is fine. We observe that "in an ad hoc  
>> network, thy better be wary that the LL address may be of limited  
>> use". Which, I think, is also fine.
>
>>> RFC3927 implementation available, as a starting point in

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 25 Oct 2009 22:59:06 +0100

<SNIP>

> make sure things dont break.

I'm trying to see where in the RFC2740 it is specified what happens if  
a non-OSPFv3 aware router finds itself in an OSPFv3-network. As I  
can't find anything in 2740, my conjecture would be "that router  
wouldn't work in that network" -- which seems quite reasonable.

Why should ad hoc networks be different?

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 25 Oct 2009 23:00:01 +0100

> But it's in the Charter, no?

No - what is in the charter is not what you're implying.

Thomas

> Alex
>
>> Emmanuel
>> On Sun, Oct 25, 2009 at 7:16 PM, Alexandru Petrescu <[email-masked] 
>>  <mailto:[email-masked]>> wrote:
>>        addresses. It is required that such models do not cause  
>> problems
>>        for ad
>>                        - Making sure IPv4 Private addresses stable  
>> and
>>                        usable within a manet, or
>>            To address this potential problem I propose two  
>> alternative
>>            paragraphs:

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 09:51:34 +0100

Thomas Heide Clausen a écrit :
> I'm trying to see where in the RFC2740 it is specified what happens if a 
> non-OSPFv3 aware router finds itself in an OSPFv3-network. As I can't 
> find anything in 2740, my conjecture would be "that router wouldn't work 
> in that network" -- which seems quite reasonable.
> 

> on an ad hoc node or regular Internet nodes attached to the ad hoc

One way to satisfy that requirement is to write about it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 09:52:24 +0100

Please interpret this for me:

> It is required that such models do not cause problems for ad

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 10:01:39 +0100

On Oct 26, 2009, at 9:52 AM, Alexandru Petrescu wrote:

>>>> obviously, this topic is completely out of scope for the  
>>>> addressing model document, and even for the whole working group!
>>>

Easy, consider this example network:

	{a,b,c,d}-----AHR--

AHR is an Ad Hoc Router with two interfaces. One is towards {a,b,c,d}  
and is a regular ethernet, with a, b, c and d being regular non-MANET  
hosts or routers. The other interface is a "MANET interface" towards  
other AHRs.

Whatever [autoconf] does should not affect {a, b, c, d} at all -- but,  
of course, will affect AHRs and their interconnect.

Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers do  
between them (and whatever changes are introduced to OSPFv3) on OSPFv3  
interfaces does not affect {a, b, c, d}.

This because the "magic of an OSPFv3 routing domain" -- and the "magic  
of a MANET routing domain" -- is isolated from the rest of the network  
by an IP hop. All the "ad hoc unaware parts of the system" see is a  
well-defined, unchanged, classic, legacy IP hop...

Thomas

<SNIP - for those reading the digest>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 10:05:28 +0100

> of course, will affect AHRs and their interconnect.

I agree.

This should be said in the document, to satisfy that Charter requirement.

It currently does not address that requirement (at least not with 
respect to link-local addresses).

Once you agree this is necessary, we can see further.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 10:09:15 +0100

On Oct 26, 2009, at 10:05 AM, Alexandru Petrescu wrote:

>> AHR is an Ad Hoc Router with two interfaces. One is towards  
>> {a,b,c,d} and is a regular ethernet, with a, b, c and d being  
>> regular non-MANET hosts or routers. The other interface is a "MANET  
>> interface" towards other AHRs.
>> Whatever [autoconf] does should not affect {a, b, c, d} at all --  
>> but, of course, will affect AHRs and their interconnect.
>
> I agree.
>

I'd be much happier if you rephrase your last sentence to:

	"Once the WG agrees, we can see further"

;)

So I'll wait for the rest of the WG to chime in -- I just explained my  
understanding of the charter.

Thomas

>> between them (and whatever changes are introduced to OSPFv3) on  
>> OSPFv3 interfaces does not affect {a, b, c, d}.
>> This because the "magic of an OSPFv3 routing domain" -- and the  
>> "magic of a MANET routing domain" -- is isolated from the rest of  
>> the network by an IP hop. All the "ad hoc unaware parts of the  
>> system" see is a well-defined, unchanged, classic, legacy IP hop...
>> Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 10:30:46 +0100

> understanding of the charter.

:-)

You implicitely say above that the Ad Hoc Router AHR has two interfaces.

Maybe we should get agreement from the WG about AHR having two 
interfaces? (early signs showed 1).

Alex

>>> "magic of a MANET routing domain" -- is isolated from the rest of the 
>>> network by an IP hop. All the "ad hoc unaware parts of the system" 
>>> see is a well-defined, unchanged, classic, legacy IP hop...
>>> Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 10:31:46 +0100

On Oct 26, 2009, at 10:30 AM, Alexandru Petrescu wrote:

>>>> regular non-MANET hosts or routers. The other interface is a  
>>>> "MANET interface" towards other AHRs.
>> So I'll wait for the rest of the WG to chime in -- I just explained  
>> my understanding of the charter.
>
> :-)
>

No, I was saying that my example has one interface.

> interfaces? (early signs showed 1).

No. An AHR may have 1, 2 or many many more interfaces....

Thomas

> Alex
>
>> Thomas
>>> Alex
>>>
>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3-routers  
>>>> do between them (and whatever changes are introduced to OSPFv3)  
>>>> on OSPFv3 interfaces does not affect {a, b, c, d}.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 10:35:10 +0100

> No, I was saying that my example has one interface.

But you pictured two ifaces on AHR!  You even say so.

> No. An AHR may have 1, 2 or many many more interfaces....

I dont think you have agreement from the WG about this particular point.

Although I do agree with you on this particular point.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 10:39:11 +0100

On Oct 26, 2009, at 10:35 AM, Alexandru Petrescu wrote:

>>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at all  
>>>>>> -- but, of course, will affect AHRs and their interconnect.
>>>>>
>>>>> I agree.
>>>>>
>>>>> It currently does not address that requirement (at least not  
>>>>> with respect to link-local addresses).
>>>>>
>>>> So I'll wait for the rest of the WG to chime in -- I just  
>>>> explained my understanding of the charter.
>>>
>>> :-)
>>>

Yes, in this *example* that is very true, for the purpose of  
illustrating that point.

> I dont think you have agreement from the WG about this particular  

Hum, for 10+ years, we've been building MANETs with MANET routers  
(AHRs) having a single interface. Some have multiple interfaces too.  
That too has been supported for that long.

I don't think that anybody who's been building MANETs would be able to  
disagree on this particular point?

Thomas

>>>>>> Now, replace AHR with "OSPFv3-router" -- whatever OSPFv3- 
>>>>>> routers do between them (and whatever changes are introduced to  
>>>>>> OSPFv3) on OSPFv3 interfaces does not affect {a, b, c, d}.
>>>>>> "magic of a MANET routing domain" -- is isolated from the rest  
>>>>>> of the network by an IP hop. All the "ad hoc unaware parts of  
>>>>>> the system" see is a well-defined, unchanged, classic, legacy  
>>>>>> IP hop...
>>>>>> Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 10:52:50 +0100

> Yes, in this *example* that is very true, for the purpose of 

One of the most particular points in AUTOCONF drafts is that A-B-C 
problem where B is claimed to have only one interface.  It is one of the 
most important building blocks of the problem in AUTOCONF.

If it had 2 interfaces, then we had no such problem.

Alex

> Hum, for 10+ years, we've been building MANETs with MANET routers (AHRs) 
> having a single interface. Some have multiple interfaces too. That too 
> has been supported for that long.
>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 26 Oct 2009 10:58:27 +0100

Alex,

On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu <
[email-masked]> wrote:

> [...]

> One of the most particular points in AUTOCONF drafts is that A-B-C problem
> where B is claimed to have only one interface.  It is one of the most
> important building blocks of the problem in AUTOCONF.
>

What is a building block?

> If it had 2 interfaces, then we had no such problem.

As such, this sentence is wrong. B could have two (or more interfaces), and
still reach A and C over the same interface. Autoconf will have to support
multiple interfaces. And -- as Thomas showed in the example -- should not
have any effect on non-MANET interfaces.

Ulrich

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 11:00:53 +0100

On Oct 26, 2009, at 10:52 AM, Alexandru Petrescu wrote:

>>>>>>>> Whatever [autoconf] does should not affect {a, b, c, d} at  
>>>>>>>> all -- but, of course, will affect AHRs and their interconnect.
>>>>>>>
>>>>>>> I agree.
>>>>>>>
> problem where B is claimed to have only one interface.  It is one of  
> the most important building blocks of the problem in AUTOCONF.

An A, B, C are MANET routers in your example? If yes, then A, B, C  
(with whatever many interfaces they have) are aware of their MANET  
capabilities (just as an OSPFv3 router is aware of its OSPFv3  
capabilities)

The "single-MANET-interface-router" configuration is quite common in  
MANETs. I'd even go as far as saying that it's probably the most  
common configuration.

Duly note that we're only *interested* in MANET interfaces -- non- 
MANET-interfaces we've already agreed to not touch, they should  
operate as they always have.

> If it had 2 interfaces, then we had no such problem.

Oh yes, we still would.

Thomas

>> (AHRs) having a single interface. Some have multiple interfaces  
>> too. That too has been supported for that long.
>> I don't think that anybody who's been building MANETs would be able  
>> to disagree on this particular point?
>> Thomas
>>>>>>>> routers do between them (and whatever changes are introduced  
>>>>>>>> to OSPFv3) on OSPFv3 interfaces does not affect {a, b, c, d}.
>>>>>>>> This because the "magic of an OSPFv3 routing domain" -- and  
>>>>>>>> the "magic of a MANET routing domain" -- is isolated from the  
>>>>>>>> rest of the network by an IP hop. All the "ad hoc unaware  
>>>>>>>> parts of the system" see is a well-defined, unchanged,  
>>>>>>>> classic, legacy IP hop...
>>>>>>>> Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 11:08:37 +0100

Ulrich Herberg a écrit :
> Alex,
> 
> On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu 

Ok, it is a recurrent aspect motivating the AUTOCONF work, appearing 
several times in the AUTOCONF drafts.

> As such, this sentence is wrong. B could have two (or more interfaces), 
> and still reach A and C over the same interface.

:-)

> Autoconf will have to 
> support multiple interfaces. And -- as Thomas showed in the example -- 
> should not have any effect on non-MANET interfaces.

Ok - what happens if a non-MANET node connects to a MANET interface of a 
MANET router?

Do you forbid this case?

Do you care about this case?

If you do - then you should not discourage the IPv4 LLs of the non-MANET 
node.  You could discourage the IPv4 LLs of the MANET interface of a 
MANET node.

Or - this distinction is not made in the draft.  It is only made in our 
discussions.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Mon, 26 Oct 2009 11:08:42 +0100

> MANETs. I'd even go as far as saying that it's probably the most
Devices with more than one interface are much more expensive, so they are not 
as common as one-interface routers.

> > If it had 2 interfaces, then we had no such problem.
If we had only interfaces with "closed" broadcast domains life would be much 
easier... ;)

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-263,   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: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 11:11:47 +0100

Thomas Heide Clausen a écrit :
> An A, B, C are MANET routers in your example? If yes, then A, B, C (with 
> whatever many interfaces they have) are aware of their MANET 
> capabilities (just as an OSPFv3 router is aware of its OSPFv3 capabilities)
> 
> MANETs. I'd even go as far as saying that it's probably the most common 
> configuration.
> 
> Duly note that we're only *interested* in MANET interfaces -- 
> non-MANET-interfaces we've already agreed to not touch, they should 

Thomas - are you interested about what happens when a non-MANET node 
connects to a MANET interface of a MANET node?

If yes - then you should not forbid the IPv4 LLs on the non-MANET nodes. 
  You could discourage them on the MANET interfaces of the MANET nodes.

This distinction should be made in the draft.

>> If it had 2 interfaces, then we had no such problem.

Ok - the solution would be to route between the two interfaces.

Alex

>>>>>>>>> Now, replace AHR with "OSPFv3-router" -- whatever 
>>>>>>>>> OSPFv3-routers do between them (and whatever changes are 
>>>>>>>>> introduced to OSPFv3) on OSPFv3 interfaces does not affect {a, 
>>>>>>>>> b, c, d}.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 11:14:22 +0100

On Oct 26, 2009, at 11:08 AM, Alexandru Petrescu wrote:

> Ulrich Herberg a écrit :
>> Alex,
>> On Mon, Oct 26, 2009 at 10:52 AM, Alexandru Petrescu <[email-masked] 
>> As such, this sentence is wrong. B could have two (or more  
>> interfaces), and still reach A and C over the same interface.
>
> :-)
>
>> Autoconf will have to support multiple interfaces. And -- as Thomas  
>> showed in the example -- should not have any effect on non-MANET  
>> interfaces.
>
> Ok - what happens if a non-MANET node connects to a MANET interface  
> of a MANET router?
>

What happens if a non-OSPFv3 router connects to an OSPFv3 interface of  
an OSPFv3 router?

> Do you forbid this case?

In my networks, yes, I do not see the use of it. Furthermore, I see it  
as somewhat harmful as that means that an application bound to that  
"non-MANET node" would be exposed to the characteristics of a MANET,  
and may not be able to handle it.

Thomas

> If you do - then you should not discourage the IPv4 LLs of the non- 
> MANET node.  You could discourage the IPv4 LLs of the MANET  
> interface of a MANET node.
>
> Or - this distinction is not made in the draft.  It is only made in  
> our discussions.
>
> Alex
>
>> Ulrich
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 11:14:48 +0100

> If we had only interfaces with "closed" broadcast domains life would  

Yes, if only the world looked like an Ethernet.....

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 26 Oct 2009 11:16:33 +0100

On Oct 26, 2009, at 11:11 AM, Alexandru Petrescu wrote:

>>>>>>>>>>>>>> obviously, this topic is completely out of scope for  
>>>>>>>>>>>>>> the addressing model document, and even for the whole  
>>>>>>>>>>>>>> working group!
>>>>>>>>>>>>>
>>>>>>>>>> {a,b,c,d} and is a regular ethernet, with a, b, c and d  
>>>>>>>>>> being regular non-MANET hosts or routers. The other  
>>>>>>>>>> interface is a "MANET interface" towards other AHRs.
>>> problem where B is claimed to have only one interface.  It is one  
>>> of the most important building blocks of the problem in AUTOCONF.
>> The "single-MANET-interface-router" configuration is quite common  
>> in MANETs. I'd even go as far as saying that it's probably the most  
>> common configuration.

No. Just as I'm not interested in what happens if an Ethernet  
interface plugs into a Token Ring network.....

> If yes - then you should not forbid the IPv4 LLs on the non-MANET  
> nodes.  You could discourage them on the MANET interfaces of the  
> MANET nodes.
>

No, Ulrich explained well the issue - what you propose as "solution"  
has nothing to do with the problem.

Thomas

>>>> I don't think that anybody who's been building MANETs would be  
>>>> able to disagree on this particular point?
>>>> Thomas
>>>>>>>>>> routers do between them (and whatever changes are  
>>>>>>>>>> introduced to OSPFv3) on OSPFv3 interfaces does not affect  
>>>>>>>>>> {a, b, c, d}.
>>>>>>>>>> the "magic of a MANET routing domain" -- is isolated from  
>>>>>>>>>> the rest of the network by an IP hop. All the "ad hoc  
>>>>>>>>>> unaware parts of the system" see is a well-defined,  
>>>>>>>>>> unchanged, classic, legacy IP hop...
>>>>>>>>>> Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 11:48:43 +0100

Thomas Heide Clausen a écrit :
>> Ok - what happens if a non-MANET node connects to a MANET interface of 
>> a MANET router?
>>
> 

Err..., right, then the non-OSPFv3 router can not talk OSPFv3 to the 
OSPFv3 router.

This is a good example, because there is a way by which the non-OSPFv3 
router is not disturbed by the OSPFv3 messaging - it doesnt join the 
respective multicast group.

This avoidance by use of multicast is possible because both OSPFv3 and 
non-OSPFv3 routers follow the same rules about addressing.

If, e.g., the OSPFv3 router were to be specified to broadcast messages 
(ff02::1 instead of the ospf group), then the non-OSPFv3 router would be 
disturbed.

In the same way, the non-MANET nodes and the MANET nodes should follow 
the same addressing mechanisms, in order to not disturb each other.

Discouraging the use of link-local addresses is a significant departure 
from the current addressing scheme.

> "non-MANET node" would be exposed to the characteristics of a MANET, and 
> may not be able to handle it.

Well, I think your network - if you want to connect it to non-MANET 
nodes - should follow same addressing rules as the non-MANET nodes.  It 
should not discourage the use of LLs.

It could develop other ways of assigning global addresses, but don't 
discourage the existing ways.

If your new AUTOCONF mechanism uses a new link-local multicast group (as 
the MANET WG IANA document implies: link-local multicast group address 
ff02::6d) then I am not sure how are you going to forbid the link-local 
addresses, which have the same scope.  But that is another point about 
which I will write separately.

Alex

>> If you do - then you should not discourage the IPv4 LLs of the 
>> non-MANET node.  You could discourage the IPv4 LLs of the MANET

---

From: sratliff <[email-masked]>
Date: Mon, 26 Oct 2009 10:04:48 -0400

On 10/26/09 6:14 AM, "Thomas Heide Clausen" <[email-masked]> wrote:

>>> <[email-masked]

Thomas is correct. In fact, AFAIK, such a configuration won't work, as all
of the OSPFv3 MANET flooding optimizations won't interoperate with standard
flooding. 

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 15:07:22 +0100

> of the OSPFv3 MANET flooding optimizations won't interoperate with standard

I agree.  The way this works is that the non-OSPFv3 node is not impacted 
by the OSPFv3 messages because there exist multicast groups to which the 
  non-OSPFv3 node has not subscribed.

In the same way, we should do about MANET routers and non-MANET routers.

Alex

---

From: sratliff <[email-masked]>
Date: Mon, 26 Oct 2009 10:10:12 -0400

Sigh.... 

Simply ³enabling another interface², or ³hanging another radio on the
router² won¹t work in my deployments. My customers don¹t want 802.11; they
use other, proprietary technology. The radios are ridiculously expensive (in
excess of $100,000 each).

So can we please move on, and keep this from being a ³WiFi-only² discussion?

Regards,
Stan

On 10/26/09 5:58 AM, "Ulrich Herberg" <[email-masked]> wrote:

> <[email-masked]> wrote:
>> [...]
>  
> multiple interfaces. And -- as Thomas showed in the example -- should not have
> any effect on non-MANET interfaces.
> 
> Ulrich
> 
>