Subject: [netmod] draft-ietf-netmod-rfc6991-bis - ipv6-link-local address?

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Jan 2022 16:54:09 -0500

Mahesh suggested I send this suggestion here.

Several IPv6 routing protocols have circumstances where the only acceptable address is an ipv6 link-local address.

The YANG type we have for ipv6 can accommodate ipv6 link local addresses, however it's overly permissive for some use cases.

Has the Working Group considered adding a typedef for ipv6 link-local?

FWIW, the current use case under consideration is operational state for BGP IPv6 routes conforming to RFC 2545 and related work under consideration in IDR for link-local only BGP peering.  In such circumstances, the BGP nexthop will contain a component that may only be ipv6 link-local.

For the BGP YANG module, the edits under consideration will currently use the ipv6 type.  Since the current use case is operational only state, the lack of the more restrictive type is not considered a blocker. For the future link-local-only work, configuration state will be needed.

-- Jeff

---

From: Reshad Rahman <[email-masked]>
Date: Thu, 6 Jan 2022 22:02:00 +0000 (UTC)

Jeff, this was brought up a few months ago (see Juergen's response): https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/

    On Thursday, January 6, 2022, 04:54:22 PM EST, Jeffrey Haas <[email-masked]> wrote:  

-- Jeff

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

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Jan 2022 17:07:05 -0500

Reshad,

Thanks for drawing my attention to this older thread.

It seems the method for addressing the need is understood.  I guess my request is to urge Jürgen and the WG to reconsider its avoidance of providing us a common type.  Not having multiple people reinvent this particular thing each time seems productive.

-- Jeff

> On Jan 6, 2022, at 5:02 PM, Reshad Rahman <[email-masked]> wrote:
> 
> Jeff, this was brought up a few months ago (see Juergen's response): 
> https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/ <https://mailarchive.ietf.org/arch/msg/netmod/cRmDwqarkW2fNc2nS25zrkycQWs/>
> 
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>

---

From: Reshad Rahman <[email-masked]>
Date: Thu, 6 Jan 2022 22:14:51 +0000 (UTC)

Jeff, I agree. On the previous thread no-one on NETMOD showed interest in a common type, I should have CCed a few routing WGs...
Regards,Reshad.
    On Thursday, January 6, 2022, 05:07:07 PM EST, Jeffrey Haas <[email-masked]> wrote:  
 
 Reshad,

 

-- Jeff

---

From: Jürgen Schönwälder <[email-masked]>
Date: Thu, 13 Jan 2022 11:49:12 +0100

As pointed out by others, this is what I proposed back in July '21:

typedef ipv6-address-link-local {
  type ipv6-address;
  pattern '[fF][eE]80:.*';
  description
    "A link-local IPv6 address in the prefix fe80::/10 as defined
     in section 2.5.6. of RFC 4291.";
  reference
    "RFC 4291: IP Version 6 Addressing Architecture";
}

If this serves the purpose, I can add this definition to the
inet-types module.

Will there also be a need to have an IPv4 equivalent?

typedef ipv4-address-link-local {
  type ipv4-address;
  pattern '169\.254\..*';
  description
    "A link-local IPv4 address in the prefix 169.254.0.0/16 as 
     defined in section 2.1. of RFC 3927.";
  reference
    "RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses";
}

/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Jan 2022 07:43:15 -0500

Jürgen,

> On Jan 13, 2022, at 5:49 AM, Jürgen Schönwälder <[email-masked]> wrote:
> 

This example had been the first time I'd seen a pattern on top of a typedef with its own pattern.
That said, it seems to be what I would expect.

> Will there also be a need to have an IPv4 equivalent?

For most of the routing technologies I have worked on, it's not a requirement.  But it's an appropriate gap to fill and will potentially be useful for other technologies.  E.g. BRAS.

-- Jeff