Subject: Re: [netmod] ip config issues

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 01 Nov 2011 14:56:26 +0100

On Fri, 28 Oct 2011 14:19:55 +0200 (CEST), Martin Bjorklund <[email-masked]> wrote:
> Hi,
> 
> I have posted a new version (-01) of the ip-config draft.  It is now
> possible to configure non-contiguous netmasks, as discussed
> previously.
> 
> There are a couple of other issues, not yet handled.
> 
> * ip-01 primary, secondary, and preferred address
> 
>   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)).

The last feature is IMO somewhat esoteric, but it shows how difficult it
will be to find a common denominator even for the few most popular
platforms. And here we are dealing with very basic stuff.

> 
>   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?
> 
> 
> * ip-02 iv6 auto-link-local-address leaf
> 
>   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.
> 
>   Q. Is this a useful (and implementable) parameter?

Hmm, probably it is not a good idea at all because the link-local
address is used e.g. in neighbor discovery, so it could break IPv6
operation.

What could be useful is a switch for enabling/disabling stateless address
autoconfiguration, as it is done e.g. in Linux via

/proc/sys/net/ipv6/conf/<interface>/accept_ra

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

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Nov 2011 15:26:03 +0100 (CET)

> platforms. And here we are dealing with very basic stuff.

Is it esoteric?  It seems quite useful to me.

We need to define a model that is useful, but not too limiting for
people that want to add esoteric stuff.

But I am still not sure my understanding of these parameters is
correct.

> address is used e.g. in neighbor discovery, so it could break IPv6

Well, if we had a auto-link-local-address leaf, we would require the
operator to configure a link-local address manually, if he sets
auto-link-local-address to false.

> autoconfiguration

This would include the link-local address, right?  Also, RFC 4862
require a configuration variable DupAddrDetectTransmits.

Should we also add an 'enabled' leaf under ipv6, so that if
ipv6 is enabled, by default the address autoconfiguration process runs
and assigns a link-local address?

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 1 Nov 2011 10:53:05 -0400

>platforms. And here we are dealing with very basic stuff.

A lot of flags like this seem esoteric until you find out the
number of customers that use them ;^)

>>     default source on interface

I think there's a default for the subnet and multiple
subnets per interface, and the only way go out an
interface is either a subnet-based route or an interface-specific
request ("ping 10.1.1.1 interface fe-1/1/1"), so you need both.
You also need the idea of a default address for the entire
device, which is also in the strange-but-not-rare category.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 01 Nov 2011 17:51:47 +0100

Dne 1.11.2011 15:26, Martin Bjorklund napsal(a):
> Ladislav Lhotka<[email-masked]>  wrote:
>> On Fri, 28 Oct 2011 14:19:55 +0200 (CEST), Martin Bjorklund<[email-masked]>  wrote:
>>> Hi,
>>>
Well, I have never seen multiple addresses belonging to the same IP 
subnet configured on the same interface. But I have also never seen 
non-contiguous netmasks - I do admit academic networking is special.

> people that want to add esoteric stuff.

Yes, but there is potentially no end of esoteric features, knobs, bells 
and whistles, so perhaps we can leave such stuff to vendors who want to 
please their customers and also to differentiate from their competitors. 
At the end of the day, I think we will have to determine - actually for 
all modules we aim to develop - what is the canonical "IETF 
configuration model" for the given subsystem, otherwise we may never get 
to an end.

> auto-link-local-address to false.

Yes, but I don't really see any motivation for doing so. Is there any 
implementation that allows this?

> require a configuration variable DupAddrDetectTransmits.

I mean addresses configured from router advertisements, I don't know 
whether they can include link-local addresses (I doubt it).

> and assigns a link-local address?

What's normally done is that if IPv6 is enabled, a link-local address is 
configured for each interface and hosts (not routers) also accept RAs 
from which they configure a global address and default route. But while 
listening to RAs may be disabled even for hosts, I am not sure it is 
possible to disable creation of EUI-64-based LL addresses.

What about making "ipv6" a presence container? If it is present, LL 
address would be configured on that interface.

  Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Nov 2011 10:12:24 -0700

>> Ladislav Lhotka<[email-masked]> wrote:
...
> Yes, but there is potentially no end of esoteric features, knobs, bells and whistles, so perhaps we can leave such stuff to vendors who want to please their customers and also to differentiate from
> their competitors. At the end of the day, I think we will have to determine - actually for all modules we aim to develop - what is the canonical "IETF configuration model" for the given subsystem,
> otherwise we may never get to an end.
> ...

I agree with Lada.
The first order problem is "what to standardize".
Our goal is to do common things in a common way.

If at least two vendors roughly agree to implement a knob then it
may be worth standardizing.  If zero or one vendor is willing
to implement the knob, then why bother standardizing it?
We have YANG augment-stmt for a reason.

>> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 01 Nov 2011 19:44:30 +0100 (CET)

> Our goal is to do common things in a common way.

Absolutely!  In this particular case, the problem ("primary address")
was brought up by Lada, and Phil acknowledged the need for it, so it
makes sense to discuss it.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 01 Nov 2011 12:50:14 -0700

On 11/01/2011 11:44 AM, Martin Bjorklund wrote:
> Andy Bierman<[email-masked]>  wrote:
>> I agree with Lada.

OK -- I think multiple vendors support this under different names.
I think in general it is good to gauge implementation interest
for everything wrt/ [mandatory, if-feature, optional, deferred, rejected] status.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 03 Nov 2011 09:26:04 +0100

> makes sense to discuss it.

Agreed, we have to decide what knobs are generally needed. In this 
particular case of source address selection, IPv6 provides relatively 
clear guidelines (RFC 3484) while in IPv4 this seems to be 
underspecified, which opened space for vendor creativity (btw. Linux 
"ip" utility has its share of esoteric features, too).

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 07 Nov 2011 16:40:24 +0100

Hi,

after reconsidering all pros and cons, I think the best option is to leave
the scope of the ip-cfg draft (and contents of the module) as it is, even
though I previously suggested some extensions.

WRT primary, preferred etc.: Simple devices should be fine with the
existing data model - they either don't have the source address
selection problem at all, or can use a non-configurable selection
algorithm. For routers etc., these flags can easily be added via
augmenting.

WRT non-contiguous mask: I still think it's an esoteric insanity but, as
Tom Petch pointed out, standards leave it as an option, albeit with
reservations. So it should probably stay in the module because it would
otherwise be difficult to obtain it via augmenting.

I think it is quite important to get this module out of the doors asap.

Lada

PS. The typo "familiy" I found in -00 is still present in -01 (twice).

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C