Re: [Autoconf] Working Group Last Call fordraft-ietf-autoconf-addr-model-01

[Emmanuel Baccelli <[e-mail]>]

Hi Ronald,


On Wed, Dec 23, 2009 at 11:19 PM, Velt, R. (Ronald) in 't <
[e-mail]> 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