Re: [dhcwg] DHCPv6 RAAN options

["Bernie Volz (volz)" <[e-mail]>]

Fred:

How about a 3rd option ...

Perhaps you should look at the Active Leasequery work as that might be a better option for the Relay tracking what the server has?

See http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-active-leasequery.


One issue for RAAN and even Relay gleaming the Reply is that the Reply message might be lost and never get to the Relay. The client may not retry (or all Releases suffer from this issue) - it is suggested that the client retry, not a requirement.

   Because Release messages may be lost, the client should retransmit
   the Release if no Reply is received.  However, there are scenarios
   where the client may not wish to wait for the normal retransmission
   timeout before giving up (e.g., on power down).

(I guess we could argue here that 3315 should say "Because Release or Reply messages may be lost ...". Perhaps another 3315bis item if we haven't caught this already? No, at least not as of the bis 02 document.)

On the other hand, I'm also not sure how serious this issue is. The Relay is probably keeping some state about what addresses/prefixes are in use by what clients. So, when a Release is received, it can at least validate that the client has this lease and remove it. If a rouge client did the Release, what happens? I guess that depends on what the Relay is doing with this information. If the Relay is also acting as a router or network traffic cop, such as in DOCSIS CMTS, when a unknown addresses is seen, the Relay does a Leasequery to the server to ask it who is using this address. If it gets back information, it updates it state tables and all is well. (Note that PD leases can be recovered - as the Leasequery will return the PD lease containing the address). The only bad thing when the Relay removes the lease early is that if it was injecting the PD into the routing table, that would obviously stop and potentially be a problem.

Note that Bulk LQ might also be needed by the Relay to recover state if the relay loses stable storage? Hence, using Active LQ may not be such a stretch to avoid these security holes.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[e-mail]] On Behalf Of Templin, Fred L
Sent: Friday, August 08, 2014 12:48 PM
To: Ted Lemon
Cc: [e-mail]; Ralph Droms
Subject: Re: [dhcwg] DHCPv6 RAAN options

Hi Ted,

> -----Original Message-----
> From: Ted Lemon [mailto:[e-mail]]
> Sent: Friday, August 08, 2014 9:34 AM
> To: Templin, Fred L
> Cc: Ralph Droms; [e-mail]
> Subject: Re: [dhcwg] DHCPv6 RAAN options
> 
> On Aug 8, 2014, at 12:24 PM, Templin, Fred L <[e-mail]> wrote:
> > It is a link-layer consideration that occurs below the IPv6 layer.
> > So, yes it is DHCPv6 over a specific link layer.
> 
> Right, I don't think this makes sense as an Internet standard unless 
> there's some broad applicability, in which case that would have to be documented as a DHCP extension first.
> 
> > If that is still troubling, then please also consider the case of a 
> > link that is physically constrained to have only a single
> > DHCPv6 relay.
> 
> A special extension to DHCP just to account for this use case seems like the wrong approach when you
> consider the general applicability of the DHCP protocol.   ISTM that either solution we've talked
> about would work for you as a private hack, but the question is which 
> one (if any) makes sense as a standard extension to DHCP.

Just so we can be clear on the alternatives, the first one we talked about was to ask the server to include in its Reply message any IAs that were released as a result of the client's Release message and with lifetimes set to 0. The second alternative was to resurrect RAAN options somehow.

If I am understanding this correctly, then the RAAN option provides a convenient way of relay agent gleaning. But, option 1 would still allow for a slightly less convenient means for gleaning.

Thanks - Fred
[e-mail]

_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg