Subject: [netmod] ipv6 config parameters

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Nov 2011 09:36:01 +0100 (CET)

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?

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.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2011 17:04:03 +0800

> Should we add this leaf to our data model?

I'd say yes as every node is required to implement it.

> if-feature?    They are present in the IP-MIB.

IMO this could go to the ietf-ipv6-unicast-routing module. It doesn't exist yet, my idea was that am IPv6-related WG (6man) would develop it. These variables could augment the /rt:routing/rt:router container.

Lada

> 
> 
> /martin
> 
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2011 10:14:34 +0100

> Should we add this leaf to our data model?

If RFC 4862 says so...
 
> 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.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Nov 2011 10:13:09 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> IMO this could go to the ietf-ipv6-unicast-routing module. It doesn't
> exist yet, my idea was that am IPv6-related WG (6man) would develop
> it. These variables could augment the /rt:routing/rt:router container.

But they are specified in 4861 to be per interface.  Also, is
v6-unicast really the right place to put it?

I think it makes sense to put them in this document, but I would very
much welcome input from 6man.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2011 10:32:38 +0100

> v6-unicast really the right place to put it?

I agree.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2011 17:51:37 +0800

> But they are specified in 4861 to be per interface.  Also, is

Each "router" entry in the routing-cfg module represents a self-contained (virtual) router, so configuration of its interfaces has to be done specifically for each entry, i. e. under /rt:routing/rt:router, with leafref references to the "interfaces" subtree. For example, each virtual router may define a different value for CurHopLimit.

> v6-unicast really the right place to put it?

As soon as a server advertises the "ipv6-routing"  feature, it should also implement some nodes analogical to what the ipv4-unicast-routing module provides.

> much welcome input from 6man.

I think it would require more than just implementing these variables. For example, a neighbor cache (state data) should be implemented, too.

My concern is that including v6 neighbor discovery would delay the publication of the ip-cfg module.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2011 18:14:32 +0800

> we should in my view have a plan how to put things into manageable

Yes, that's why I don't want to have an ietf-ipv6-unicast-routing module as a part of the routing-cfg draft.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2011 11:36:31 +0100

On Mon, Nov 14, 2011 at 06:14:32PM +0800, Ladislav Lhotka wrote:
> 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?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2011 18:45:20 +0800

> 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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 14 Nov 2011 12:04:28 +0100

> 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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 14 Nov 2011 12:17:29 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> > 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. 
> > 
> to do.

Section 12 of draft-ietf-6man-node-req-bis-11 says:

   This section defines general host considerations for IPv6 nodes that
   act as routers.  Currently, this section does not discuss routing-
   specific requirements.

and then it talks about ND and RA etc.  So I believe we should not
blur this distinction.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 14 Nov 2011 22:40:04 +0800

> and then it talks about ND and RA etc.  So I believe we should not

I don't mind if we agree on another organization, but I think it should be done in the same way for IPv4 and IPv6. So probably you should also define the contents of IPv4 & IPv6 unicast routes in the ip-cfg module. For IPv4, it is currently done in the ipv4-unicast-routing module.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C