Discussion:
Stupid 4291 question
Toerless Eckert
2017-07-17 15:14:53 UTC
Permalink
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
David Farmer
2017-07-17 16:24:45 UTC
Permalink
Post by Toerless Eckert
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
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:***@umn.edu
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
===============================================
Michael Richardson
2017-07-17 17:21:45 UTC
Permalink
Post by David Farmer
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.
I don't see why you say that.
Post by David Farmer
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.
Post by David Farmer
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 [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [



--
Michael Richardson <mcr+***@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
David Farmer
2017-07-17 19:16:24 UTC
Permalink
Post by Michael Richardson
Post by David Farmer
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.
I don't see why you say that.
Post by David Farmer
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
Post by David Farmer
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.
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.
Post by Michael Richardson
Post by David Farmer
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 [
--
-= IPv6 IoT consulting =-
--
===============================================
David Farmer Email:***@umn.edu
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>
===============================================
Toerless Eckert
2017-07-17 22:01:33 UTC
Permalink
inline
Post by David Farmer
Post by Toerless Eckert
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
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.
Right. That would have been my interpretation as well.
Post by David Farmer
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.
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
Ole Troan
2017-07-17 16:44:36 UTC
Permalink
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
Post by Toerless Eckert
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Toerless Eckert
2017-07-17 22:05:09 UTC
Permalink
Ole:

In your example, would you be allowed to have a /128 with
the same 2001:db8:: on another router according to 4291 ?
Post by Ole Troan
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.
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
Post by Toerless Eckert
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--
---
***@cs.fau.de
Loading...