Subject: [netmod] ip-cfg-02

From: Martin Bjorklund <[email-masked]>
Date: Wed, 08 Feb 2012 13:42:23 +0100 (CET)

Hi,

I have posted an updated version of the ip-cfg draft.

There are still some open issues; see the attached file and please
comment on these issues.

/martin
* ip-01 primary, secondary, and preferred address [open]

  Lada suggested that we need to specify the primary address on an
  interface, and he pointed to the solution of two router vendors for
  doing this.  Phil sent some links to Juniper's documentation.

  It seems to be that these two vendors have the same terminology, but
  different meaning of the term "primary address".  In one case it
  seems to be the source address used for all outgoing packets on the
  interface, and in the other it seems to be the source address used
  for outgoing multi- and broadcast packets.

  Phil also mentioned "preferred address", which seems to be the
  source address used for outgoing unicast packets on the *subnet*
  (i.e., there can be one "preferred address" per subnet on an
  interface (I think)).

  So it seems there are two concepts here:

    default source on interface

    default source in subnet

  Q.  Is my understanding correct?

  Q.  If it is, do we need any, both, or more of these concepts?

  This was discussed at IETF-82.  From the minutes:

    JS: Trying to summarize.  It seems to be important that the
        application running on the box can choose the source address.
        It is less clear that we need something per interface.

** Solution #ip-01.01

  Do not add any configration parameters for this.

* ip-02 ipv6 auto-link-local-address leaf [open]

  Lada suggested that maybe there should be a way to tell the server
  to not automatically assign a link-local unicast address for an ipv6
  interface, as defined in RFC 4862.

  Q. Is this a useful (and implementable) parameter?

** Solution #ip-02.01

  If it is decided to do this...

    container ipv6 {
      ...
      container autoconf {
        ...
        leaf create-link-local-address {
          type boolean;
          default true;
          description
            "When create-link-local-address is false, a link local
             unicast address MUST be configured.";
        }
      }
    }

** Solution #ip-02.02

  Since RFC 4862 does not mention that this should be configurable, do
  not add such a leaf.

* ip-03 ip enable knob [open]

  It seems useful to have a knob to enable ipv6 on an interface.  When
  enabled, stateless address autoconfiguration (RFC 4862) can run.

  Same for ipv4?  IP-MIB has such objects (ipv4InterfaceEnableStatus
  and ipv6InterfaceEnableStatus).

  (See also ip-02).

** Solution #ip-03.01

    container ipv6 {
      ...
      leaf enabled {
        type boolean;
        default true;
        description
          "Controls if IPv6 is enabled or disabled on this
           interface.";
      }
    }

  Ditto for IPv4.

* ip-04 ipv6 parameters for stateless address autoconfiguration [closed]

  RFC 4862, section 5.1. states:

    A node MUST allow the following autoconfiguration-related variable to
    be configured by system management for each multicast-capable
    interface:

      DupAddrDetectTransmits

  Q. Should we add this leaf?

** Solution #ip-04.01

      container autoconf {
        ...
        leaf dup-addr-detect-transmits {
          type uint32;
          default 1;
          description
            "The number of consecutive Neighbor Solicitation messages
             sent while performing Duplicate Address Detection on a
             tentative address.  A value of zero indicates that
             Duplicate Address Detection is not performed on tentative
             addresses.  A value of one indicates a single
             transmission with no follow-up retransmissions.";
          reference
            "RFC 4862: IPv6 Stateless Address Autoconfiguration";
        }
      }

  This issue was discussed at IETF-82.  The conclusion there was that
  this leaf is needed.

** Resolution

  Adopted #ip-04.01

* ip-05 ipv6 parameters for neighbor discovery [open]

  RFC 4861, section 6.2.1. states:

    A router MUST allow for the following conceptual variables to be
    configured by system management.

  Q. Should we add these leaf, conditional on a feature "ipv6-router"?

  This issue was discussed at IETF-82.  The conclusion there was that
  these objects are needed.

** Solution #ip-05.01

  Yes, we should add these parameters, but in the routing document.
  (Note that in SNMP land, these objects are defined in IP-MIB)

* ip-06 add a feature for ipv6 hosts [open]

  RFC 4862 specifies that the creation of global addresses applies
  only to hosts, not to routers.  Thus, should we add a feature for
  ipv6 hosts?  It would be used in the create-global-addresses leaf:

        leaf create-global-addresses {
          // Open Issue #ip-06: should we have a feature here?
          //if-feature ipv6-host;
          type boolean;
          default true;
          description
            "If enabled, the host creates global addresses as described
             in section 5.5 of RFC 4862.";
          reference
            "RFC 4862: IPv6 Stateless Address Autoconfiguration";
        }

  Question.  In RFC 4862 a host is defined as a node that is not a
  router, and a router is defined as a node that forwards IP packets.

  In the IP-MIB (and in some well known OSes), ip forwarding is a
  writable knob, i.e. if a node is a router or host could change
  dynamically.  If this is correct, we cannot make this a YANG
  feature.

** Solution #ip-06.01

  Yes, add this feature.

** Solution #ip-06.02

  No, instead move all host-related parameters to a separate module.

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Feb 2012 16:58:55 +0100

...

>  Q.  If it is, do we need any, both, or more of these concepts?

For IPv6, RFC 3484 doesn't require the source address to be configurable, just states that "some unspecified tie-breaker should be used" if the source address selection algoritm fails to choose a unique address.

So IMO neither of these concepts is strictly necessary.

>        It is less clear that we need something per interface.

I agree with this.

>  Since RFC 4862 does not mention that this should be configurable, do

RFC 4862:
  "If a node determines that its tentative link-local address is not
  unique, autoconfiguration stops and manual configuration of the
  interface is required."

This seems to be the only case where an operator might want to disable the automatic LL address. This situation should however be very rare, and can be handled by the DAD procedure even if the automatic LL address is not explicitly disabled.

So my preferred solution is #ip-02.02.

>          "Controls if IPv6 is enabled or disabled on this

+1

>  This issue was discussed at IETF-82.  The conclusion there was that

+1

>  (Note that in SNMP land, these objects are defined in IP-MIB)

+1. I can do it in the next revision of the routing document.

>  No, instead move all host-related parameters to a separate module.

** Solution #ip-06.03

Define the "ip-forwarding" knob and use a dynamic default for           "create-global-addresses": "true" if ip-forwarding is disabled and "false" if ip-forwarding is enabled.

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 09 Feb 2012 16:09:26 +0100

...

I agree with this.

RFC 4862:

+1

+1

** Solution #ip-06.03

Lada

---

From: Tina TSOU <[email-masked]>
Date: Thu, 09 Feb 2012 19:16:51 +0000

Sent from my iPad

> So IMO neither of these concepts is strictly necessary.
Would u give example of how u configure default source here?

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 9 Feb 2012 21:42:10 +0100

> Would u give example of how u configure default source here?

What do you mean by "here"? The case when the 3484 rules don't provide a unique address? I think that Linux, for example, chooses the address that was configured last.

Lada

---

From: Tina TSOU <[email-masked]>
Date: Thu, 09 Feb 2012 22:53:58 +0000

Tina

> -----Original Message-----
> From: Ladislav Lhotka [mailto:[email-masked]]
> Sent: Thursday, February 09, 2012 12:42 PM
> To: Tina TSOU
> Cc: Martin Bjorklund; [email-masked]
> Subject: Re: [netmod] ip-cfg-02
> 
> 
> >> For IPv6, RFC 3484 doesn't require the source address to be
> configurable, just states that "some unspecified tie-breaker should be
> used" if the source address selection algoritm fails to choose a unique
> address.
> >>
> What do you mean by "here"? The case when the 3484 rules don't provide a
> unique address? I think that Linux, for example, chooses the address that
> was configured last.
I meant the example default value of 
default source on interface
default source in subnet

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 10 Feb 2012 09:10:40 +0100 (CET)

Hi Tina,

This is regarding one of the open issues.  The question is if we need
to standardize a mechanism to configure the "primary" address.  During
the discussion about this issue, we identified at least two (maybe
three) different concepts:

    default source in subnet

(The third is the ability to specify the source for a particular
service, e.g. use 10.0.0.1 as source when you talk to the radius
server, but 10.0.0.2 when you talk to the syslog server).

The question now is *if* we should standardize a solution to these
problems or not.  I believe Lada said "no".

/martin

P.S. Here's the complete issue description again.

    default source in subnet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Feb 2012 09:27:29 +0100

> problems or not.  I believe Lada said "no".

I think Lada said no to "default source on interface" and "default
source in subnet". It still seems desirable to be able specify the
default source applications/servers use. (But this is likely just a
guideline for people to consider who do data models for application
protocols/services - perhaps we should find a place to capture such
things to consider when doing YANG configuration data models.)

/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: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Feb 2012 10:41:47 +0100

> server, but 10.0.0.2 when you talk to the syslog server).

Yes, a BGP implementation will also most likely include the possibility to configure the source address.

> problems or not.  I believe Lada said "no".

Right.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Feb 2012 10:45:42 +0100

> things to consider when doing YANG configuration data models.)

Do you mean this should be done in the ip-cfg module or elsewhere?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 10 Feb 2012 11:48:03 +0100

> Do you mean this should be done in the ip-cfg module or elsewhere?

The systems I am familiar with seem to have this as a service specific
option, likely because the service implementation takes extra care to
implement this. So I do not think the ip-cfg module should solve this.

/js (as contributor)

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Feb 2012 13:02:44 +0100

> implement this. So I do not think the ip-cfg module should solve this.

Agreed. Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 10 Feb 2012 16:50:10 +0100

Hi,

I think the ietf-ip module should also define operational state data for:

1. Autoconfigured IPv6 addresses.

2. Per-interface host variables as required by RFC 4861 (sec. 6.3.2): LinkMTU, CurHopLimit, BaseReachableTime, ReachableTime and RetransTimer.

Moreover, sec. 5.1 in the same RFC expects each host to maintain the following conceptual data structures: 
- neighbor cache
- destination cache
- prefix list
- default router list

These structures are global rather than per-interface so they do not fit into the ietf-ip module in its current form. It looks like we also need a new module, say "ip-host-cfg".

Lada

---

From: Tina TSOU <[email-masked]>
Date: Fri, 10 Feb 2012 17:27:49 +0000

Sent from my iPad

>> implement this. So I do not think the ip-cfg module should solve this.
Agreed. Thank u for the clarification.

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 11 Feb 2012 13:23:55 +0100 (CET)

Hi,

Ladislav Lhotka <[email-masked]> wrote:
> 2. Per-interface host variables as required by RFC 4861 (sec. 6.3.2): LinkMTU,
> CurHopLimit, BaseReachableTime, ReachableTime and RetransTimer.
> 

I believe most of these are present in IP-MIB, as read-only objects.
Some are not, probably for a good reason.

So this gets us into the question if it is a good idea to redo
work already put into MIBs in YANG.  For configuration data, the
question has already been answered, but not for non-config.

> These structures are global rather than per-interface so they do not fit into
> the ietf-ip module in its current form. It looks like we also need a new
> module, say "ip-host-cfg".

No need for another module; the current module can define global
structures as well.

/martin