Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

[Leaf yeh <[e-mail]>]

Section 11 of RFC3315 - <quote>If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is not a link-local address, then the client is on the link identified by the source address in the IP datagram (note that this situation can occur only if the server has enabled the use of unicast message delivery by the client and the client has sent a message for which unicast delivery is allowed).</quote>

The above sounds the client could use the GUA for sending its message instead of LLA in some case. Supposed the client also knows the GUA of the server like the case of the relay. Then the technical question turns to be: if the assumption sounds the client already has its GUA of IPv6 (at its WAN interface?), why not use it directly for the stateless configuration.


Best Regards,
Leaf


-----Original Message-----
From: Ole Trøan [mailto:[e-mail]] 
Sent: Wednesday, September 26, 2012 4:49 PM
To: Ted Lemon
Cc: Leaf yeh; dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Ted,

>> the use of a relay message is purely to get around the 3315 restriction of using a link-local address.
>> the client is local to the node. assume for arguments sake that in the implementation the client is acting also as the relay.
> 
> I suspected as much.   IMHO, this is the wrong thing to do.   Just use the tunnel endpoint address instead of the link-local address in the case where there is no link-local address.   You'd have to make this standards-track and update RFC3315, but I think that's okay.   There's no magic to using the link-local address on broadcast interfaces-it's just the one address we can always count on the client having.   Of course, in this case we can't count on that, and if you look at section 1.1 of RFC3315 and section 11, you can see that the standard already accounts for cases where the link-local address is not used.   Actually, it looks like the spec may have a bug with respect to unicast that needs to be fixed.

I think we should do this too. let us make sure we get that into the RFC3315bis that I clearly remember you volunteered to write. ;-)
this draft proposes a solution that only affects the client implementation though (that is changing anyway), so I think we need this for a deployable solution.

cheers,
Ole