Subject: [netmod] review of draft-ietf-netmod-ip-cfg-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 10 Jun 2012 15:48:53 +0200

I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my
comments/questions.

a) p1: I am wondering whether the title is correct. The document
   really is concerned with the configuration of IP interfaces as far
   as I understand it. It does not do routing and it also leaves out
   configuration things such as reassembly timers, default TTLs, etc.
   So would a more accurate title be "A Yang Data Model for IP
   Interface Configuration"? And if so, should the module name become
   ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip?

b) Should there be an Acknowledgements section? We have quite some decent
   reviews...

c) s/create-temporary-addressed/create-temporary-addresses/

d) p5:

   The objects ipNetToPhysicalTable and ipAddressStatus are writable in
   the IP-MIB but do not represent configuration, and are thus not
   mapped to the YANG module.

   This seems odd. Static address mappings can typically be configured
   and some people do this (either for security or performance
   reasons). As far as I understand things in the Linux world, address
   mappings seem to be interface specific.

e) p6: s/2011/2012/

f) p10: If I do not what autoconf address at all, I have to set all
   create-* leaves to false? Should there be a global switch? Not
   sure, just asking...

g) p13: Should there be text discussing ipv4/forwarding and
   ipv6/forwarding? Or the impact of the autoconf knobs?

h) p14: Are the references RFC6241, RFC6242 really normative?
        The routing document I think has RFC6241 and RFC 6242 as
        informative. Perhaps we should also explicitely refer to
        RFC6536 or even encourage its implementation.

i) Add IPv6 config to the example?

/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: "Alexander Clemm (alex)" <[email-masked]>
Date: Mon, 11 Jun 2012 17:30:17 -0700

I have also reviewed the draft and just a few questions/comments:

p6 leaf enabled:  I am not entirely clear about the semantics of this
leaf.  What happens if enabled is set to "false" - is this equivalent to
the entire container being absent?  
Another way of phrasing this is, why is this leaf required at all - why
not simply make container ipv4 a presence container - if it is present,
ipv4 is enabled, if not, it is not.  

p8 leaf enabled - same comment for IPv6 as for IPv4

General - presumably ipv6 be assumed to be ubiquitous and supported by
any device that supports Netconf, still the question if there is a need
to declare an ipv6 feature?  

Thank you
--- Alex

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Juergen Schoenwaelder
Sent: Sunday, June 10, 2012 6:49 AM
To: [email-masked]
Subject: [netmod] review of draft-ietf-netmod-ip-cfg-03

b) Should there be an Acknowledgements section? We have quite some
decent
   reviews...

d) p5:

e) p6: s/2011/2012/

/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/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jun 2012 12:54:52 +0200 (CEST)

>    ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip?

Do we want to add global parameters such as default TTLs?  If not, I
do not mind changing the title.

> b) Should there be an Acknowledgements section? We have quite some decent

Absolutely, now added.

> c) s/create-temporary-addressed/create-temporary-addresses/

Fixed.

>    mappings seem to be interface specific.

For some discussion/questions, see
http://www.ietf.org/mail-archive/web/netmod/current/msg06514.html.

ipNetToPhysicalTable says:

     As the entries in this table are typically not persistent
     when this object is written the entity SHOULD NOT save the
     change to non-volatile storage.

which is why I did not include this.

> e) p6: s/2011/2012/

Fixed.

>    create-* leaves to false? Should there be a global switch? Not

I think we discussed this but can't find any notes.  So, should there
be an option to disable stateless autoconfiguration on an ipv6-enabled
interface?

>    ipv6/forwarding? Or the impact of the autoconf knobs?

RFC 4293 has text for ipForwarding and ipv6IpForwarding, so we should
probably have something similar.  What would the security impact be
for the autoconf parameters?

>         RFC6536 or even encourage its implementation.

Yes.  Same as for ip-cfg.

> i) Add IPv6 config to the example?

Ok.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 12 Jun 2012 13:14:30 +0200

> do not mind changing the title.

I do not know how much bigger this makes the project...

> which is why I did not include this.

Well, that might be true for the MIB. I happen to run boxes that have
static mappings and I happen to run boxes that do proxyarp stuff. I am
not saying this has to be included or not, I was however somewhat
irritated by the reasoning. Seems we need to settle what the real
scope of this data model is.

> be an option to disable stateless autoconfiguration on an ipv6-enabled

I guess someone needs to check what the IPv6 specs really say about
this. I have boxes that have static IPv6 addresses configured and I
would prefer them to ignore any wired RAs on those links.

> for the autoconf parameters?

The reason we use statically configured IPv4 and IPv6 addresses on our
servers is to improve their robustness. We considered moving to static
address mappings as well but did not go there (yet). If you use
autoconfig, then you have to trust something and whether that trust is
justified is something to consider.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jun 2012 13:18:32 +0200

> do not mind changing the title.

Then there are also the global operational data structures from sec. 5.1 of RFC 4861: neighbor cache, etc. I think it is better to add the necessary global data and leave the scope of the I-D and module as "core IP".

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 12 Jun 2012 13:37:58 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> Then there are also the global operational data structures from
> sec. 5.1 of RFC 4861: neighbor cache, etc. I think it is better to add
> the necessary global data and leave the scope of the I-D and module as
> "core IP".

So what is the "necessary global data" we should add?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 12 Jun 2012 13:57:11 +0200

> So what is the "necessary global data" we should add?

They are specified in said RFC:

1. neighbor cache
2. destination cache
3. prefix list
4. default router list

The latter two are in the routing module but the former two aren't.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Jun 2012 08:02:51 +0200 (CEST)

> The latter two are in the routing module but the former two aren't.

But RFC 4861 specifies these as data structures per interface.  So
even if we add those Juergen's comment still applies.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 25 Jun 2012 08:30:36 +0200 (CEST)

> > > I have reviewed draft-ietf-netmod-ip-cfg-03 and here are my

[...]

> not saying this has to be included or not

Ok.  So let's ask the question:  Do you think we should include
configuration parameters for this?  If so, do you have a suggestion
for the data model?

> , I was however somewhat
> irritated by the reasoning.

The text talks about the relationship to the MIB, so it reflects the
MIB definition.

> would prefer them to ignore any wired RAs on those links.

Actually, since create-temporary-addresses is false by default, there
is really just one leaf you have to set to false.  So adding another
leaf to control this leaf is probably overkill.

> justified is something to consider.

I will need help with this.  Could you suggest a paragraph to add?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Jun 2012 11:45:50 +0200

> But RFC 4861 specifies these as data structures per interface.  So

Right, although it seems strange. In the implementations I am aware of, the data structures for 1, 2 and 4 (routing table, forwarding table, routing cache) are global. Only "prefix list" is clearly per-interface.

> even if we add those Juergen's comment still applies.

Juergen's comment certainly applies.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jun 2012 14:28:49 +0200

> Right, although it seems strange. In the implementations I am aware of, the data structures for 1, 2 and 4 (routing table, forwarding table, routing cache) are global. Only "prefix list" is clearly…

Junos seems to configure arp entries on an interface. Both, Cisco and
Linus seem to have an interface (sometimes called device) as a
mandatory argument. While the kernel may just have one table, I think
it is safe to follow RFC 4861, no?

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Jun 2012 16:51:27 +0200

> it is safe to follow RFC 4861, no?

I think it is generally useful to be able to see the entire ARP table without being forced to iterate over all interfaces, but also have options to filter the data, e.g. to view the entries for a selected interface.

This way we can satisfy 4861 requirements, too, because we keep the necessary information for each interface even though the underlying data structure is global.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jun 2012 17:13:39 +0200

> This way we can satisfy 4861 requirements, too, because we keep the necessary information for each interface even though the underlying data structure is global.

We are talking about configuration.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Jun 2012 17:25:30 +0200

> We are talking about configuration.

We should talk about both operational state data and configuration, and 4861 clearly talks about state data. But even for configuration, I am not convinced that having manually configured ARP entries spread over different places is a good design.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 25 Jun 2012 18:20:12 +0200

On Mon, Jun 25, 2012 at 05:25:30PM +0200, Ladislav Lhotka wrote:
> We should talk about both operational state data and configuration,
> and 4861 clearly talks about state data. But even for configuration,
> I am not convinced that having manually configured ARP entries
> spread over different places is a good design.

The title of the I-D is "A YANG Data Model for IP Configuration" and I
think that is by intention. 

If static ARP (or ND) entries are associated with an interface, it
perhaps starts to make sense that they appear/disappear when that
interfaces is configured/unconfigured. At least one router vendor
seems to be doing it that way.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 Jun 2012 19:06:40 +0200

> think that is by intention.

Hmm, this interpretation surprises me. So the state data tables are intentionally left out? I think it is quite important that the client have a way for querying the tables, either using generic <get> or via a special RPC method.
  
> seems to be doing it that way.

In FreeBSD, the '-i' option is only applicable to display operations of the arp(8) command (as a filter). In Linux, it can be optionally specified also when setting a manual entry. If it is not, the kernel will assign it to the interface that happens to be configured with the corresponding prefix. By forcing manual ARP entries to be bound to interfaces, we lose this kind of semantics.

Lada

---

From: t.petch <[email-masked]>
Date: Tue, 26 Jun 2012 11:49:45 +0100

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Juergen Schoenwaelder" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, June 25, 2012 3:51 PM
> >> Right, although it seems strange. In the implementations I am aware
of, the data structures for 1, 2 and 4 (routing table, forwarding table,
routing cache) are global. Only "prefix list" is clearly per-interface.
> I think it is generally useful to be able to see the entire ARP table
without being forced to iterate over all interfaces, but also have
options to filter the data, e.g. to view the entries for a selected
interface.

View yes, but that is a function of the viewing software.  The routers I
am familiar with have a table per interface, and may well have the same
IP address on two different interfaces with different L2 addresses, so
in a combined view, I expect the table to include a column for the
interface, and it does.  Of course, the underlying implementation may be
a single table with a column for the interface as well, but however it
is achieved, I see interface as a part of the table entry.

Tom Petch

>
> This way we can satisfy 4861 requirements, too, because we keep the
necessary information for each interface even though the underlying data
structure is global.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 26 Jun 2012 21:24:39 +0200 (CEST)

Hi,

>    ietf-ip-interfaces (prefix ip-if) rather than just ietf-ip?

Going back to this one - should we explicitly limit the scope of this
to IP interface config (and thus rename the module and document), or
is it ok as it is?  Personally I think the current title is fine; if
we want to add more (non-interface specific) stuff in the future we
would revise this document.  But I can also live with the more limited
scope and title.  So what do others think?

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 10:17:36 +0200

> scope and title.  So what do others think?

It might be a reasonable plan to call the module ietf-ip with the
understanding that we likely will have to add stuff to it that we
leave out in the first revision. But if that is the plan, it might be
worth spelling it out for instance in the Introduction, e.g. by
stating that the first revision of this data model focusses on IP
interface configuration and that it is expected to future revisions
will add more knobs to configure IP. It might also be useful to spell
out in the Introduction that IP routing related configuration objects
are defined in the routing data model. Having some more text in the
introduction likely helps to set the expectations right.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 11:11:16 +0200

> configuration parameters for this?  If so, do you have a suggestion

It is not clear what the WG things about it since only a few people
commented. More input would help.

> leaf to control this leaf is probably overkill.

OK, consider this closed.
 
> I will need help with this.  Could you suggest a paragraph to add?

Here is a first attempt to provide constructive input:

ipv4/forwarding and ipv6/forwarding: These nodes control whether IP
  packets are forwarded on this interface. By disabling or enabling
  forwarding on a interface, an attacker might impact network
  connectivity.

ipv6/autoconf: The leafs in this branch control the autoconfiguration
  of IPv6 addresses and in particular whether temporary addresses are
  used or not. By modifying the corresponding leafs, an attacker might
  impact the addresses used by a node and thus the indirectly the
  privacy of the users using the node.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Jun 2012 12:25:14 +0200 (CEST)

> introduction likely helps to set the expectations right.

Ok, I expanded the Introduction by 300%!   This is the new text:

    This document defines a YANG ^RFC6020^ data model for
    configuration of IP implementations.
    
    The initial version of this data model focuses on configuration
    parameters for interfaces.  It is expected that future revisions of
    this data model might add other kinds of IP configuration parameters.
    
    Configuration parameters to control IP routing are defined in
    ^I-D.ietf-netmod-routing-cfg^.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jun 2012 12:50:50 +0200

[...]
     
>     this data model might add other kinds of IP configuration parameters.

I would remove the might here. The phrase "is expected" already makes
this conditional. Or even shorter (but reducing your expansion score a
bit):

    Future revisions of this data model might add other kinds of IP
    configuration parameters.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 27 Jun 2012 21:57:27 +0200 (CEST)

> commented. More input would help.

With some input from Juergen, here's a sketch of a data model to
configure static ip-to-link-layer mappings, one for ipv4 and one for
ipv6:

  augment "/if:interfaces/if:interface" {
    container ipv4 {
      // as currently defined in the draft
      ...
      list arp { // name?
        key "ip";
        // entries end up as static arp cache entries
        leaf ip {
          type inet:ipv4-address;
        }
        leaf phys-address {
          type yang:phys-address;
        }
      }
    }
    container ipv6 {
      // as currently defined in the draft
      ...
      list neighbor { // name?
        key "ip";
        // entries end up as static neighbor cache entries
        leaf ip {
          type inet:ipv6-address;
        }
        leaf phys-address {
          type yang:phys-address;
        }
      }
    }
  }    

So, what do people think?  Should something like this be included in
this data model?  It seems most OSes / systems implement this
functionality, and it is supported in the IP-MIB.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jun 2012 08:28:23 +0200

> functionality, and it is supported in the IP-MIB.

As we discussed earlier, implementations allow for configuring static ARP or neighbor cache entries either globally (IOS, *BSD) or per interface (JUNOS), and some allow both (Linux). By having this configuration under "if:interface" we are losing the former option. So I would prefer the global variant, which is more general because each entry can contain an "interface-ref" leaf to make the entry interface-specific.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 09:11:55 +0200

> As we discussed earlier, implementations allow for configuring static ARP or neighbor cache entries either globally (IOS, *BSD) or per interface (JUNOS), and some allow both (Linux). By having this…

Which system allows ARP / ND entries to be configured that are not
associated with an interface?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Jun 2012 12:42:55 +0200 (CEST)

> > functionality, and it is supported in the IP-MIB.

First of all - do you think we should add something like this to the
configuration model?  I know you have talked about adding the neighbor
cache, but I always thought you meant only monitoring of the neighbor
cache.

> As we discussed earlier, implementations allow for configuring static
> ARP or neighbor cache entries either globally (IOS, *BSD) or per
> interface (JUNOS), and some allow both (Linux). By having this
> configuration under "if:interface" we are losing the former option. So
> I would prefer the global variant, which is more general because each
> entry can contain an "interface-ref" leaf to make the entry
> interface-specific.

In Junos it is even configured per address (subnet) per interface.
This makes sense since if you configure a mapping for an IP address
that is not part of your subnets, this mapping will never be used.  In
fact, also linux checks that the static arp entry belongs to your
subnet.

I didn't want to put it under address, since this would require you to
configure a static address - OTOH on systems where you use static arp
entries you probably also use static IP addresses...

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 12:56:51 +0200

> fact, also linux checks that the static arp entry belongs to your

My Debian and Ubuntu boxes (kernel 2.6.32) apparently do this without
any checks:

$ sudo ip neigh add 1.1.1.1 lladdr 01:02:03:04:05:06 dev eth1
$ sudo ip neigh add 2442::4224 lladdr 01:02:03:04:05:06 dev eth1

Note 1.1.1.1 is not meaningful on the subnet nor is 2442::4224.
 
> entries you probably also use static IP addresses...

Probably but not necessarily. I would not force this.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Jun 2012 13:04:36 +0200 (CEST)

> $ sudo ip neigh add 2442::4224 lladdr 01:02:03:04:05:06 dev eth1

Interesting.  arp -s gives an error if you try this.

Ok, so know we know we should use 'ip' to implement this data model on
linux ;)

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 28 Jun 2012 13:13:22 +0200

> fact, also linux checks that the static arp entry belongs to your

Yes, but it is done dynamically, so the same (global) static ARP entry remains valid even after the interface changes its name.

ARP entries represent information about external devices, so it is not a property of a particular interface. The linkage to an interface is only indirect - without having an interface on the same IP subnet, the local device has no way for using that information.

A device may also have multiple connections to the same subnet, and then the ARP entry should be equally valid for all connected interfaces.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 28 Jun 2012 13:14:21 +0200 (CEST)

> Interesting.  arp -s gives an error if you try this.

Ok, I should have RTFM.  If -i is not given it will consult the
routing table, and can't find the interface.  Sorry for the noise.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 13:38:02 +0200

> Ok, so know we know we should use 'ip' to implement this data model on

Apparently, arp used an ioctl to create the entry while the ip utility
talks via a netlink socket to the kernel. The ioctl interface seems to
check while the netlink interface does not.

Well, here is likely why. The command

sudo arp -s 1.1.1.1 01:02:03:04:05:06

does not identify an interface. Hence, the kernel most likely uses the
IP address to find the interface. If you specify the interface

sudo arp -i eth1 -s 1.1.1.1 01:02:03:04:05:06

then even Linux arp does what it is told to do. (And if you want to do
fancy proxyarp stuff, being able to create arbitrary arp entries might
even be useful.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 28 Jun 2012 13:44:06 +0200

On Thu, Jun 28, 2012 at 01:13:22PM +0200, Ladislav Lhotka wrote:
> 
> 
> ARP entries represent information about external devices, so it is
> not a property of a particular interface. The linkage to an
> interface is only indirect - without having an interface on the same
> IP subnet, the local device has no way for using that information.

I would argue that the mapping information is only valid on a certain
interface. I have never seen arp entries that are not associated to an
interface. The IP subnet linkage does not seem to really exist, at
least not on Linux. And if you do strange proxyarp stuff, you might
even do proxyarp for devices that do not belong to the subnet you are
using on that specific interface.

> A device may also have multiple connections to the same subnet, and
> then the ARP entry should be equally valid for all connected
> interfaces.

I would have to try this to see what kernels really do. I assume they
use the interface specific mapping and might likely have duplicate
entries in the arp table for the different interfaces.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 29 Jun 2012 14:00:55 +0200 (CEST)

Hi,

So far, I have not seen a single reply in favor of adding this feature
to the data model, so right now it seems to me we should not add this.

/martin

---

From: Carl Moberg <[email-masked]>
Date: Fri, 29 Jun 2012 14:33:50 +0200

I'll bite. I think we should add this feature to the data models since I believe there are use cases for it in VM-heavy data centers where dynamic ARP processes need to be kept to a bare minimum. I think that case is important enough and since the feature is supported in most mainstream OSes I think it should go into the standard model.

--
Carl Moberg, Tail-f Systems
mailto:[email-masked]
twitter: @cmoberg
http://www.tail-f.com/

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 29 Jun 2012 16:51:19 +0200

> using on that specific interface.

Yes, you are right, each neighbour entry is indeed associated with an interface.
Looking into kernel source, the neigh_create() function has a "dev" parameter which is a pointer to a device/interface. Sorry for the noise.

I now support the neigbour discovery additions proposed by Martin.

Lada