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

From: "Teco Boot" <[email-masked]>
Date: Tue, 5 Jan 2010 19:31:49 +0100

Did this mail reach any destination?
Teco.

>-----Oorspronkelijk bericht-----
>Van: Teco Boot [mailto:[email-masked]]
>Verzonden: maandag 4 januari 2010 20:08
>Aan: 'Thomas Heide Clausen'
>CC: '<[email-masked]>'
>Onderwerp: RE: [Autoconf] Working Group Last Call for draft-ietf-
>autoconf-addr-model-01
>
>Hi Thomas,
>
>To begin with: happy new year.
>
>And on your question, I expect the doc editors carefully check
>WGLC comments and update the doc.
>
>On this particular issue on 1-hop connectivity, the doc has the
>following text:
>>  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 exactly my requirement. But for IP packet exchange, there
>is a need for a routing table entry or neighbor cache entry for the
>destination. I dislike an addressing model where 1-hop connectivity
>dependents on a routing protocol. Meanwhile, it is perfectly right
>that a routing protocol overrides a routing table entry for a directly
>connected interface with a longer match entry, even when it is a
>multi-hop path.
>
>The mechanism I use decouples configured prefixes on the MANET
>interfaces and the advertised prefixes. With a default configuration,
>only the MANET interface address is advertised (e.g. a /32 prefix),
>even if a shorter subnet mask is configured on that interface. Today,
>it is not an autoconfigured configuration.
>
>The question is: do we want to support such functionality in Autoconf?
>This requires providing and configuring a subnet mask. For IPv6, this is
>not a big deal, we can use /64 and define a well known ULA or whatever.
>This is also proposed by others, e.g. draft-perkins-manet-autoconf:
>>  In case the node does not know any suitable prefix, it uses the
>>  MANET_PREFIX, with prefix length 64, reserved for this purpose.
>For IPv4, this draft suggests the 169.254/16, which was zero-config at
>that time. Now, it is clearly defined as link-local. Try to
>allocate 240/8? Or leave IPv4 for what it is? Other options?
>
>I hope this helps. Did it?
>
>Regards, Teco
>
>
>>-----Oorspronkelijk bericht-----
>>Van: Thomas Heide Clausen [mailto:[email-masked]]
>>Verzonden: zondag 27 december 2009 5:33
>>Aan: Teco Boot
>>CC: <[email-masked]>
>>Onderwerp: Re: [Autoconf] Working Group Last Call for draft-ietf-
>>autoconf-addr-model-01
>>
>>Teco,
>>
>>What are you, concretely, suggesting to do to the doc?
>>
>>Seasonal greetings,
>>
>>Thomas
>>
>>
>>On 24 Dec 2009, at 08:32, "Teco Boot" <[email-masked]> wrote:
>>
>>> 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.
>>>
>>>
>>>
>>> _______________________________________________
>>> Autoconf mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/autoconf

---

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Jan 2010 14:58:03 -0500

Two comments on this document.

The document uses but does not really define the term "routing
domain". It should define and/or explain what this term means and why
the term is important (in the context of this document).

> 6.1.  IPv6 Model
> 
>    For IPv6, the principles described in Section 4 and Section 5 suggest
>    the following rules:
> 
 ...
>    o  No on-link subnet prefix is configured on this interface.
> 

But:

> 6.2.  IPv4 Model
> 
>    For IPv4, the principles described in Section 4 and Section 5 suggest
>    rules similar to those mentioned for IPv6 in Section 6.1, that are:
> 
...
>    o  Any subnet prefix configured on this interface should be of length
>       /32.

I don't see a lot of difference between an IPv6 "on-link" prefix and
an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4
are treated differently.

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 7 Jan 2010 13:47:46 +0100

Hi Thomas,

Thanks for your review.

Happy new year.

I  will comment on one thing in your email, leaving the "routing  
domain" discussion for elsewhere.

On 5 Jan 2010, at 20:58, Thomas Narten <[email-masked]> wrote:

<snip>

> an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4

I believe that Dave Thaler mentioned that there in no definition of an  
"on link prefix" for IPv4, and that this is the reason for the text  
being thus different for v4 and v6.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 07 Jan 2010 08:31:53 -0500

> being thus different for v4 and v6.

It is more than the text being different. If the recommendation is
that in IPv4 you assign a /32 subnet prefix, than in IPv6 the
equivalent would be to set a /128 to the on-link prefix set.

Whether you call it a subnet prefix or on-link isn't the issue.

What I think doesn't make sense is to assign a prefix in IPv4 but say
not to do so for IPv6.

If that is in fact the intention, what is the technical justification?

Thomas

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 Jan 2010 12:25:40 +0100

> the term is important (in the context of this document).

We can reference RFC 1136 for this (but I'd hate to have to use the ISO 
"routeing" spelling, it just hurts my eyes).

> an IPv4 subnet prefix. It doesn't make sense to me that IPv6 and IPv4
I think I was the one who actively supported treating IPv6 and IPv4 
differently in the document. IPv6 has a ULA range, IPv4 doesn't. IPv4 
has a Private range, IPv6 doesn't. IPv4 global space is constrained, 
IPv6 isn't. IPv4 stacks remove IPv4 link-local addresses from an 
interface when a global or private is assigned, IPv6 stacks do not... 
etc... etc... So, while there certainly are commonalities in the models, 
there are enough differences that describing each model separately seems 
to reduce the chance of misunderstanding the differences that do exist 
between one version vs. the other.

- Mark

---

From: Thomas Narten <[email-masked]>
Date: Wed, 20 Jan 2010 08:51:12 -0500

Mark,

> has a Private range, IPv6 doesn't.

This isn't a real difference. Net 10 is "private" in IPv4 and spans
multiple links/subnets. That is no different than a ULA in IPv6.

Yes, there are some important differences between ULAs and net 10
addresses (namely global uniqueness), but that doesn't change how
prefixes out of those networks are assigned to individual links, and
whether they are to be treated as being on-link (or not), which is
what is at issue.

> IPv4 global space is constrained, IPv6 isn't. IPv4 stacks remove
> IPv4 link-local addresses from an interface when a global or private
> is assigned, IPv6 stacks do not...  etc... etc... So, while there
> certainly are commonalities in the models, there are enough
> differences that describing each model separately seems to reduce
> the chance of misunderstanding the differences that do exist between
> one version vs. the other.

This doesn't really answer my core question. There is no real
difference between a /32 in IPv4 and a /128 in IPv6. What is the
justification for saying /32 should be used in IPv4 but no on-link
prefix is used in IPv6?

BTW, I'd be fine with having the IPv6 section say on-link with a
/128. That is what I would have expected for consistency.

I don't think doing this is a big deal, unless you have IPv4 and IPv6
be different, with no good technical justification, which is how I see
things at the moment.

Thomas

---

From: Mark Townsley <[email-masked]>
Date: Wed, 20 Jan 2010 19:22:16 +0100

cc'ing Dave Thaler directly, I need his advice here. Please see inline...

Indeed, in the previous draft we had this text:

>    o  (An IPv6) subnet prefix configured on this interface should be 
> of length
>       /128.
> and
>
>    o  Any (IPv4) subnet prefix configured on this interface should be 
> of length
>       /32.

However, Dave convinced us at the last IETF that the better way in IPv6 
to describe what we really want to say is that on-link subnet prefixes 
should simply not be configured at all. Practically speaking, I don't 
think we have this same luxury in IPv4.

- Mark

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 21 Jan 2010 16:03:15 +0100

Hi Ronald,

On Wed, Dec 23, 2009 at 11:19 PM, Velt, R. (Ronald) in 't <
[email-masked]> wrote:

> All,
>
> Please find my comments below:
>
> <snip>

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 agree, this is more precise.

> 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."
>
>
>

Here too ;)

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

We're just to describe what addresses/prefixes are to be configured, on a
router's interface which does not have determined connectivity. How, and to
what the routers connect over such interfaces is out of scope for this
document, as far as I understand it.

> <snip>
>
> 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.
>

This is corrected ;)

Regards, and happy new year.

Emmanuel