Re: [netmod] ipv6 config parameters

[Ladislav Lhotka <[e-mail]>]

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.

Lada

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C