Prefix Delegation and hosts

[Templin, Fred L]

Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
Recent discussions and drafts have suggested that the "Requesting Router" could be a
simple host that receives a Prefix Delegation (of whatever prefix length) for its own
multi-addressing purposes. Meaning, that the host configures addresses from the
prefix and assigns them, e.g., to a loopback interface so that its local applications can
each use a different address if desired.

But, whether the node uses the delegated prefix for multi-addressing (as a host
would) or for assignment to downstream links (as a router would), it still has the
same appearance from the outside world. So, from the outside world, the node
would appear as a multi-addressing host even if it is acting as a router on its
downstream links. The only time it would look like a router is if it engaged in a
dynamic routing protocol on the interface over which it received the prefix.

Any thoughts?

Thanks - Fred

[Templin, Fred L]

To add to this, these types of nodes must not send RAs on the link over which they
received the prefix delegation - only routers that are authoritative for the link should
send RAs.

Thanks - Fred

-----Original Message-----
Sent: Wednesday, July 19, 2017 3:26 AM
Subject: Prefix Delegation and hosts
Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
Recent discussions and drafts have suggested that the "Requesting Router" could be a
simple host that receives a Prefix Delegation (of whatever prefix length) for its own
multi-addressing purposes. Meaning, that the host configures addresses from the
prefix and assigns them, e.g., to a loopback interface so that its local applications can
each use a different address if desired.
But, whether the node uses the delegated prefix for multi-addressing (as a host
would) or for assignment to downstream links (as a router would), it still has the
same appearance from the outside world. So, from the outside world, the node
would appear as a multi-addressing host even if it is acting as a router on its
downstream links. The only time it would look like a router is if it engaged in a
dynamic routing protocol on the interface over which it received the prefix.
Any thoughts?
Thanks - Fred
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Michael Richardson]

Post by Templin, Fred L
But, whether the node uses the delegated prefix for multi-addressing
(as a host would) or for assignment to downstream links (as a router
would), it still has the same appearance from the outside world. So,
from the outside world, the node would appear as a multi-addressing
host even if it is acting as a router on its downstream links. The only
time it would look like a router is if it engaged in a dynamic routing
protocol on the interface over which it received the prefix.
Any thoughts?

I should tell my 5G provider that I need the prefix because I run VMs
on my phone (work, home, kid gaming), and that it has nothing to do with
tethering.

[Templin, Fred L]

-----Original Message-----
Sent: Wednesday, July 19, 2017 5:24 AM
Subject: Re: Prefix Delegation and hosts

Post by Templin, Fred L
But, whether the node uses the delegated prefix for multi-addressing
(as a host would) or for assignment to downstream links (as a router
would), it still has the same appearance from the outside world. So,
from the outside world, the node would appear as a multi-addressing
host even if it is acting as a router on its downstream links. The only
time it would look like a router is if it engaged in a dynamic routing
protocol on the interface over which it received the prefix.
Any thoughts?

I should tell my 5G provider that I need the prefix because I run VMs
on my phone (work, home, kid gaming), and that it has nothing to do with
tethering.

Yes, exactly. And, if the provider won't give you a prefix because they fear
tethering all you need to do is turn your phone into a NAT.

Thanks - Fred

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [

[Alexandre Petrescu]

Post by Templin, Fred L
Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
Recent discussions and drafts have suggested that the "Requesting Router" could be a
simple host that receives a Prefix Delegation (of whatever prefix length) for its own
multi-addressing purposes. Meaning, that the host configures addresses from the
prefix and assigns them, e.g., to a loopback interface so that its local applications can
each use a different address if desired.

The host-that-became-router can also not assign any address from the
delegated prefix on any of its interfaces, use its LLs, and forward IP
packets.

Post by Templin, Fred L
But, whether the node uses the delegated prefix for multi-addressing (as a host
would) or for assignment to downstream links (as a router would), it still has the
same appearance from the outside world. So, from the outside world, the node
would appear as a multi-addressing host even if it is acting as a router on its
downstream links. The only time it would look like a router is if it engaged in a
dynamic routing protocol on the interface over which it received the prefix.

I agree. It would like like Router to the outside world if it ran a
routing protocol and if it joined the All-Routers multicast address.

Alex

Post by Templin, Fred L
Any thoughts?
Thanks - Fred
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Templin, Fred L]

Hi Alex,

-----Original Message-----
Sent: Wednesday, July 19, 2017 7:09 AM
Subject: Re: Prefix Delegation and hosts

Post by Templin, Fred L
Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
Recent discussions and drafts have suggested that the "Requesting Router" could be a
simple host that receives a Prefix Delegation (of whatever prefix length) for its own
multi-addressing purposes. Meaning, that the host configures addresses from the
prefix and assigns them, e.g., to a loopback interface so that its local applications can
each use a different address if desired.

The host-that-became-router can also not assign any address from the
delegated prefix on any of its interfaces, use its LLs, and forward IP
packets.

I agree it can be LL-only on its interface over which it receives the PD,
but it needs to have at least one GUA assigned on *some* interface
so it has a source address for sending ICMPs.

Post by Templin, Fred L
But, whether the node uses the delegated prefix for multi-addressing (as a host
would) or for assignment to downstream links (as a router would), it still has the
same appearance from the outside world. So, from the outside world, the node
would appear as a multi-addressing host even if it is acting as a router on its
downstream links. The only time it would look like a router is if it engaged in a
dynamic routing protocol on the interface over which it received the prefix.

I agree. It would like like Router to the outside world if it ran a
routing protocol and if it joined the All-Routers multicast address.

Yes, you are right. These things must not receive and respond to multicast
RSs sent by hosts on the link that are trying to contact routers that are
authoritative for the link.

Thanks - Fred

Alex

Post by Templin, Fred L
Any thoughts?
Thanks - Fred
--------------------------------------------------------------------
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
--------------------------------------------------------------------

[Brian E Carpenter]

Post by Templin, Fred L
Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
Recent discussions and drafts have suggested that the "Requesting Router" could be a
simple host that receives a Prefix Delegation (of whatever prefix length) for its own
multi-addressing purposes. Meaning, that the host configures addresses from the
prefix and assigns them, e.g., to a loopback interface so that its local applications can
each use a different address if desired.
But, whether the node uses the delegated prefix for multi-addressing (as a host
would) or for assignment to downstream links (as a router would), it still has the
same appearance from the outside world. So, from the outside world, the node
would appear as a multi-addressing host even if it is acting as a router on its
downstream links. The only time it would look like a router is if it engaged in a
dynamic routing protocol on the interface over which it received the prefix.

Formally, a router is "a node that forwards IPv6 packets not explicitly
addressed to itself. (See Note below.)" [RFC8200]. I recommend reading
the note as well. But what it amounts to is: it's no business of the
delegating router what the requesting router chooses to do with the
delegated prefix, as long as it obeys RFC8200. If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the friends,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
will show up in running code sometime.)

Brian

[Lorenzo Colitti]

On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter <

Post by Brian E Carpenter
If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the friends,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
will show up in running code sometime.)

Why pick /80 instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a few
steps in the race to the bottom.

[joel jaeggli]

Post by Lorenzo Colitti
On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter
If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the friends,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
will show up in running code sometime.)
 
Why pick /80 instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a
few steps in the race to the bottom.

Presumably if your goal is to allow downstream devices to futher segment
you will assign the shortest prefixes you can get away with in your
model. if your goal is micro-segmentation of things like for example for
containers or VMs, you'll probably assign as long as you can get away
with e.g. /126 /127 /128 which can be littered all over the address
space if you're so inclined.

Post by Lorenzo Colitti
--------------------------------------------------------------------
IETF IPv6 working group mailing list
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

[Simon Hobson]

Post by joel jaeggli

Post by Lorenzo Colitti
Why pick /80 instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a
few steps in the race to the bottom.

Presumably if your goal is to allow downstream devices to futher segment
you will assign the shortest prefixes you can get away with in your
model. if your goal is micro-segmentation of things like for example for
containers or VMs, you'll probably assign as long as you can get away
with e.g. /126 /127 /128 which can be littered all over the address
space if you're so inclined.

I think you missed his point.
The moment anyone admits that a network can have less than 64bits of addressing to play with, then the sky will fall in, there'll be plagues of locusts, the world will end, and everyone will start getting /128 single addresses delegated to them. Thus, there should not be any document anywhere even admitting that /64 isn't sacrosanct lest the ISPs inhabiting the muddy bottom of the pond use it as an excuse to delegate smaller than multiple /64s to their customers.

[Templin, Fred L]

From: Lorenzo Colitti [mailto:***@google.com]
Sent: Thursday, July 20, 2017 4:46 AM
To: Brian E Carpenter <***@gmail.com>
Cc: Templin, Fred L <***@boeing.com>; ***@ietf.org
Subject: Re: Prefix Delegation and hosts

On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter <***@gmail.com<mailto:***@gmail.com>> wrote:
If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the friends,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
will show up in running code sometime.)

Why pick /80 instead of something more familiar such as /120? The requesting router can even assign prefixes based on RFC1918 IPv4 /24 prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a few steps in the race to the bottom.


Ø Or, just jump to /128 immediately and do NAT?

[Brian E Carpenter]

Post by Lorenzo Colitti
On Thu, Jul 20, 2017 at 4:37 AM, Brian E Carpenter <

Post by Brian E Carpenter
If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the friends,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
will show up in running code sometime.)

Why pick /80

Since you ask, because that allows for a 48-bit IID, which is big enough
to satisfy privacy and collision requirements. /120 isn't, which means it
would only be suitable for infrastructure components where neither personal
privacy nor pseudo-random assignment is needed.

I'm not convinced about the race to the bottom. But I'd better go and read
Mark's message next.

Brian

Post by Lorenzo Colitti
instead of something more familiar such as /120? The
requesting router can even assign prefixes based on RFC1918 IPv4 /24
prefixes and IIDs based on the late 8 bits of the IPv4 address. Skip a few
steps in the race to the bottom.

[Templin, Fred L]

Hi Brian,

-----Original Message-----
Sent: Wednesday, July 19, 2017 7:38 PM
Subject: Re: Prefix Delegation and hosts

Post by Templin, Fred L
Classical DHCPv6 Prefix Delegation involves a Requesting Router and a Delegating Router.
Recent discussions and drafts have suggested that the "Requesting Router" could be a
simple host that receives a Prefix Delegation (of whatever prefix length) for its own
multi-addressing purposes. Meaning, that the host configures addresses from the
prefix and assigns them, e.g., to a loopback interface so that its local applications can
each use a different address if desired.
But, whether the node uses the delegated prefix for multi-addressing (as a host
would) or for assignment to downstream links (as a router would), it still has the
same appearance from the outside world. So, from the outside world, the node
would appear as a multi-addressing host even if it is acting as a router on its
downstream links. The only time it would look like a router is if it engaged in a
dynamic routing protocol on the interface over which it received the prefix.

Formally, a router is "a node that forwards IPv6 packets not explicitly
addressed to itself. (See Note below.)" [RFC8200]. I recommend reading
the note as well. But what it amounts to is: it's no business of the
delegating router what the requesting router chooses to do with the
delegated prefix, as long as it obeys RFC8200.

Agreed. The "requesting router (RR)" could even be a host that uses the PDs
for its own multi-addressing purposes and without forwarding any packets not
explicitly addressed to itself. So, in that sense, it is no business of *any* other
nodes on the link as to what the RR does with the prefix.

But, for sure, the RR is NOT authoritative for the link over which it receives the
PD so it should not send RAs on that link. Only routers that are authoritative
for the link should send RAs, since RAs contain configuration information for
the link. RRs should instead send NA messages with RIOs.

If it gets a /64 and
and chooses to use DHCPv6-PD to hand out /80s to its friends, nobody
upstream will know (or care). Of course, SLAAC won't work for the friends,
but nobody upstream will know that either. (It should be a small matter
of coding to make SLAAC work with 48 bit IIDs, so I've no doubt that
will show up in running code sometime.)

I don't see why not, I guess. After all, it is *their* prefix and they can do
whatever they want with it - standards or no.

Thanks - Fred

Brian