Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Dec 2017 17:19:19 +0000

An updated version of this draft is now available that addresses comments posted
on the v6ops list. Links to the document and diffs from the previous version appear
below, and the document now includes a "Changes" appendix to more easily track
major changes between versions.

Please review and send any new comments to the list, and please confirm whether
earlier comments have been addressed.

Thanks - Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, December 14, 2017 9:07 AM
To: [email-masked]
Subject: I-D Action: draft-templin-v6ops-pdhost-17.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : IPv6 Prefix Delegation Models
        Author          : Fred L. Templin
	Filename        : draft-templin-v6ops-pdhost-17.txt
	Pages           : 13
	Date            : 2017-12-14

Abstract:
   IPv6 prefixes are typically delegated to requesting routers which
   then use them to number their downstream-attached links and networks.
   This document considers prefix delegation models according to whether
   the requesting router acts as a router on behalf of any downstream
   networks, as host on behalf of its local applications or as both.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-v6ops-pdhost-17
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-17

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Dec 2017 17:20:51 -0800

> earlier comments have been addressed.

It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be, and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router.

https://www.google.com/search?q=ipam
For example, https://en.wikipedia.org/wiki/IP_address_management

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Dec 2017 14:21:49 +0100

> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by extension IP Prefix Management) software can be implemented in a compu…

Prefix delegation, more so than address assignment is coupled with the routing system.
Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected.

Cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Dec 2017 15:15:04 +0000

Hi Fred,

> From: Fred Baker [mailto:[email-masked]]
> Sent: Thursday, December 14, 2017 5:21 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked] list <[email-masked]>
> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
> 
> 
> 
> It continue to describe the entity delegating the prefix as a "Delegating Router 'D'". The IPAM (IP address Management, and by
> extension IP Prefix Management) software can be implemented in a computer sold as a router, but there is no requirement that it be,
> and it usually is not. As a matter of fact, if a router is a system that forwards messages directed to addresses other than its own, in the
> context of an application such as a DHCPv6 address/prefix management process, it is acting as a host, not a router.

The Delegating Router / Requesting Router relationship is the same as in
RFC3633. If the Delegating Router does not implement the actual prefix
delegation service locally, then it forwards prefix delegation requests to
some other node in the operator's network that provides the service.
That node need not be a router (it could be a simple server running in
some VM). But, the Delegating Router is still a router.

See also Section 14 of RFC3633 for discussion about DHCPv6 relay agents
on Delegating Routers.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Dec 2017 15:17:30 +0000

> From: Ole Troan [mailto:[email-masked]]
> Sent: Friday, December 15, 2017 5:22 AM
> To: Fred Baker <[email-masked]>
> Cc: Templin, Fred L <[email-masked]>; [email-masked] list <[email-masked]>

Correct. And, RFC3633 also correctly explains the case where the Delegating
Router employs a DHCPv6 Relay Agent instead of a DHCPv6 Server.

Thanks - Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Dec 2017 08:07:41 +1300

> Which is why RFC3633 only described a model where the delegating router and requesting router was directly connected.

They're coupled, but it isn't logically required that the entity that gives
prefix P to a device is also the upstream router that will include P in an
aggregate. I agree that's a natural implementation, but it isn't the only one.
IPAMs and their generalisation in CASM, and draft-ietf-anima-prefix-management,
are alternatives.

So I agree - it is a false assumption that the prefix delegator is
a router, and that the delegation mechanism is RFC3633.

As far as the draft goes, I'd like to see this qualified:

"An example IPv6 PD service is the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  An
alternative service based solely on IPv6 ND messaging has also
been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]."

Maybe by adding that other, non-router, mechanisms may exist,
such as proprietary IPAMs, draft-ietf-anima-prefix-management
and draft-sun-casm-address-pool-management-yang (expired).

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Dec 2017 19:56:52 +0000

Hi Brian,

OK, thanks for explaining and I think I understand. I have a picture in my mind
now that I think would satisfy everyone's concerns. I will try to get a new draft
version out with updated figures and text on Monday.

Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Friday, December 15, 2017 11:08 AM
> To: [email-masked]
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Dec 2017 21:20:26 +0100

Brian,

Sure, but we have learnt that the matter of route injection is a thorny problem. 
If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains. 

Ole

> On 15 Dec 2017, at bu20:07, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 15 Dec 2017 22:06:55 +0100

Brian,

Sure, but we have learnt that the matter of route injection is a hard problem. 
If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains. 

Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Dec 2017 10:08:44 +1300

> If you do not topologically restrict the problem, how do you solve it? Among separate administrative domains.

Agreed. It can get very tricky. I just prefer the language in the draft
not to be restrictive.

   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Dec 2017 21:20:58 +0000

Hi,

> Sent: Friday, December 15, 2017 1:09 PM
> To: Ole Troan <[email-masked]>
> Cc: [email-masked]

Without question, the first-hop router has to do route injection. It also has
to honor route lifetimes, route revocations and link-layer address changes
of the requesting router.

I think this latter point is one that may need some further consideration.
If the requesting router's link-layer address changes, and the requesting
router signals the first-hop router by sending unsolicited NAs, wouldn't
it be much easier if the first-hop router were also an active participant
in the prefix delegation process? Because, an off-link entity would
never see the NAs.
 
> Agreed. It can get very tricky. I just prefer the language in the draft

I think the language can be relaxed, but I go back to the point about
the first-hop router also being an active participant in the PD exchange.
AFAICT, the first-hop router is the only node that can both inject the
prefix and observe the on-link behavior of the requesting router.

Thanks - Fred

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 Dec 2017 10:44:33 +1100

Hi,

On 16 December 2017 at 08:20, Templin, Fred L <[email-masked]> wrote:
> Without question, the first-hop router has to do route injection.

Actually, I don't think that is true. Some other router in the network
running BGP could inject the route into the routing domain, with a BGP
route NEXT_HOP attribute for the route set to either a non-Link-Local
address of the client host's interface, or the NEXT_HOP attribute for
the route set to one of the first-hop router's addresses (likely a
loopback interface address ), with that first-hop router then
resolving the last hop IPv6 address/link-layer address to reach the
host. (I'd be inclined to do the latter to make it easier to identify
from the BGP route table  NEXT_HOPs where a particular set of host
with assigned prefixes are attached, and I think BGP implementations
commonly consume less memory when a set of prefixes share the same
NEXT_HOP address.)

This "route injection" BGP router(s) would need to somehow learn of
the host assigned prefixes when they're assigned to then inject the
assigned host prefixes.

Haven't thought enough about whether it would be worth doing this way
or not. It might be operationally better or simpler to have a smaller
set of routers do this type of injection on a network rather than
having all first hop routers, which could, for example, number in the
1000s, do it.

Regards,
Mark.

> It also has

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Dec 2017 15:38:32 +1300

> prefix and observe the on-link behavior of the requesting router.

Yes, but if it observes one of its downstream routers advertising a new prefix
in the IGP, it is not acting as a first hop router; it's simply a peer router.
At that point the downstream device is no longer acting only as a host, the
upstream device perhaps did not hand out the prefix in question, and the
network may not even be hierarchical any more.

I realise that's not the scenario you're mainly interested in, but it
seems entirely possible.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Dec 2017 05:50:29 +0100

Le 16/12/2017 à 00:44, Mark Smith a écrit :
>>> -----Original Message----- From: v6ops
>>> [mailto:[email-masked]] On Behalf Of Brian E Carpenter 
>>> Sent: Friday, December 15, 2017 1:09 PM To: Ole Troan
>>> <[email-masked]> Cc: [email-masked] Subject: Re: [v6ops]
>>> draft-templin-v6ops-pdhost a working group draft?
>>> 
> Actually, I don't think that is true. Some other router in the
> network running BGP could inject the route into the routing domain,
> with a BGP route NEXT_HOP attribute for the route set to either a
> non-Link-Local address of the client host's interface, or the
> NEXT_HOP attribute for the route set to one of the first-hop router's
> addresses (likely a loopback interface address ), with that first-hop
> router then resolving the last hop IPv6 address/link-layer address to
> reach the host. (I'd be inclined to do the latter to make it easier
> to identify from the BGP route table  NEXT_HOPs where a particular
> set of host with assigned prefixes are attached, and I think BGP
> implementations commonly consume less memory when a set of prefixes
> share the same NEXT_HOP address.)
> 

But then, how that 'route injection' BGP router learns these prefixes?
If the 'route injection' BGP router is the DHCP Relay, then it is very
easy: they are processes on the same filesystem and they can coordinate
easily.

(the DHCP Relay must be the first-hop router from the perspective of the 
pdhost).

> Haven't thought enough about whether it would be worth doing this
> way or not. It might be operationally better or simpler to have a
> smaller set of routers do this type of injection on a network rather
> than having all first hop routers, which could, for example, number
> in the 1000s, do it.

A question is who triggers the 'route injection' BGP router to inject:
is it the Server or the Relay?  If it is the Relay, then one may end up
with 1000s of Relays not doing route injection, but triggering 1000
messages to the 'route injection' BGP router which in turn would inject
routes.

(as a side note, in a certain deployment there is no DHCP Relay, and the
DHCP Server is a unique and big machine that executes also BGP and does
the BGP route injection too upon prefix delegation).

Alex

> 
> Regards, Mark.
> 
>> It also has to honor route lifetimes, route revocations and
>> link-layer address changes of the requesting router.
>> 
>> I think this latter point is one that may need some further
>> consideration. If the requesting router's link-layer address
>> changes, and the requesting router signals the first-hop router by
>> sending unsolicited NAs, wouldn't it be much easier if the
>> first-hop router were also an active participant in the prefix
>> delegation process? Because, an off-link entity would never see the
>> NAs.
>> 
>>>> If you do not topologically restrict the problem, how do you
>>>> solve it? Among separate administrative domains.
>>> 
>>> Agreed. It can get very tricky. I just prefer the language in the
>>> draft not to be restrictive.
>> 
>> I think the language can be relaxed, but I go back to the point
>> about the first-hop router also being an active participant in the
>> PD exchange. AFAICT, the first-hop router is the only node that can
>> both inject the prefix and observe the on-link behavior of the
>> requesting router.
>> 
>> Thanks - Fred
>> 
>>> Brian
>>> 
>>>> 
>>>> Ole
>>>> 
>>>>>>>> Please review and send any new comments to the list,
>>>>>>>> and please confirm whether earlier comments have been
>>>>>>>> addressed.
>>>>>>> 
>>>>>>> It continue to describe the entity delegating the prefix
>>>>>>> as a "Delegating Router 'D'". The IPAM (IP address
>>>>>>> Management, and by
>>> extension IP Prefix Management) software can be implemented in a
>>> computer sold as a router, but there is no requirement that it
>>> be, and it usually is not. As a matter of fact, if a router is a
>>> system that forwards messages directed to addresses other than
>>> its own, in the context of an application such as a DHCPv6
>>> address/prefix management process, it is acting as a host, not a
>>> router.
>>>>>> 
>>>>>> Prefix delegation, more so than address assignment is
>>>>>> coupled with the routing system. Which is why RFC3633 only
>>>>>> described a model where the delegating router and
>>>>>> requesting router was directly connected.
>>>>> 
>>>>> They're coupled, but it isn't logically required that the
>>>>> entity that gives prefix P to a device is also the upstream
>>>>> router that will include P in an aggregate. I agree that's a
>>>>> natural implementation, but it isn't the only one. IPAMs and
>>>>> their generalisation in CASM, and
>>>>> draft-ietf-anima-prefix-management, are alternatives.
>>>>> 
>>>>> So I agree - it is a false assumption that the prefix
>>>>> delegator is a router, and that the delegation mechanism is
>>>>> RFC3633.
>>>>> 
>>>>> "An example IPv6 PD service is the Dynamic Host Configuration
>>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  An 
>>>>> alternative service based solely on IPv6 ND messaging has
>>>>> also been proposed [I-D.pioxfolks-6man-pio-exclusive-bit]."
>>>>> 
>>>>> Maybe by adding that other, non-router, mechanisms may
>>>>> exist, such as proprietary IPAMs,
>>>>> draft-ietf-anima-prefix-management and
>>>>> draft-sun-casm-address-pool-management-yang (expired).
>>>>> 
>>>>> Brian
>>>>> 
>>>>> _______________________________________________ v6ops mailing
>>>>> list [email-masked] 
>>> _______________________________________________ v6ops mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> 
>> _______________________________________________ v6ops mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________ v6ops mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Dec 2017 12:37:01 +1100

On 16 December 2017 at 15:50, Alexandre Petrescu
<[email-masked]> wrote:
>>>> [mailto:[email-masked]] On Behalf Of Brian E Carpenter Sent:
>>>> Friday, December 15, 2017 1:09 PM To: Ole Troan
>> This "route injection" BGP router(s) would need to somehow learn of the
>> host assigned prefixes when they're assigned to then inject the assigned
>> host prefixes.
>
>

In some unspecified way. Point I'm making is that it isn't a necessity
that the first hop router is the one that injects the route. In a
large network running BGP there can be value in more centralising
functions such as route advertisement e.g. BGP Route Reflectors.

e.g if you have centralised DHCP server infrastructure, a few BGP
routers adjacent to the DHCP servers that are injecting routes would
reduce the need to have each and every first hop router perform that
function.

> the BGP route injection too upon prefix delegation).

That's a possible model, although I don't like "big machines" because
the consequence of their failure as also usually big.

It's finding the right balance between highly distributed and highly
centralised, weighing up the trade-offs between.

>>>>>> Protocol for IPv6 (DHCPv6) [RFC3315][RFC3633].  An alternative service
>>>>>> based solely on IPv6 ND messaging has

---

From: Ole Troan <[email-masked]>
Date: Sun, 17 Dec 2017 11:20:33 +0100

Mark,

> On 17 Dec 2017, at 02:37, Mark Smith <[email-masked]> wrote:
> 

If hand waving is all that’s required, sure. :-)
- how do you “know” the next-hop address of first-hop or last-hop?
- how do you program the fib of the first-hop router?

Sure, you can do that with some out-of-band mechanism, but you’re still only hand waving. 

Cheers 
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Dec 2017 06:28:01 +1100

Hi Ole,

> Mark,

<snip>

> - how do you “know” the next-hop address of first-hop or last-hop?

If DHCPv6 is being used with the first hop router as a Relay, then the
Relay address could be used as the BGP NEXT_HOP address. Similarly, if
RADIUS accounting records assignment of prefixes to hosts, then the
RADIUS NAS address could be used as the BGP NEXT_HOP address for the
prefix.

If the assignment of prefixes is entirely local to the first hop
router, with no involvement of or reporting to an external service,
then it would be necessary for that first hop router to announce the
host prefix. However, in that case there would likely be a pool of
prefixes to assign to hosts, known to be assigned to a particular
first hop router, so BGP could be used to inject that route somewhere
other than at the first hop router.

> - how do you program the fib of the first-hop router?

In most cases I would expect the first hop router to put the host
assigned prefix in its own FIB, as it was involved in assigning it.

However, if the first hop link has a GUA or ULA prefix, and the host's
address on that link is known externally, as well as the assigned
prefix via RADIUS, then BGP could also be used to program the first
hop router's FIB - the prefix would be injected with the BGP NEXT_HOP
set to the individual hosts' first hop link GUA or ULA address.

Some of these examples are convoluted and unlikely to be used. Others
could be useful depending on goals or network architecture. I
commented really just to show that an absolute statement that the
first hop router must announce the host assigned prefix(es) into the
routing domain isn't necessarily correct if BGP is being used.

Regards,
Mark.

---

From: Ole Troan <[email-masked]>
Date: Mon, 18 Dec 2017 21:04:31 +0100

Mark,

> routing domain isn't necessarily correct if BGP is being used.

sure, it is possible to imagine solutions where BGP 3rd party next-hop is useful.
but BGP 3rd party next-hop in itself is far from a complete solution, and as you suggest above it is hard to avoid involvement from the first-hop router.
which was my point in replying to Fred, you cannot just treat PD as a IPAM solution, at least not unless you are prepared to pull the "orchestrate/SDN" handwave... ;-)

Cheers,
Ole