Subject: RE: [dhcwg] Feedback on Layer 2 Relay Agent functionality

From: David Miles <[email-masked]>
Date: Tue, 6 Nov 2007 20:21:29 +1100

With the recent discussions around Layer 2 Relay Agents (such as that  
described in DSL Forum TR-101 Appendix B) has there been consideration  
of the equivalent for IPv6?

Today Layer 2 Relay Agents are an integral part of TR-101 when N:1  
VLANs are used. As we move towards IPv6 deployments there is a desire  
to keep the fundamental layer 2 architecture (N:1) which suggests a  
similar function for DHCPv6 in the DSLAM.
Like the current DSL Forum L2 DHCPv4 Relay Agent, the purpose for the  
relay agent is to add DHCPv6 Remote ID (equivalent to DHCPv4 Option  
82) so that a server can determine policy based on value matching.

In DHCPv6 things become more challenging as for starters there is no  
real "layer 2". There seem to be two general options:

1) Implement a DHCPv6 Relay on the DSLAM
	- Implication is that the DSLAM must then have a IPv6 address (link- 
local) and stack, participating as an actual node in the N:1 VLAN (ie,  
the DSLAM should perform DAD and possibly ND)
	- As the DSLAM does not act as an IPv6 router, the Relay-Forward link  
address would be unspecified and thus requires the addition of  
Interface ID
	- The interface ID itself could then be used to convey the "circuit"  
to the router

2) DSLAM inserts Option 37 (Remote ID) into DHCPv6 messages
	- Inserts information into a client-sourced Solicit without the  
client knowledge
	- Minimal impact on the DSLAM (no need for complete IPv6 stack
	- Not supported by DHCPv6 (RFC 3315) as Option 37 is a Relay Agent  
Option

I wouldn't suggest the above satisfactorily explores the issues  
relating to DHCPv6 Relay Agents in a DSLAM, but hopefully it may stir  
some ideas. IPv6 deployments are just on the horizon for carriers but  
without clear directives we could see multiple (and incompatible)  
approaches.

My apologies if this has been discussed prior (I couldn't find any  
direct references in the archives)

Regards,

- David

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 6 Nov 2007 10:15:09 -0800

> of the equivalent for IPv6?

I believe it has been discussed...it's an integral part of DHCPv6,
this seems to have been a design consideration.  The things we've been
talking about are places where perhaps some clarification is in order;
in particular that they will simply behave like a regular DHCPv6 relay
agent - the only exception that they will send a zero-filled
link-address value (3315 makes no explicit statement about what to do
here, and some implementers have asked if they should fill it with a
link-local address...).

For this reason, servers use the outermost link-address value that
is nonzero for client link detection ("unless otherwise configured"),
something that is also not concretely defined ("exampled?") in 3315.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: David Miles <[email-masked]>
Date: Wed, 7 Nov 2007 09:12:11 +1100

Thanks David,

This aligns with what I had assumed for option 1. I'd assume its also  
legal to set the IP destination of this DHCPv6 Relay-Forward to the  
All-DHCPv6-Servers MC address (fe02::1:2)? One consequence of  
implementing a full DHCPv6 relay on the DSLAM is that the DSLAM is now  
an IPv6 host within each VLAN and must therefore respond to DAD and ND  
from both clients and the BNG (as an example, of course there is far  
more than this). This could introduce significant complexity into the  
implementation with little apparent benefit, after all the relay agent  
in the DSLAM is not trying to unicast the traffic directly to a server  
- it is simply inserting Remote-ID.

When you say it has been discussed, does that imply a preliminary  
conclusion has been reached? I don't suppose you know roughly when it  
was discussed so I could trawl through the archives? While DHCPv6  
relay is an integral part of RFC 3315 I'm not aware of a discussion  
around TR-101 L2 DHCPv6 Relay, though I see there was one recently for  
IPv4.

Regards,

-David