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

[Leaf yeh <[e-mail]>]

Tomek - Where are we with the 3315bis plans? I know that it is a major work, ..., but for such a grand purpose I will find some time.

I'd also like to join the plan if I could provide any help.


Best Regards,
Leaf


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Tomek Mrugalski
Sent: Friday, September 28, 2012 5:15 AM
To: [e-mail]
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

On 12-08-10 14:42, Ted Lemon wrote:
> The authors of this draft have requested a working group last call.
> The draft explains how DHCP clients operate in an environment where
> the interface being configured doesn't support multicast (e.g., 6RD).
> If this is a matter of interest to you, please review the draft and
> send comments to the list.
> 
> If you are in favor of advancing the draft, please say so on the
> list; if nobody supports it, it won't advance.   If you oppose
> advancing it, please also say so.   We will determine consensus on
> August 24.
Hi,

I'm terribly sorry for not joining the discussion earlier. I'm in favor
of advancing the draft, but not in its current form.

In my opinion allowing the client to send every message encapsulated in
relay-forw will not give you much, but will just bring more problems. In
particular:

- What would you put in the peer-addr and link-addr fields of the
relay-forw message? Bernie's suggestion for putting 0s in peer-addr
makes sense, but what about link-addr? Would you put CE's global unicast
address there? That would work, but in many cases it would scale up
poorly. If you have 1000 CEs in your network, you would potentially need
to configure 1000 subnets as the server is supposed to use link-addr to
find out those links. Some servers require explicit network topology
information (i.e. listing all links that the server is supposed to
support). On the other hand, you can define one large subnet that covers
all your 6rd CE's global addresses, but that would not work in certain
implementations. This leads to a question if the server is supposed to
treat all CEs as being the same or different links.

- This draft mentions DNS, SIP and NTP options. Are we talking stateless
or stateful (or both) here? That should be clarified.

- The argument for not having to update 3315 is weak. There are couple
inconsistencies in it and there's 3315 bis planned anyway. To be more
specific, This statement "client MUST use link-local address..." from
3315 is in direct contradiction with a another sentence from section
18.1 of 3315: "If the client has a source address of sufficient scope
that can be used by the server as a return address, and the client has
received a Server Unicast option (section 22.12) from the server, the
client SHOULD unicast any Request, Renew, Release and Decline messages
to the server."

Have you considered a different approach? Something like this:

1. Say that any DHCPv6 solution working over tunnels (or non-multicast,
no link-local interfaces in general) MUST support server unicast.
2. Make the 6rd CE send normal messages (not relayed) from its global
address to 6rd BR anycast address.
3. Extend the server unicast to work on solicit, confirm, rebind and
inf-request. (update 3315, section 15, second paragraph).
4. Optionally update 3315 to point out inconsistencies regarding source
address ("MUST use link-local address..." in section 16 vs. 18.1 "If the
client has a source address of sufficient scope..."). That is really
optional, as any server that implements server unicast already disobeys
that rule.

This will work on all servers that adhere to sections 17.2.2 (advertise)
and 18.2.8 (reply): " If the Solicit message was received directly by
the server, the server unicasts the Advertise message directly to the
client using the address in the source address field from the IP
datagram in which the Solicit message was received.".

I understand that you want to have it deployed as soon as possible, but
we have 3315bis work planned anyway, so there will be changes and that
is unavoidable. And with the server-unicast approach, it really isn't
that big change.

Step 4 will happen anyway. So it's a matter of updating section 15:

"A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address."

to

"A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address, unless explicitly configured to use server unicast option with
that address.".

If we are concerned of any possible side effects in normal deployment
scenarios, we may work out some extra safety checks (add "... and the
receiving interface does not support multicast nor link-local addresses").

Sure, expecting the client to magically know server address when sending
the first solicit is odd, but if we want to make DHCPv6 work on
non-multicast, no link-local interfaces, we need to make some
compromises. I very much prefer that approach, compared to the server
reporting that there are 1000s of new relays or server starting to
blindly accepting unicast messages.

On the other hand, there's RFC6276 that talks about co-locating relay
and PD client, so the effort to avoid it is already lost.

Editorial comment:
"The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast
address as the destination address, section 20 of [RFC3315]". That
reference to section 20 of RFC3315 is strange. Section 20 describes
relay operation. What exactly authors want to point to in this context?

Hope that helps,
Tomek

p.s.
Where are we with the 3315bis plans? I know that it is a major work, so
it is not easy to commit to it, but there are more and more things that
require update. I'm already overburdened with the failover work and
other stuff, but for such a grand purpose I will find some time.



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