Re: [netmod] ipv6 config parameters

[Juergen Schoenwaelder <[e-mail]>]

On Mon, Nov 14, 2011 at 06:45:20PM +0800, Ladislav Lhotka wrote:
> 
> On Nov 14, 2011, at 6:36 PM, Juergen Schoenwaelder wrote:
> 
> > On Mon, Nov 14, 2011 at 06:14:32PM +0800, Ladislav Lhotka wrote:
> >> 
> >> On Nov 14, 2011, at 5:14 PM, Juergen Schoenwaelder wrote:
> >> 
> >>> On Mon, Nov 14, 2011 at 09:36:01AM +0100, Martin Bjorklund wrote:
> >>>> Hi,
> >>>> 
> >>>> Here are two issues for the draft-ietf-netmod-ip-cfg document.
> >>>> 
> >>>> 
> >>>> RFC 4862 (IPv6 Stateless Address Autoconfiguration) states:
> >>>> 
> >>>>  A node MUST allow the following autoconfiguration-related variable to
> >>>>  be configured by system management for each multicast-capable
> >>>>  interface:
> >>>> 
> >>>>    DupAddrDetectTransmits
> >>>> 
> >>>> Should we add this leaf to our data model?
> >>> 
> >>> If RFC 4862 says so...
> >>> 
> >>>> RFC 4861 (Neighbor Discovery in IPv6) states:
> >>>> 
> >>>>  A router MUST allow for the following conceptual variables to be
> >>>>  configured by system management.
> >>>> 
> >>>>    <list of a handful of config params>
> >>>> 
> >>>> Should we add these variables to our data model, conditional on an
> >>>> if-feature?    They are present in the IP-MIB.
> >>> 
> >>> The question here is what is in scope of this work and what is out of
> >>> scope. Are we limiting this data model to the configuration of
> >>> interfaces or do we include things happening on routers, like the
> >>> configuration of routing advertisements. In fact, if we take a broad
> >>> definition of the scope, we will have to work through
> >>> 
> >>> draft-ietf-6man-node-req-bis-11.txt
> >>> 
> >>> and all the mandatory stuff it references. And also 4941 comes into my
> >>> mind and there is ongoing work on source address selection and even
> >>> discussion today how to handle situations where you get potentially
> >>> conflicting information via RAs and DHCP. Since it is unlikely that we
> >>> will be successful covering everything configurable in the IP layer,
> >>> we should in my view have a plan how to put things into manageable
> >>> pieces.
> >> 
> >> Yes, that's why I don't want to have an ietf-ipv6-unicast-routing
> >> module as a part of the routing-cfg draft.
> > 
> > I am not sure I can follow you. What would ietf-ipv6-unicast-routing
> > cover? What do you have in mind?
> 
> Firstly, it should define analogical things as the ipv4-unicast-routing module now provides, such as IPv6 route content - in most cases this part would only require to replace inet:ipv4-{address,prefix} with the IPv6 counterpart.
> 
> But beyond that, a whole bunch of other IPv6-specific parameters would be needed, as you wrote above.
> 

OK. I think our disconnect is that I do not consider things like ND
parameters or RA config a subject of the routing module while you seem
to do. And it might be that the number of IPv4 knobs that do exist out
there is not necessarily much smaller than number of IPv6 knobs we
know about today.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>