Subject: [Autoconf] Working Group Last Call for draft-ietf-autoconf-addr-model-01

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 10 Dec 2009 02:37:03 +0100

All,

In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The  
editors have updated the document and issued draft-ietf-autoconf-addr- 
model-01 to reflect these discussions. The WG chairs have reviewed the  
document, and believe that this new version capture the discussion to  
our satisfaction.

In order to not drag out the WG process unnecessarily, we therefore  
hereby issue a Working Group Last Call on draft-ietf-autocon-addr-model:

	http://tools.ietf.org/wg/autoconf/draft-ietf-autoconf-adhoc-addr-model/

This Working Group Last Call runs until 09/12/23.

Please review the document carefully, and post your comments to [email-masked] 
  as soon as possible and before that deadline.

When you review the document, please pay specific attention to the  
changes which were included following the discussions in Hiroshima,  
and which were summarized in Appendix A (http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-01#appendix-A 
  - reproduced below):

	Appendix A.  Changes since -00

	   This section logs the main changes of this document since its last
	   version.  These are:

	   Facts on the needs of applications other than routing -  At the end
	      of the intro, added a disclaimer on the fact that apps other than
	      routing may need additional addresses (potentially plus prefixes,
	      and such, better global than local, but that the doc focuses only
	      on what is necessary for the routing protocols to be functional.

	   Modified list of issues pertaining to the use of LLs -  Removed DAD
	      issue as argument for why link-local addresses are not  
recommended
	      for use.  Other issues, that remain listed in this document, are
	      still sufficient to reach the same conclusion.

	   More precise expression of the model for IPv6 -  Reworded the "/128
	      IPv6 prefixes" recommendation into "there is no on-link prefix"
	      recommendation.

	   More precise expression of the applicability of the model -  Better
	      expression of recommendation that "if you know something about
	      reachability o addresses or interfaces" then you may leverage  
this
	      to configure an on-link prefix in the last paragraphs of  
section 3
	      and 4.

Sincerely,

Ryuji and Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 11 Dec 2009 13:04:37 +0100

Here my thoughts on the document in its current state.

I think the document describes a practical addressing model for ad hoc 
networks. I say _a_ practical addressing model, because I think there
are other practical models, e.g. a model that use link-locals or a model 
that use a common subnet prefix for each MANET segment. All such models
have their pro's and con's.

I think the document is restrictive in scope, it focuses solely on 
addresses for the MANET protocol and leaves open what to do for normal 
end-user applications. Do we need an additional document?
It does not say anything on the address types, e.g. use ULA of request 
something else.
The document leaves also open what address model applies to those parts
of the ad hoc network that have some determined connectivity properties.
It also does not address multi-homed scenarios.

Detailed comments:

Page 3:
   In general, global scope is desired
   over local scope, though it is understood that this may not always be
   achievable via automatic configuration mechanisms.
I don't understand why automatic configuration of globals is not achievable,
specifically when the network is attached to The Internet.

Page 4:
   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.
This is not in line with the scope of the document. The next sentence in
the document also argues against this statement.

Page 4:
   If L2 communication is enabled between a pair of interfaces, IP
   packet exchange is enabled regardless of the IP subnet configuration
   on each of these interfaces.
This is only possible if the IP stack is aware of the L2 link between the 
pair of interfaces. One way of establishing this is configure an on-link 
subnet prefix. Now we choose not to configure so, and instead run a MANET
protocol. But this makes IP communication dependent on the MANET protocol, 
which can have a negative effect on managing the network. Think of remote
management and updates on the MANET protocol.

Page 4:
   If on the contrary, assumptions can be made regarding the
   connectivity between interfaces, or regarding the persistent
   reachability of some addresses, these SHOULD be considered when
   configuring IP subnet prefixes, and the corresponding interface(s)
   MAY in such case be configured with an on-link subnet prefix.
There are scenarios where some tethered hosts do always have connectivity 
with a router, and connectivity to other nodes is undetermined. In such
cases, there should be used an off-link subnet prefix. The text says 
"should" and "may", so yes, the document is not incorrect. But it leaves
open many scenarios.

Page 5:
   link-local addresses are of
   limited utility on links with undetermined connectivity
There were debates on protocols that more or less require or depend on 
link-locals. Mentioned protocols are OSPF-MANET, ND and MLD.
On ND: RAs are sent with link-local source address.
This is also the case for NS to Solicited-Node Address (FF02:0:0:0:0:1:FFXX:
XXXX), using default source address selection.
And also, the default source address selection uses link-locals for MANET
Packets with LL-MANET-Routers destination address.

Page 5:
   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.
This argument is not specific to ad hoc networks at all. So I do not see
a reason to come up with it in this document.
There is no such standardized mechanism for non-link-locals either, so with
the same argument those address types cannot be used also !!!
However, there are proposals for ensuring unique InterfaceIDs, for example
for generating unique ULAs, and as a consequence such mechanism also 
ensures unique link-locals. So link-locals can be used to reliably identify
routers.
Link-locals have a limitation on reachability, and one may need reachable
router identifiers. In that case, link-locals cannot be used.

Page 5:
   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.
I agree on this. But the scope of the document is an addressing model used
by MANET protocols. MANET protocols use hop-by-hop information transfer, and

thus do not need more than link-locals provide.

Page 6:
   Note that the use of IPv4 link-local addresses [RFC3927] in this
   context should be discouraged for most applications, as the
   limitations outlined in Section 6.1 for IPv6 link-local addresses
   also concern IPv4 link-local addresses.  These limitations are
   further exacerbated by the smaller pool of IPv4 link-local addresses
   to choose from and thus increased reliance on DAD.
I think the main difference with IPv6 is that an IPv4 interface would not
have configured a link-local _and_ a routable address.
Also, what other, larger, pool of addresses is available? 

Regards, Teco.

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Thomas Heide Clausen
>Verzonden: donderdag 10 december 2009 2:37
>Aan: [email-masked]
>Onderwerp: [Autoconf] Working Group Last Call for draft-ietf-autoconf-
>addr-model-01
>
>All,
>
>and which were summarized in Appendix A
>(http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-
>01#appendix-A
>  - reproduced below):
>
>
>_______________________________________________
>Autoconf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/autoconf

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 21 Dec 2009 15:14:43 +0100

Hi,

here is my review on the draft.

I think that the document defines a good start into further work of
AUTOCONF, and I am all in favor for going ahead with the publication
of it. Some more detailed comments:

  * The document represents *a* practical addressing model, that works
for interfaces (such as used in MANETs) without planned topology, and
as such without any assumptions about connectivity between routers.
The document makes clear -- and this has been a major point of
discussion -- that when more assumptions about connectivity can be
made, other subnet prefixes can be configured on the interfaces.

  * The modified introduction, that includes a disclaimer about other
applications on the router or attached hosts, sets clear limits of the
scope of the document. Therefore, I think it was a useful addition to
the document. Once we agree on an addressing model and recharter
AUTOCONF, we should decide where to treat these addresses and prefixes
that are used by applications on the router or attached hosts.

  * Concerning the reworded /128 assumption, I think the new
formulation (proposed by Dave Thaler IIRC) is useful. Maybe, however,
the authors should add an explanation what that means in practice or
give an example how that can be achieved.

  * I agree with the modified part about link-local addresses.

  * The "Security Considerations" section is empty. Will the authors
add something in there?

Merry Christmas
Ulrich

On Thu, Dec 10, 2009 at 2:37 AM, Thomas Heide Clausen
<[email-masked]> wrote:
> All,
>
> In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The editors
> have updated the document and issued draft-ietf-autoconf-addr-model-01 to
> reflect these discussions. The WG chairs have reviewed the document, and
> believe that this new version capture the discussion to our satisfaction.
>
> In order to not drag out the WG process unnecessarily, we therefore hereby
> issue a Working Group Last Call on draft-ietf-autocon-addr-model:
>
>
> Please review the document carefully, and post your comments to
> [email-masked] as soon as possible and before that deadline.
>
> When you review the document, please pay specific attention to the changes
> which were included following the discussions in Hiroshima, and which were
> summarized in Appendix A
> (http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-01#appendix-A -
> reproduced below):
>
>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 22 Dec 2009 12:59:40 +0200

Hi,

I read through addr-model-01 and am happy with the changes. As with Ulrich, I am in favor of going ahead with publication.

- The text on the needs of applications other than routing and assignment to hosts is very useful and puts this draft into perspective, explaining exactly the kinds of things we are defining over in 6lowpan using this model as a reference. Thanks. 

- The change from /128 to "there is no on-link prefix" recommendation works well in my opinion. This is compatible with our use in 6lowpan. 

- I don't think that security section content is required for this document.  

Happy Holidays!
Zach

On Dec 10, 2009, at 3:37 , Thomas Heide Clausen wrote:

> All,
> 
> In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. The editors have updated the document and issued draft-ietf-autoconf-addr-model-01 to reflect these discussions. The WG chairs have reviewed the document, and believe that this new version capture the discussion to our satisfaction.
> 
> In order to not drag out the WG process unnecessarily, we therefore hereby issue a Working Group Last Call on draft-ietf-autocon-addr-model:
> 
> Please review the document carefully, and post your comments to [email-masked] as soon as possible and before that deadline.
> 
> When you review the document, please pay specific attention to the changes which were included following the discussions in Hiroshima, and which were summarized in Appendix A (http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model-01#appendix-A - reproduced below):
> 
> 
> 	      issue as argument for why link-local addresses are not recommended
> 	      reachability o addresses or interfaces" then you may leverage this
> 	      to configure an on-link prefix in the last paragraphs of section 3
> 	      and 4.
> 
> Sincerely,
> 
> Ryuji and Thomas
> 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 23 Dec 2009 23:19:39 +0100

All,

Please find my comments below:

I-D> Abstract
I-D> 
I-D>    This document describes a model for configuring IP addresses and
I-D>    subnet prefixes on the interfaces of routers which connect to
links
I-D>    with undetermined connectivity properties.

The scope of this document appears to be limited to router interfaces
used for talking to other routers, so maybe change to: "... on the
interfaces of routers which connect to other routers over links with
undetermined connectivity properties." (See also comment on section 3).

<snip>

I-D> 
I-D> 1.  Introduction
I-D> 
I-D>    The appropriate configuration of IP addresses and subnet masks
for
I-D>    router network interfaces is generally a prerequisite to the
correct
I-D>    functioning of routing protocols.  Consideration of various
items,
I-D>    including underlying link capabilities and connectivity,
geographical
I-D>    topology, available address blocks, assumed traffic patterns,
I-D>    etc. are used when determining the appropriate network topology
and
I-D>    the associated IP interface configuration.
I-D> 
I-D>    When the capabilities and connectivity of the links that connect
I-D>    routers are well-known and stable, logical network topology
design
I-D>    and corresponding IP interface configuration are
straightforward.
I-D>    Absent any assumption about link-level connectivity, however,
there
I-D>    is no canonical method for determining a given IP interface
I-D>    configuration.
I-D> 
I-D>    Link-level connectivity is generally qualified as undetermined
when
I-D>    it is unplanned and/or time-varying in character.  Ad hoc
networks
I-D>    are typical examples of networks with undetermined link-level
I-D>    connectivity.  Routing protocols for ad hoc networks have as
purpose
I-D>    to detect and maintain paths across the network, even when faced
with
I-D>    links with undetermined connectivity, assuming that routers'
I-D>    interfaces are configured with IP addresses.  This document thus
I-D>    proposes a model for configuration of IP addresses and subnet
I-D>    prefixes on router interfaces to links with undetermined
connectivity
I-D>    properties, to allow routing protocols to function.

As soon as these routing protocols have completed an initial round of
"detecting" and the "maintaining" of paths is in progress, said paths
may be put to use for the actual forwarding of user traffic. At each
intermediate router, this involves looking up next-hop addresses in the
FIB, retrieving the corresponding L2 destination addresses and sticking
the latter on the packets (frames, actually) to be forwarded. It stands
to reason that these next-hop addresses are the same ones as those for
routing protocol operation. (The alternative would be to use LL's as
next-hops!)

Suggest to change the last sentence of the paragraph above to: "... , to
allow routing protocols and data packet forwarding to function".

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

While the configuration of prefixes for general applications may be
separable from the configuration of prefixes and addresses necessary for
the operation of routing protocols, in my view the configuration of
addresses to be used as next-hops for data packet forwarding is not. So
again: "... necessary for routing protocols and data packet forwarding
to function."

<snip>

I-D> 
I-D> 
I-D> 3.  Applicability Statement
I-D> 
I-D>    The configuration proposed by this model is applicable to any
I-D>    router's IP interface.  It specifies IP addresses and IP subnet
I-D>    prefixes to be configured on network interfaces.

It seems to me, that the applicability of the model is restricted to
those IP interfaces that are used to connect to other routers. If this
is the case, the first sentence could be reworded as: "... is applicable
to any router's IP interface over which a routing protocol is run".

In general, both other routers and hosts could be reachable over some IP
interface of a router. See e.g. the first slide of Teco's presentation
in the Autoconf session at IETF-74 (San Francisco). Does the model
presented here rule out that possibility? If so, this should be stated.
Or is this still supportable, provided a different, additional IP
address is configured on the router's IP interface, for the purpose of
router-host communication?

Can we always assume that a different IP interface will be used for
router-host communication? During the long discussion on the ML about
the usability of link-locals, mention was made several times of devices
that are so resource-starved that they have neither a globally unique
MAC addresses nor a (pseudo)-random number generator. What if some poor
underprivileged router device has just a single radio interface as its
sole means of communication with both hosts and other routers? The
'tethered' hosts (term coined by Fred Templin; I called them 'satellite
hosts' initially) would have to share a common prefix with the router.

I-D> 
I-D>    When more specific assumptions can be made regarding the
connectivity
I-D>    between interfaces, or the (persistent) reachability of some
I-D>    addresses, these SHOULD be considered when configuring subnet
I-D>    prefixes.
I-D> 
I-D> 
I-D> 4.  IP Subnet Prefix Configuration
I-D> 
I-D>    If the link to which an interface connects enables no
assumptions of

s/enables/warrants/ ?

I-D>    connectivity to other interfaces, the only addresses which can
be
I-D>    assumed "on link", are the address(es) of that interface itself.
I-D>    Note that while link-local addresses are assumed to be "on
link", the
I-D>    utility of link-local addresses is limited as described in
Section 6.
I-D> 
I-D>    Subnet prefix configuration on such interfaces must thus not
make any
I-D>    promises in terms of direct (one hop) IP connectivity to IP
addresses
I-D>    other than that of the interface itself.  This suggests the
following
I-D>    principle:
I-D> 
I-D>    o  no on-link subnet prefix should be configured on such an
I-D>       interface.
I-D> 
I-D>    If L2 communication is enabled between a pair of interfaces, IP
I-D>    packet exchange is enabled regardless of the IP subnet
configuration
I-D>    on each of these interfaces.
I-D> 
I-D>    If on the contrary, assumptions can be made regarding the
I-D>    connectivity between interfaces, or regarding the persistent
I-D>    reachability of some addresses, these SHOULD be considered when
I-D>    configuring IP subnet prefixes, and the corresponding
interface(s)
I-D>    MAY in such case be configured with an on-link subnet prefix.
I-D> 
I-D> 
I-D> 5.  IP Address Configuration
I-D> 
I-D>    Routing protocols running on a router may exhibit different
I-D> 
I-D> 
I-D> 
I-D>    requirements for uniqueness of interface addresses; some have no
such
I-D>    requirements, others have requirements ranging from local
uniqueness
I-D>    only, to uniqueness within, at least, the routing domain.
I-D> 
I-D>    Configuring an IP address that is unique within the routing
domain
I-D>    satisfies the less stringent uniqueness requirements of local
I-D>    uniqueness, while also enabling protocols which have the most
I-D>    stringent requirements of uniqueness within the routing domain.
This
I-D>    suggests the following principle:
I-D> 
I-D>    o  an IP address assigned to an interface that connects to a
link
I-D>       with undetermined connectivity properties should be unique,
at
I-D>       least within the routing domain.
I-D> 
I-D> 
I-D> 6.  Addressing Model
I-D> 
I-D>    Section 4 and Section 5 describe principles for IP address and
subnet
I-D>    prefix configuration on an interface of a router, when that
interface
I-D>    connects to a link with undetermined connectivity properties.
The
I-D>    following describes guidelines that follow from these
principles,
I-D>    respectively for IPv6 and IPv4.
I-D> 
I-D> 6.1.  IPv6 Model
I-D> 
I-D>    For IPv6, the principles described in Section 4 and Section 5
suggest
I-D>    the following rules:
I-D> 
I-D>    o  An IP address configured on this interface should be unique,
at
I-D>       least within the routing domain, and
I-D> 
I-D>    o  No on-link subnet prefix is configured on this interface.

Or: Within the routing domain, the IP address configured on this
interface is only one out of its prefix that is configured on any
interface.

I-D> 
I-D>    Note that while an IPv6 link-local address is assigned to each
I-D>    interface as per [RFC4291], in general link-local addresses are
of
I-D>    limited utility on links with undetermined connectivity, as

And yet the LL-MANET-Router multicast address given by RFC5498 has
link-local scope. If the routing protcol instance (which in many cases
could be a 'daemon' running in user space) does not explicitly specify
the source address to be used when sending protocol packets to this
multicast address, chances are that the Operating System will pick a
link-local source address.

Furthermore, I agree with Teco's comment here on Neighbor Sollicitations
(which will be sent over router-to-router interfaces as part of user
data forwarding). These are sent to the Solicited-Node multicast
address, which has link-local scope. If RFC3484, Source Address
Selection, Rule #2 is followed, a link-local source address will be
picked for these NS.

I-D>    connectivity to neighbors may be constantly changing.  The known
I-D>    limitations are:
I-D> 
I-D>    o  There is no mechanism to ensure that IPv6 link-local
addresses are
I-D>       unique across multiple links, hence they can not be used to
I-D>       reliably identify routers.
I-D> 
I-D>    o  Routers cannot forward any packets with link-local source or
I-D>       destination addresses to other links (as per [RFC4291]) while
most
I-D>       of the time, routers need to be able to forward packets
to/from
I-D>       different links.

I completely agree with Teco's comment on this bullet. Routing protocol
messages / packets travel hop-by-hop.

I-D> 
I-D> 
I-D> 
I-D> 
I-D>    Therefore, autoconfiguration solutions should be encouraged to
I-D>    primarily focus on configuring IP addresses that are not IPv6
link-
I-D>    local.

While I don't think the "therefore" is entirely justified, I do agree
with the advice!

I-D> 
I-D> 6.2.  IPv4 Model
I-D> 
I-D>    For IPv4, the principles described in Section 4 and Section 5
suggest
I-D>    rules similar to those mentioned for IPv6 in Section 6.1, that
are:
I-D> 
I-D>    o  An IP address configured on this interface should be unique,
at
I-D>       least within the routing domain, and
I-D> 
I-D>    o  Any subnet prefix configured on this interface should be of
length
I-D>       /32.
I-D> 
I-D>    Note that the use of IPv4 link-local addresses [RFC3927] in this
I-D>    context should be discouraged for most applications, as the
I-D>    limitations outlined in Section 6.1 for IPv6 link-local
addresses
I-D>    also concern IPv4 link-local addresses.  These limitations are
I-D>    further exacerbated by the smaller pool of IPv4 link-local
addresses
I-D>    to choose from and thus increased reliance on DAD.
I-D> 
I-D> 
I-D> 7.  IANA Considerations
I-D> 
I-D>    This document has no actions for IANA.
I-D> 
I-D> 
I-D> 8.  Security Considerations
I-D> 
I-D>    This document does not describe any security considerations.

That's a tautology, as Charles P. already pointed out.

I-D> 
I-D> 
I-D> 9.  Normative References
I-D>

<snip>
 
I-D> 
I-D> 
I-D> Appendix A.  Changes since -00
I-D> 
I-D>    This section logs the main changes of this document since its
last
I-D>    version.  These are:
I-D> 
I-D>    Facts on the needs of applications other than routing -  At the
end
I-D>       of the intro, added a disclaimer on the fact that apps other
than
I-D>       routing may need additional addresses (potentially plus
prefixes,
I-D>       and such, better global than local, but that the doc focuses
only
I-D>       on what is necessary for the routing protocols to be
functional.

But user data packet forwarding is still overlooked.

I-D> 
I-D>    Modified list of issues pertaining to the use of LLs -  Removed
DAD
I-D>       issue as argument for why link-local addresses are not
recommended
I-D>       for use.  Other issues, that remain listed in this document,
are
I-D>       still sufficient to reach the same conclusion.
I-D> 
I-D>    More precise expression of the model for IPv6 -  Reworded the
"/128
I-D>       IPv6 prefixes" recommendation into "there is no on-link
prefix"
I-D>       recommendation.
I-D> 
I-D>    More precise expression of the applicability of the model -
Better
I-D>       expression of recommendation that "if you know something
about
I-D>       reachability o addresses or interfaces" then you may leverage
this

typo: reachability of addresses

I-D>       to configure an on-link prefix in the last paragraphs of
section 3
I-D>       and 4.
I-D> 
I-D> 
I-D> Appendix B.  Contributors
I-D> 
I-D>    This document reflects discussions and contributions from
several
I-D>    individuals including (in alphabetical order): Teco Boot, Ulrich
I-D>    Herberg, Thomas Narten, Erik Nordmark, Charles Perkins and Zach
I-D>    Shelby.

Perhaps add Dave Thaler?

I-D> 
I-D>

That's all. I can only hope that my comments will not all be dismissed
right away.

Season's greetings,
Ronald in 't Velt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
>Sent: donderdag 10 december 2009 2:37
>To: [email-masked]
>Subject: [Autoconf] Working Group Last Call 
>fordraft-ietf-autoconf-addr-model-01
>
>All,
>
>In Hiroshima, we discussed draft-ietf-autoconf-addr-model-00. 
>The editors have updated the document and issued 
>draft-ietf-autoconf-addr-
>model-01 to reflect these discussions. The WG chairs have 
>reviewed the document, and believe that this new version 
>capture the discussion to our satisfaction.
>
>In order to not drag out the WG process unnecessarily, we 
>therefore hereby issue a Working Group Last Call on 
>draft-ietf-autocon-addr-model:
>
>	
>When you review the document, please pay specific attention to 
>the changes which were included following the discussions in 
>Hiroshima, and which were summarized in Appendix A 
>(http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-mode
>l-01#appendix-A
>  - reproduced below):
>
>
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 24 Dec 2009 08:32:34 +0100

I have to add the issue on network operations (see my mail below).
For IPv6, a solution is using LLs. Not easy to handle, but it works.
But for IPv4, I can't find something working. And I did not receive 
any response on my mail.

Because I work on MANETs that are actually deployed, and those need
remote management, including a fall-back reachability option in cases
the MANET routing protocol is not running, I swapped back to the 
addressing model I used before, that is using a common prefix for all
interfaces to a MANET segment. I did not detect any problems with it.
I had problems with the /32: some of the boxes I use simply do not
support this, and when configured, I miss the fallback reachability.

No misunderstanding: I keep supporting the advertised /32 prefix,
advertised prefixes shall not overlap. This needs a function in the
MANET routing protocol, that is does not advertise the configured
prefix, but instead the /32 route (or a configured shorter prefix).
All MANET Routing protocol implementations I use support this 
function. 
Write down a standard, for what is widely deployed?

Regards, Teco

PS. I think Autoconf should work on IPv6. And the addressing model 
should work well for multi-homed MANETs. The current draft attempts
to define the model for both IPv4 and IPv6 and does not address the
multi-homed scenario at all. 

-----Oorspronkelijk bericht-----
Van: [email-masked] [mailto:[email-masked]] Namens
Teco Boot
Verzonden: dinsdag 8 december 2009 15:41
Aan: [email-masked]
Onderwerp: [Autoconf] 1-hop reachability depending on MANET protocol

When using the proposed addressing model, I faced a reachability 
problem between 1-hop neighbors, when the MANET routing protocol
was stopped. I couldn't start via the network, because the problem.

Luckily, there are link-locals.

Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sun, 27 Dec 2009 05:32:49 +0100

Teco,

What are you, concretely, suggesting to do to the doc?

Seasonal greetings,

Thomas