Subject: [Autoconf] New I-D submitted

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 14 Jul 2009 00:02:55 -0700

Hello folks,

The autoconf design team has arrived at a documentation milestone,
with the publication of the following Internet Draft:
    
http://www.ietf.org/internet-drafts/draft-baccelli-autoconf-adhoc-addr-model-01.txt

 From the Abstract:

   This document describes a model for configuration of IP addresses and
   subnet prefixes on the interfaces of routers which connect to links
   with undetermined connectivity properties.

Indeed, the document is quite narrowly focussed, limited to discussing
only the issues minimally required for the working group to move forward.

Comments are encouraged!

Regards,
Charlie P.

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 14 Jul 2009 10:46:26 -0400

In section4, the authors state :
"Subnet prefix configuration on such interfaces must thus not make any
promises in terms of direct (one hop) IP connectivity to IP addresses
other than that of the interface itself. This translates in the
following policy: no two such interfaces in the network should be
configured with the same subnet prefix."

Later, in section 6.1 and 6.2, the authors get around to stating that
prefix length should be 32 bits for V4, 128 bits for V6. My question is
this -- Since prefix length really defines what is or isn't a "subnet",
why monkey around with all of the text up front? This looks like you
took 6 pages to say "For V4, use prefix length 32. For V6, use 128. Use
of V6 Link-locals? Beats us!" Or, am I missing something?

Regards,
Stan

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

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 14 Jul 2009 10:57:53 -0700

Hi all,

The agenda is available here.
http://www.ietf.org/proceedings/09jul/agenda/autoconf.txt

We have two hours slot for the AUTOCONF and will discuss the one  
charter item.
The design team published the initial document as Charlie announced.

In Appendix A, open issues are listed.
Please review this document and provide your comments.
Your proposal for the open issues are mostly welcome.

thanks,
Thomas&ryuji

Begin forwarded message:

> From: "Charles E. Perkins" <[email-masked]>
> Date: 2009/07/14 0:02:55:PDT
> To: "[email-masked]" <[email-masked]>
> Subject: [Autoconf] New I-D submitted
>
>
> Hello folks,
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 12:09:05 +0200

Dear AUTOCONFers,

I have read the draft-baccelli-autoconf-adhoc-addr-model-01
"IP Addressing Model in Ad Hoc Networks"

Authors of the draft-baccelli draft - thank you for putting up this
draft.  I followed the discussion on the DT list and realize there was
struggle for consensus and much work was done to reach agreement.

I have several remarks on it.

There is a slight difference between what the Charter
requires and what the draft offers.  The Charter requires to describe
how _nodes_ configure their addresses, whereas the draft sounds as
describing how one (a human) should or should not configure addresses on
these nodes.

Charter:
> [...] ad hoc nodes (refer to RFC 2501) need to configure their 
> network interface(s) with local addresses that are valid within an ad
>  hoc network. Ad hoc nodes may also need to configure globally 
> routable addresses [...]

draft:
> no two such interfaces in the network should be configured with the 
> same subnet prefix.[...] [in some cases] and the corresponding 
> interfaces MAY be configured with the same subnet prefix.

This sounds as advice to some human risking making a mistake and wrongly
configure prefixes on interfaces.

If it were formulated like "the autoconf mechanism should[n't] configure
  same/different prefix on an interface" then the text would be more
aligned with the Charter.

> 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.
[...]
> If on the contrary, assumptions can be made regarding connectivity to
>  other interfaces on the link, these SHOULD be considered when 
> configuring IP subnet prefixes, and the corresponding interfaces MAY 
> be configured with the same subnet prefix.

To my reading, the order of these two paragraphs is wrong.  The second
paragraph should be mentioned first.  The first paragraph should be
mentioned second, and _that_ should start with "If on the contrary".

I suggest that because I have a hard time imagining an interface which
enables no assumptions of the connectivity to other interfaces.  This is
a very special case, and as such I think it should be mentioned second.

> Configuring an IP address that is unique within the routing domain 
> satisfies the less stringent uniqueness requirements of local 
> uniqueness, while also enabling protocols which have the most 
> stringent requirements of uniqueness within the routing domain.  This
>  translates in the following policy: an IP address assigned to an 
> interface that connects to a link with undetermined connectivity 
> properties should be unique at least within the routing domain.

By extension, I can not understand how a link with undetermined
connectivity properties can be part of an apparently coherent routing
domain.  If the parts of the domain are undetermined then by logical
extension the routing domain is undetermined too.

> when that interface connects to a link with undetermined connectivity
>  properties.

Again, I do _not_ understand what  is a link with undetermined
connectivity properties.  I think you make abstraction of the existence
of link layers.

> o  A subnet prefix configured on this interface should be of length 
> /32.

I could agree with this recommendation for links with undetermined
connectivity properties.  But since I don't understand the latter I
can't accept the recommendation either.

I suggest to make first recommendation for links which have determined
connectivity properties, and then in later sections make recommendations
for links with undetermined connectivity properties.

The same for IPv6 section 6.2.

> MANET Link Model -  no satisfying MANET link model was formulated to
>  date.  Lacking a better definition so far, a MANET link is: a link 

I don't understand link with undetermined connectivity properties.  Are
you sure they're undetermined or are they simply unkown to this draft?

> Use of Link Local Addresses -  while the use of link local addresses
>  on interfaces connecting to a MANET link is not prohibited, the 
> semantics of "link local" in this context is yet to be defined, 
> taking into account the unusual requirements that follow, concerning 
> such addresses.  These requirements include for example uniqueness 
> within a scope spanning beyond a single IP hop.

I suggest reformulation and re-positioning of this paragraph.

IPv6 link-local addresses are mandatory, and are the first thing
self-configured by all implementations, before anything else.  Please
mention that.  Even on non-standardized IPv6-over-foo links, the
implementations do self-configure link-local addresses (like USB, and more).

"link local" is already defined.  It spans a link.  Links are already
defined.

I would suggest to remove this paragraph and re-write a new paragraph
about link-local addresses and position it near the beginning of the
draft, which says the first addresses configured by the nodes are the
IPv6 link-local addresses, before any other types of addresses.

Alex

Ryuji Wakikawa a écrit :
> charter item. The design team published the initial document as 
> Charlie announced.
> 
> In Appendix A, open issues are listed. Please review this document 
> and provide your comments. Your proposal for the open issues are 
> mostly welcome.
> 
> thanks, Thomas&ryuji
> 
> 
> Begin forwarded message:
> 
>> From: "Charles E. Perkins" <[email-masked]> Date: 
>> 2009/07/14 0:02:55:PDT To: "[email-masked]" <[email-masked]> 
>> This document describes a model for configuration of IP addresses 
>> and subnet prefixes on the interfaces of routers which connect to 
>> links with undetermined connectivity properties.
>> 
>> Indeed, the document is quite narrowly focussed, limited to 
>> discussing only the issues minimally required for the working group
>>  to move forward.
>> 
>> Comments are encouraged!
>> 
>> Regards, Charlie P.
>> 
>> 
>> _______________________________________________ Autoconf mailing 
>> list [email-masked] 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 16:33:48 +0200

|By extension, I can not understand how a link with undetermined
|connectivity properties can be part of an apparently coherent routing
|domain.  If the parts of the domain are undetermined then by logical
|extension the routing domain is undetermined too.

Many MANET protocols are out there and being used today.
This is the evidence you are missing something.
I suggested in DT to refer to an updated
draft-baccelli-multi-hop-wireless-communication. I think this document is
helpful, especially for you :-)

Teco.

|Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 16:37:48 +0200

|draft:
|> no two such interfaces in the network should be configured with the
|> same subnet prefix.[...] [in some cases] and the corresponding
|> interfaces MAY be configured with the same subnet prefix.
|
|This sounds as advice to some human risking making a mistake and wrongly
|configure prefixes on interfaces.
|
|If it were formulated like "the autoconf mechanism should[n't] configure
|  same/different prefix on an interface" then the text would be more
|aligned with the Charter.

We are not describing an Autoconf mechanism.
We tried to describe a practical addressing model for MANETs.
Charter:
> However, the first task of the working group is to describe
> one practical addressing model for ad hoc networks.

Teco.

|Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 16:47:21 +0200

> We are not describing an Autoconf mechanism.

Yes, right, no AUTOCONF mechanism described; I was trying to say that 
the Charter requires nodes to configure addresses whereas the draft 
reads as if humans configure those addresses on their interfaces.  A 
slight change in the formulation could make it more aligned to the Charter.

Instead of draft saying:
"no two such interfaces in the network should be configured..."
it could say:
"no two such interfaces in the network should configure"
because the Charter says:
"ad hoc nodes [...] need to configure their network interface(s)"

This is just a slight modification.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 21 Jul 2009 16:28:39 +0100

> the draft 
> reads as if humans configure those addresses on their interfaces.

Not to me.

> "no two such interfaces in the network should be configured..."

Nowhere does that say what or who does the configuration.
It thus applies whether configured by humans, software,
Martians, or anything else.

This form of wording is in many specifications.

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

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 17:37:49 +0200

|"link local" is already defined. It spans a link. Links are already
|defined.

We had lots of discussions on "what is a link?".

I defined some terms, but those were not included 
in the draft. Now we don't know if link-locals 
span the link. 

I do not agree on this. I say: packets with 
link-local source or destination are not forwarded. 
RFC4291:
>   Routers must not forward any packets with 
>   Link-Local source or destination addresses 
>   to other links. 
So if two interfaces on the same link do not have 
connectivity, your statement is false.

There was consensus on "MANET link". That term was 
used for a _line_ on some diagram. The MANET _cloud_ 
was "the link", i.e. the communication facility. The 
line indicates a (symmetric / bi-directional) connection 
between two nodes. On this diagram, the MANET link was 
not fully connected, so link-local does not span the link.

Teco.

|Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 17:44:32 +0200

Dearlove, Christopher (UK) a écrit :
>> the draft reads as if humans configure those addresses on their 
>> interfaces.
> 
> Not to me.
> 
>> Instead of draft saying: "no two such interfaces in the network 
>> should be configured..."
> 
> Nowhere does that say what or who does the configuration. It thus 
> applies whether configured by humans, software, Martians, or anything
>  else.
> 

...

draft says:
> This translates in the following policy: no two such interfaces in 
> the network should be configured with the same subnet prefix.

I think 'policy' is what people do and impose.

> these [assumptions] SHOULD be considered when configuring IP subnet
> prefixes

The capitalized 'SHOULD' makes me think it is for the implementer to 
read carefully when implementing.

I don't see DHCP SHOULD consider some assumptions.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 21 Jul 2009 16:49:05 +0100

> I think 'policy' is what people do and impose.

Policy may possibly be what people impose. It isn't what
people do. Google, for example, "policy based routing".
It's not humans doing the routing.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 18:09:40 +0200

Hi Stan,

|This looks like you <skipped> say 
   <skipped>
|Use of V6 Link-locals? Beats us!

I don't think it was someone's intention to start a competition.
I think some majority in DT had IPv4 in mind, and using 
link-locals in IPv4 is not an obvious choice for routers.

Some said the charter says "come up with a (single?) 
addressing model for MANETs". And because IPv4 
link-locals is not an obvious choice, here we have 
this outcome.

Yes, I think link-locals can be used in a MANET. 
But with limited use. And practical use. The argument 
against is that there are addresses needed for multi-hop 
communication also. And one could say: why using multiple
addresses where one can do the job? Others say all addresses
must be defended using DAD, whatever overhead is involved.

Nevertheless, IPv6 link-locals is fact of live. I am still
shocked due to suggestions stepping away from it.

Teco.

|Regards,
|Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 21 Jul 2009 18:33:00 +0200

Teco Boot a écrit :
> I defined some terms, but those were not included in the draft.

What are these definitions of a link?  Could you post them here?  Are
they related to the definition of link already in rfc4861?

> Now we don't know if link-locals span the link.
> 
> I do not agree on this. I say: packets with link-local source or
> destination are not forwarded.

That is true, I agree with this, it is an essential characteristic of 
link-local addresses.

>> RFC4291:
>> Routers must not forward any packets with Link-Local source or
>> destination addresses to other links.
> So if two interfaces on the same link do not have connectivity, your
> statement is false.

I assume two interfaces on the same link _do_ have connectivity.  I 
don't understand what you mean by two interfaces on the same link not 
having connectivity.

If you mean two interfaces on the same link _and_ not having 
connectivity then I believe they are not on the same link, and they are 
on two different links.

Being on the same link and being connected can't be dissociated.

> There was consensus on "MANET link". That term was used for a _line_
> on some diagram. The MANET _cloud_ was "the link", i.e. the
> communication facility. The line indicates a (symmetric /
> bi-directional) connection between two nodes. On this diagram, the
> MANET link was not fully connected, so link-local does not span the
> link.

I don't agree with this picture.

A link-local address reaches all nodes on the link.

If you want to define other meanings for "link-local" or for "link" then 
please do so.   We'll have to compare it against the one in rfc4861.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Jul 2009 19:18:37 +0200

|If you want to define other meanings for "link-local" or for "link" then
|please do so.   We'll have to compare it against the one in rfc4861.

My link definition is from 4861.

Here the terms I suggested before, with minor adjustment (comments Charlie):

===========

link       - a communication facility or medium over which nodes can
             communicate at the link layer, i.e., the layer
             immediately below IP. (out of RFC4861)

MANET link - 1-hop connectivity between two MANET interfaces. Called
             edge in graph theory.

MANET interface
           - MANET router interface with a MANET protocol enabled.

Radio link - a link with undetermined connectivity properties, such
             as asymmetry, non-transitivity and time-variation as
             described in
             [draft-baccelli-multi-hop-wireless-communication].
             Wireless links have often undetermined connectivity
             properties. 

Radio interface
           - MANET router interface to a Radio link.

===========

The term "MANET link" needs another thought. The word "link" in 
"MANET link" would be associated with term "link", and as pointed 
out this is confusing. I am OK on any better term, but I still 
can't come up with something. "MANET edge" ?? No, this wouldn't 
work.

Teco.

|
|Alex