Subject: [netmod] RFC 7277: ip-address-origin

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Dec 2016 14:33:04 +0100

Hi,

I think that one important enum is missing in the "ip-address-origin" typedef:

  enum link-local {
    description
      "Indicates a link-local address.";
    reference
      "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses
       RFC 4291: IP Version 6 Addressing Architecture";

Would an erratum be possible/useful?

Lada

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Dec 2016 14:39:42 +0100

Lada,

when would I use link-layer and when link-local? Perhaps all needed is
a clarification of the description of link-layer? (Perhaps link-local
would have been a better name but too late now...)

An RFC 3927 address could also be a 'random' address. In fact, the
169.254/16 prefix kind of hings at RFC 3927 addresses falling under
'random'.

/js

On Fri, Dec 16, 2016 at 02:33:04PM +0100, Ladislav Lhotka wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 16 Dec 2016 13:40:38 +0000

Semantically, link-local seems more like a type of address than the origin
of the address. Also, the enum already has the type ³link-layer².

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 16 Dec 2016 13:42:27 +0000

On 12/16/16, 8:39 AM, "netmod on behalf of Juergen Schoenwaelder"
<[email-masked] on behalf of

>169.254/16 prefix kind of hings at RFC 3927 addresses falling under

Actually, I think Œrandom¹ is a more semantically correct classification
for RFC 3927 addresses than the proposed Œlink-local¹.

Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Dec 2016 14:59:59 +0100

> On 16 Dec 2016, at 14:39, Juergen Schoenwaelder <[email-masked]> wrote:
> 
> Lada,
> 

The distinction between SLAAC and link-local address is IMO also important.

> would have been a better name but too late now...)

That's why I believe the draconian update rules in sec. 11 of RFC 7950 are seriously counterproductive (at this stage at least). We should simply fix such mistakes and omissions in a new revision of ietf-ip, because otherwise the modules will soon be full of rubbish.

> 169.254/16 prefix kind of hings at RFC 3927 addresses falling under

OK, so adding 3927 to "reference" should suffice in this case.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 16 Dec 2016 15:05:34 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> That's why I believe the draconian update rules in sec. 11 of RFC
> 7950 are seriously counterproductive (at this stage at least). We
> should simply fix such mistakes and omissions in a new revision of
> ietf-ip, because otherwise the modules will soon be full of
> rubbish.

I agree w/ Acee that the name 'link-layer' is more appropriate for the
*origin* of the address.

If you manually configure a link-local address the origin would be
'static'.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 16 Dec 2016 15:13:57 +0100

> On 16 Dec 2016, at 15:05, Martin Bjorklund <[email-masked]> wrote:
> 

That's possible for link-local but not for SLAAC, which is an L3 mechanism.

So a fix might be:

1. Change description of "link-layer" to include link-local addresses.

2. Add a new enum, e.g. "slaac".

Lada

---

From: William Lupton <[email-masked]>
Date: Fri, 16 Dec 2016 14:48:06 +0000

FYI the TR-181 “Device:2” data model (a TR-069 data model) defines a conceptually similar IPv6 address origin parameter (*):

—— 
Mechanism via which the IP address was assigned. Enumeration of:
AutoConfigured (Automatically generated. For example, a link-local address as specified by SLAAC [Section 5.3/RFC4862], a global address as specified by SLAAC [Section 5.5/RFC4862], or generated via CPE logic (e.g. from delegated prefix as specified by [RFC3633]), or from ULA /48 prefix as specified by [RFC4193])
DHCPv6 (Assigned by DHCPv6 [RFC3315])
IKEv2 (Assigned by IKEv2 [RFC5996])
MAP (Assigned by MAP [RFC7597], i.e. is this interface's MAP IPv6 address)
WellKnown (Specified by a standards organization, e.g. the ::1 loopback address, which is defined in [RFC4291])
Static (For example, present in the factory default configuration (but not WellKnown), created by the ACS, or created by some other management entity (e.g. via a GUI))
This parameter is based on ipOrigin from [RFC4293].
——

Rather than defining a “slaac” value we defined AutoConfigured to include SLAAC and other auto-configuration mechanisms. We also listed some other protocols via which the address might be assigned. We perhaps should have defined an “Other” value but the thinking might have been that it was better to extend the enumeration with other specific protocols rather than use “Other”.

This is intended for IPv6 only. We also defined an IPv4 addressing type parameter (**) with enumerations {DHCP, IKEv2, AutoIP, IPCP, Static}.

William

(*) https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.IP.Interface.%7Bi%7D.IPv6Address.%7Bi%7D.Origin
(**) https://www.broadband-forum.org/cwmp/tr-181-2-11-0.html#D.Device:2.Device.IP.Interface.%7Bi%7D.IPv4Address.%7Bi%7D.AddressingType

> On 16 Dec 2016, at 14:13, Ladislav Lhotka <[email-masked]> wrote:
> 
>