Subject: Stupid 4291 question

From: Toerless Eckert <[email-masked]>
Date: Mon, 17 Jul 2017 17:14:53 +0200

So, if i create a loopback interface with a /128 IPv6 global address
to use for various purposes (routing protocol identifier, mgmt address, etc. pp),
how do i figure out whether this is legal wrt. 4291 or not ? It is AFAIK common
practice in networks.

To me it looks as if it would violate 2.5.1 and i also haven't seen something in the RFCs
updating 4291. But i just browsed quickly.

Thank!
    Toerless

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Jul 2017 11:24:45 -0500

> updating 4291. But i just browsed quickly.

It's a little more complicated, simply assigning a /128 or other on-link
prefix length to any interface, loopback or otherwise, doesn't imply there
is not a 64bit IID is being used.

If each loopback /128 is assigned out of it's own unique /64, you are
fine.  Each link has a /64 and the IIDs from that /64 are only associated
with that link, the loopback interface.  The whole /64 just isn't on-link,
only the one /128 in this case.  However, if you assign any /128s from that
/64 to a different loopback interface on that or any other router, then you
violate section 2.5.1 of RFC4291.

However, I think it is fairly common practice to assign loopback interfaces
for a whole network out of a common /64, maybe assigning point-to-point
router links out of that common /64 too, and that is where the problem is,
all of the 64bit IID are not associated with the same link, not that act of
assigning a /128 to a loopback by itself.

At least that is my interpretation of it. Now the current RFC4291bis has an
exception for manually configured interfaces. I think most loopback
interfaces are manually configured. However, I think it would be better to
call out loopback interfaces explicitly, just so we don't have to get into
the philosophical argument about whether or not generating configs out of
puppet or something like that is actually manual configuration or not.

Thanks.
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Ole Troan <[email-masked]>
Date: Mon, 17 Jul 2017 18:44:36 +0200

As a general note it might be worth remembering that the address/prefix-length notation is just a short-hand that is commonly used in implementations. 

An address is always 128-bit and does not need to have an associated prefix-length with it. 

To spell out Toerless' example:
Interface loopback0
  ipv6 address 2001:db8::1
  ipv6 on-link prefix 2001:db8::1/128

In this case specifying an onlink prefix length of 128 is of course redundant. 

But you can of course specify an IPv6 address on an interface without any associated on-link prefix. 

Cheers 
Ole

> On 17 Jul 2017, at 17:14, Toerless Eckert <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Jul 2017 19:21:45 +0200

David Farmer <[email-masked]> wrote:
    > fine. Each link has a /64 and the IIDs from that /64 are only
    > associated with that link, the loopback interface. The whole /64 just
    > isn't on-link, only the one /128 in this case. However, if you assign
    > any /128s from that /64 to a different loopback interface on that or
    > any other router, then you violate section 2.5.1 of RFC4291.

I don't see why you say that.

    > However, I think it is fairly common practice to assign loopback
    > interfaces for a whole network out of a common /64, maybe assigning
    > point-to-point router links out of that common /64 too, and that is
    > where the problem is, all of the 64bit IID are not associated with the
    > same link, not that act of assigning a /128 to a loopback by itself.

Are you claiming that having a /64 for all loopbacks (which is never used in
SLAAC or on any broadcast link that could have RAs) is some kind violation?
I'm pretty sure that that has been beat to death on this list already.

    > At least that is my interpretation of it. Now the current RFC4291bis
    > has an exception for manually configured interfaces. I think most
    > loopback interfaces are manually configured.

Yes, this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: David Farmer <[email-masked]>
Date: Mon, 17 Jul 2017 14:16:24 -0500

> I'm pretty sure that that has been beat to death on this list already.

The question was, or at least I interpreted the question as being asked
about RFC4291, since bis wasn't included in the title and section 2.5.1
about IIDs, and it is now 2.4.1 in 4291bis.  So, 4291 says IID are required
to be 64 bits, that is not scoped to SLAAC, scoping this to SLAAC in
RFC4291bis is one way to go, but it is currently making an exception for
manually configured interfaces.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 18 Jul 2017 00:01:33 +0200

inline

> assigning a /128 to a loopback by itself.

Right. That would have been my interpretation as well.

> interfaces are manually configured.

> However, I think it would be better to

You're not allowed to do this from an SDN controller *rotfl*

Well, in IP multicast i also started to explain to folks a long time ago
how to do something called "prioritycast" which we use for redundant
addresses in Bidir-PIM (or even for other use cases with predictable selection
of instance). Eg: Instead of anycast where everybody converges to
the closest instance of a redundant address (aka: all instances have /128),
you need to make sure that everybody converges to one instance. The trick of course
is that you would assign to the primary instance a /128 address on a loopack and
distribute into routing protocol), to the secondary a /127, and so on (rarely more
than three redundant instances use).

Aka: in all these "inside baseball", oops: "inside network infrastructure"
addressing tricks its irritating to have to go back to this IID /64 consideration
in rfc4291. And its also somewhat confusing to read the section in 4291 about
"in routing, any prefix is permitted" and then trying to figure out how to
create any form of prefix given how they all needed to be a prefix on some
interface and those prefixes could be > 64 but would need to still waste
each one a /64 due to 2.5.1, except .... oh well, how about these prioritycast/anycast
cases explained above. Is that actually breaking rule 2.5.1 ? Is not mean to
be a separate logical subnet, its just a redundant instance of a single
logical subnet distributed over different routers.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 18 Jul 2017 00:05:09 +0200

Ole:

In your example, would you be allowed to have a /128 with
the same 2001:db8:: on another router according to 4291 ?

-- 
---
[email-masked]