RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

> Maybe Ole can say
> more about what is expected when the delegating router and relay
> agent are on different platforms.

Well, not Ole ...

And, as relay agents are typically also the routers and they see the DHCPv6 packets already, they just snoop the inside to find the client message and do what's needed for the PD and to advertise the prefixes. At least, that's what happens for DOCSIS on the CMTS.

- Bernie

-----Original Message-----
From: v6ops <v6ops-bounces@ietf.org> On Behalf Of Brian E Carpenter
Sent: Wednesday, November 21, 2018 2:59 PM
To: Templin (US), Fred L <Fred.L.Templin@boeing.com>; Mikael Abrahamsson <swmike@swm.pp.se>
Cc: v6ops list <v6ops@ietf.org>; 6man WG <ipv6@ietf.org>
Subject: Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

On 2018-11-22 07:40, Templin (US), Fred L wrote:
> Hi Mikael,
> 
>> -----Original Message-----
>> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]
>> Sent: Wednesday, November 21, 2018 10:23 AM
>> To: Templin (US), Fred L <Fred.L.Templin@boeing.com>
>> Cc: Naveen Kottapalli <naveen.sarma@gmail.com>; Brian E Carpenter <brian.e.carpenter@gmail.com>; 6man WG <ipv6@ietf.org>;
>> v6ops list <v6ops@ietf.org>
>> Subject: RE: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt
>>
>> On Wed, 21 Nov 2018, Templin (US), Fred L wrote:
>>
>>> That particular example does not relate specifically to the DHCPv6-ND
>>> proposal; the proposal is not out to solve interactions between SLAAC
>>> and DHCPv6, but in this particular example common sense should prevail.
>>
>> I know, and that's why I don't like it. I want this problem solved, not
>> glossed over.
>>
>>> The LDRA is a DHCPv6 relay agent like any other. The behavior of DHCPv6
>>> relay agents wrt prefix delegation is covered in RFC3633, Section 14.
>>
>> Errr, it's "covered" in the fact that it doesn't say how to do that.
>>
>> "If a delegating router communicates with a requesting router through
>>     a relay agent, the delegating router may need a protocol or other
>>     out-of-band communication to add routing information for delegated
>>     prefixes into the provider edge router."
>>
>> It doesn't say "inspect the relayed message and guess that you might need
>> to install a route and keep state for that route". How do you do this?
>> I have seen several relay implementations that relayed the message just
>> fine but didn't install any route, leaving the PD useless for the end
>> user.
> 
> In a case that I care about, the delegating router and relay agent are on
> one and the same platform. So, the delegating router does just what the
> spec says, and the relay agent's needs are satisfied. Maybe Ole can say
> more about what is expected when the delegating router and relay
> agent are on different platforms.

Since DHCPv6 is a separate entity from any routing protocol, this
is a case where inside a single box they could be linked by a privately
defined API but in different boxes they would need a protocol, which
could of course be either proprietary or standardised. What's new
here?

    Brian

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops