Subject: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 13 Nov 2009 16:44:54 +0100

Hi,

	In addition to my fundamental concerns that I've with this document and
that I've shared in different ways (I can do it again if considered
useful), I have a bunch of other not so fundamental ones:

	- Section 3: "The configuration proposed by this model is applicable to
any router's IP interface" --> I wonder if this should be changed to
"The configuration proposed by this model is applicable to any router's
IP MANET interface" or something like that. By saying "any router's IP
interface" it may seem that the configuration of "non-MANET" interfaces
would also follow the guidelines provided by the document (i.e., /128,
no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state
that the model is for MANET interfaces.

	- Section 4: "no two such interfaces in the network should be
configured with the same subnet prefix" --> this at least conflicts with
LLs. (I'm not bringing up __here__ again the LL issue, just pointing out
that the document should be revised to avoid this kind of contradictory
statements: "Note that while an IPv6 link-local address is assigned to
each interface as per [RFC4291]" and "no two such interfaces in the
network should be configured with the same subnet prefix".

	- Section 6.1: "These limitations are further exacerbated by the
smaller pool of IPv4 link-local addresses to choose from and thus
increased reliance on DAD" --> if link-locals are not considered and
"normal" DAD is not considered suitable for MANETs, I think this
sentence makes no sense and should just simply be removed.

	- Section 6.2: "Routers cannot forward any packet with link-local
source or destination address to other links..." --> this is rather
obvious and not particular of MANETs, why is this described in the
document?

	- Section 6.2: "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." --> this is not particular of MANETs
either, why is in the document?

	- Appendix A: "MANET Link Model" --> I don't believe in the existence
of a "MANET Link", and I don't see its relevance in an __address
autoconfiguration__ document. Repeating myself here... I think this
document and some discussions in the ML deviate from the charter goal:
we need to come up with a practical ____addressing____ architecture.
IMHO, we have been discussing instead about "IP over MANET", which to me
is a rather different thing (well, to me it doesn't even exist, if we
consider L3 MANETs).

	- Appendix A: "it remains to be determined whether or not the scope of
AUTOCONF includes applications other than routing protocols running on
the router" --> this is a very important question that we have brought
in the meeting. I have my personal opinion, but this is irrelevant,
since there seem to be a consensus (I wasn't aware of it, but Thomas
stated otherwise). I'd like to ask the chairs to bring this to the ML to
close this issue.

	This is all from my side for the time being.

	Thanks,

	Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 14 Nov 2009 06:10:36 +0900

Carlos,

> that the model is for MANET interfaces.

The idea is that you actually could configure any IP interface like  
that - but that it would be silly to do so if one has an interface  
with "determined connectivity properties". This should be captured in 3:

    The configuration proposed by this model is applicable to any
    router's IP interface.  It specifies IP addresses and IP subnet
    prefixes to be configured on network interfaces.

    When more specific assumptions can be made regarding the  
connectivity
    between interfaces, these SHOULD be considered when configuring
    subnet prefixes.

Especially, the last paragraph captures that I think.

> network should be configured with the same subnet prefix".

this is a good point.

> sentence makes no sense and should just simply be removed.

I liked Thaler's description of what we needed as ADD (Address  
Duplication Detection), in order to not confuse with other  
terminology ;)

> obvious and not particular of MANETs, why is this described in the

This is included as one of the reasons why LLs are of no particular  
use within a MANET: they can not be used as source IP for a datagram  
intended to be received by any other interface even within the MANET.

> either, why is in the document?

Same reason as above.

> is a rather different thing (well, to me it doesn't even exist, if we

I think that we agree, this whole appendix is obsolete and should be  
removed.

> stated otherwise).

Well, I believe that as someone said at the mike, that an addressing  
model is rather less interesting unless it enables running actual  
applications. I believe that we had a relatively simple way of putting  
this discussed at the meting, but we will see shortly (see below).

> I'd like to ask the chairs to bring this to the ML to
> close this issue.
>

I believe that was the plan from the [autoconf] meeting to bring a  
number of things forward. I've gotten the raw notes from our scribes,  
and will edit those to post meeting minutes on the 'list, then close  
any issues with everybody being well-informed ;)

> 	This is all from my side for the time being.

Thanks for your time and comments, they're very appreciated.

Thomas

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 13 Nov 2009 13:49:03 -0800

Hello Carlos,

An incomplete response:

> that the model is for MANET interfaces.
The point is that you _could_ use the constrained prefix assignment model
even for "non-MANET" interfaces.  But the constraint would inhibit 
aggregation
which is obviously useful in more non-MANET networks.  Nevertheless, except
for scalability, networks which COULD have aggregatable addresses would
still thereby be made to work without address aggregation.
> either, why is in the document?

I thought the point was to supply justification in case anyone
might ask why the prefix constraint was disfavoring the aggregation
of addresses into a common link.

> is a rather different thing (well, to me it doesn't even exist, if we

This is likely the heart of the problem.  A lot of people including me
have been running IP over MANET [perforce, layer-3] for years.
Then a great deal of controversy has been generated by people who
don't believe it can be done.  Which seems to suggest that they don't
believe the working group is viable in the first place.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 14 Nov 2009 01:15:38 +0100

This is not generating controversy, this is clarification.

Charles E. Perkins a écrit :
[...]
>> - Appendix A: "MANET Link Model" --> I don't believe in the 
>> existence of a "MANET Link", and I don't see its relevance in an 
>> __address autoconfiguration__ document. Repeating myself here... I
>>  think this document and some discussions in the ML deviate from
>> the charter goal: we need to come up with a practical 
>> ____addressing____ architecture. IMHO, we have been discussing 
>> instead about "IP over MANET", which to me is a rather different 
>> thing (well, to me it doesn't even exist, if we consider L3 
>> MANETs).
>> 
> 
> This is likely the heart of the problem.  A lot of people including 
> me have been running IP over MANET [perforce, layer-3] for years. 

Charles, I do believe IP can run on highly dynamic network topologies.
I trust you when you and Thomas say you did it.

Just say precisely how you did it.

For example, state when the experience was with IPv4 (not IPv6) and
don't make extrapolations from one to another.

Wireless link problems - yes, then state at least which link technology.

Host-based routes?  YEs, say it so, say how many nodes in the network,
say the number of entries in the routing tables and the prefixlen of the
destination field of each entry ("128"); but don't make it into a
recommendation of unique "/128" off-link prefix which makes no 4861ish
sense to me.

Your implementation didn't use IPv6 link-local addresses?  Ok, but don't
make that a prefered case recommendation.

State how DAD was there but overlooked.

Is DAD consuming too much bandwidth?  How much?

State how MLD and MDNS were there too and overlooked.

Were _some_ addresses manually configured? - if yes say it so.

Was there a topology?  Picture it.

Were there addresses on interfaces?

Were there some entries in some routing table entries?  Some connected
routes?

Were there some default routes?  Some ICMP Redirects?  They're paramount
importance.

Some virtual interface?

Now - are all and each of these things consensual between people having
had MANET experience?  I don't believe so.

It seems to me it is not a matter of having had the right or wrong
experience, just report as it was, and don't claim it to be consensual.
  We know it is not consensus.  I have seen the same statements of having
run MANET for years by people with _very_ different oppinions about
_how_ these MANETs should run.

Just don't make these sound as a consensual recommendation,  as the
document currently does - they break other things.  And don't export
these recommendations (avoid LLs, use unique "/128" off-link prefixes)
to other WGs, they make no sense there - their current documents already
fall outside the core of your recommendations.

(when I write "you" it's about the AUTOCONF practical addressing model
draft authorship).

Alex

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

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 15 Nov 2009 19:55:40 +0900

>that the model is for MANET interfaces.

Somewhat agreed. The problem is wording: what is MANET interface?
I say: interface with MANET protocol running. Then your suggestion
is also not completely correct. Interface to Wireless Link? Also
not completely correct, as there are many wireless links that do not 
have problems with on-link prefixes.

>network should be configured with the same subnet prefix".

Agreed.

>sentence makes no sense and should just simply be removed.

Yes, we should remove all references to DAD. It is to controversial.

>obvious and not particular of MANETs, why is this described in the

See my other posting. This is an important argument, as in the normal
case the link is expected to be somewhat stable, and there is an
interface down trigger to signal the link down. On xxx interfaces,
there is no such a trigger. And when nodes get out of range,
connections using LLs are affected while connections with non-LLs
are not.

>either, why is in the document?

We should remove this argument.

>existence

With having the draft-baccelli-autoconf-adhoc-addr-model, we can close
this issue.

>stated otherwise). I'd like to ask the chairs to bring this to the ML to

I think the consensus is that there are applications in a MANET. The MANET 
is not solely for running MANET protocols... .
It is also in the charter:
  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.

Teco.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 08:31:48 +0100

Hi Thomas,

On Sat, 2009-11-14 at 06:10 +0900, Thomas Heide Clausen wrote:
>    When more specific assumptions can be made regarding the connectivity

My point is that since some of the recommendations provided by the
document may imply modifications to standard protocols (such as
"discourage LLs --> modify/not use ND), doing this on regular interfaces
may affect regular hosts, and this is not allowed by the charter. I'd
prefer a different writing so autoconf addressing model refers only to
MANET interfaces (I know this term is not used in the document...).

> Duplication Detection), in order to not confuse with other
Fine, there have been also other terms proposed in the past. Whatever
that makes the text clearer.
> intended to be received by any other interface even within the MANET.

This is true for any kind of network. I don't see the value of that
text. Nobody is asking, AFAIK, to change the LL semantics (well, but
maybe those that discourage their use :-p).

> > either, why is in the document?

Some comment as above.

> I think that we agree, this whole appendix is obsolete and should be

OK.

> any issues with everybody being well-informed ;)

Good.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 08:36:05 +0100

Hi Teco,

> I say: interface with MANET protocol running. Then your suggestion

I agree with that definition. It is actually the one we used in our
draft.

> is also not completely correct. Interface to Wireless Link? Also

Why is it not correct?

> interface down trigger to signal the link down. On xxx interfaces,

Protocols should be designed to work without such triggers (actually
there are many cases win which these triggers are not available, even in
wired networks).

> connections using LLs are affected while connections with non-LLs

Well, this depends. If your IP one hop neighbour gets out of range, you
need to find a new one. If you are talking about TCP-alike connections
(connection oriented protocols), I agree, but in this case it is a bad
idea to use link-locals anyway, IMHO.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 08:43:45 +0100

Hi Charlie,

> still thereby be made to work without address aggregation.

Please, see my reply to Thomas's e-mail.

> of addresses into a common link.

I think the point of aggregation of addresses into a common link is more
an architectural issue, than an addressing issue. If we had agreed on
using an L2/L2.5 MANET model, then we could talk about this (and we
would not need autoconf probably). Once we decided to go for L3 MANETs
(which I agree), I think using the same prefix for different links is
not very appropriate. That's why I don't see the value in the text I
pointed out above.

> believe the working group is viable in the first place.

I agree with your comment. Just to avoid misunderstandings, I believe in
running IP over MANETs, but I also think it can be done without
modifying IP (but only minor parts required for example to avoid IP
address duplicates). Another clarification, I've also run IP over MANET
for several years, though my experience is much limited than yours and
others in this WG.

Thanks,

Carlos

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 09:12:59 +0100

Hi Carlos,

>> have problems with on-link prefixes.

My WLAN in IBSS mode is an example of an exception.
We need a term (or repeating long text) for "an interface to
other interfaces with undetermined connectivity".

>idea to use link-locals anyway, IMHO.

So we all agree that non-LLs are needed.
And working on that first, with /128 prefixes in the routing protocol.
This by configuring /128 on the interface, or override the off-link 
configured shorter prefix.

Teco.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 09:18:49 +0100

Hi Teco,

> My WLAN in IBSS mode is an example of an exception.

An exception of what? I think I'm missing something or getting lost or
both :)

> So we all agree that non-LLs are needed.

Sure.

> configured shorter prefix.

Using /128 in the routing protocol does not necessarily imply
configuring /128 on the interface, does it?

Thanks,

Carlos

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 09:35:21 +0100

Hi Carlos,

>-----Oorspronkelijk bericht-----
>Van: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
>Verzonden: maandag 16 november 2009 9:19
>Aan: Teco Boot
>CC: [email-masked]
>Onderwerp: RE: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-
>model-00
>
>Hi Teco,
>

It is about misuse of "MANET interface" or "interface to Wireless Link".
Both uses are not correct for what we intend to say.

MANET interface: interface with MANET running.
Could be Ethernet.

Interface to Wireless Link.
Could be WLAN IBSS.

>configuring /128 on the interface, does it?

OK. But the implication looks obvious to me.
I work with implementations that "manipulate" the configured prefix.
In my use case with attached hosts (ad hoc L2 radio device),
I need the HNA to get the L2 device reachable. Silly configuration,
and an example why I don't like the maximum prefix recommendation.
It results in implementations that doesn't deal with my use case.

Nevertheless, I think is a good idea to support configured maximum 
prefix lengths. It is also wise to support shorter prefixes as well.

Teco.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 10:47:42 +0100

Hi Teco,

> Interface to Wireless Link.

I see now. In my understanding, we can say that the model is for
applicable to MANET interfaces, and then use the same kind of text that
is already in the draft to say that for those MANET interfaces with well
known characteristics/properties (e.g., wired Ethernet) some
restrictions/consideration of the addressing model might not apply or
something like this...

Thanks,

Carlos

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 12:15:03 +0100

Hi Carlos,

>restrictions/consideration of the addressing model might not apply or

I was sleepy this morning. I meant WLAN BSS for an example of wrong
usage. This type of interface connected to a Wireless Link works OK.

WLAN in IBSS running MANET protocol is in scope.

Teco.