Subject: Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-00 comments

From: Peng Wu <[email-masked]>
Date: Fri, 9 Mar 2012 16:23:29 +0800

Hi Tomek,

Sorry for my late reply. Thanks for your valuable comments. See inlines.

> ------------------ Original ------------------
> From:  "Tomek Mrugalski"<[email-masked]>;
> Date:  Fri, Feb 24, 2012 03:34 AM
> To:  "[email-masked] WG"<[email-masked]>;
> Subject:  [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-00 comments
>
> Hi,
> I just read this draft and have several comments. I have mixed feelings
> for such mechanisms, but I suppose that is a necessary evil. For that
> reason I support this draft.
Thanks for your support:)

>
> Current version of this draft omits one case that is quite important
> IMHO. What if I can't modify my host, e.g. because it is a device (like
> aforementioned blu-ray player or something much more costly, like
> dedicated machines e.g. high performance printers) that does not allow
> running third party software or its vendor is unable/unwilling to
> provide such update?
Yes. This case is not coverd by the current draft. However, my question here
 is, will it be necessary?
The draft is generally used to allocate IPv4 address over IPv6 network. The
host applying this mechanism uses this IPv4 address in IPv6 environment
for certain purpose, for example, use it as the IPv4-over-IPv6 tunnel address.
Now for a blu-ray player or a printer, it usually locate in a home network.
Even if it support IPv6 beside IPv4, I don't see the purpose to drive
it to acquire
IPv4 address from a remote server through IPv6.

>
> Why CRA must be placed on the same host as client? CRA could be anywhere
> on the same link as hosts, right? Also, it can be shared between many
> clients. These are my assumptions. If they are true, something to that
> effect should be added to the text.
Yes. Theoretically CRA can be on the same link as hosts. Then it looks very
much like an actual normal DHCP relay, except that the two side of the relay are
in different address families. However, it'll quite broaden the
picture. Originally we
only want to design a mechanism to enable the DHCPv4 procedure between host
and server/relay both in IPv6 network, CRA is used as a "virtual" concept. You
are suggesting the scenario like "host--IPv4(or dual-stack) LAN--CRA--IPv6
network--TRA/TSV". This is interesting, but again I guess we should
consider the
purpose/motivation,

>
> Section 6 mentions that CRA is being provisioned with TSV/TRA address.
> Why CRA can't use normal DHCPv6 mechanism for that? I think it could use
> server unicast, already defined option in DHCPv6. Dual-stack
> (DHCPv4+DHCPv6) server could easily distinguish between regular DHCPv6
> traffic and DHCPv4-encapsulated-in-IPv6 traffic as they are sent to
> different
> ports.
CRA need an IPv6 address, to be the destination of unicast DHCP messages,
and CRA can't discover this address itself. The particularity in this
case is that
the communication could only be IPv6-unicast from the very begining.
We could use a DHCPv6 option to deliver the information during DHCPv6
process for the host. But I'm not sure what you are suggesting here with server
unicast option and dual-stack server. Could you please be more specific?

>
> I would rename this 6ADDR to something else. Someone (who didn't read
> the draft) could be mislead to think that this option allows you to
> configure IPv6 address using DHCPv4.
Indeed. We'll rename it.

>
> Have you considered other alternative: put whole DHCPv4 into DHCPv6
> option and then send it as DHCPv6 packet (possibly as relay-forw)? It
> would have one mayor advantage of being able to reuse existing deployed
> DHCPv6 relays. I haven't thought this through, so there may be pitfalls
> here, but regular DHCPv6 relay is not supposed to inspect packet too
> deeply (like dropping it because of missing client-id), so it may work.
> On the other hand, that would work only for dual-stacked servers, so
> its usability is somewhat limited.
Yes, we considered that. I think the bottom line is we are still running
DHCPv4, and we still need a DHCPv4 server rather than DHCPv6 server
to process all the requests and options, so we stick to DHCPv4. Maybe Ted
can help to explain better here:)

>
> My understanding is that server basically echoes 6ADDR option back, if
> present. Does it differ in any way server normally processes Relay Agent
> Information option, as defined in RFC3046? Something to that effect
> should be added to Section 7.
I think it should follow exactly what RFC3046 said. We'll put a sentence on
this in the draft, for clarification.

>
> In section 8 (and many other sections) you state that packet is
> forwarded to IPv6 address. Please clearly specify destination port
> number. I assume it should be 67, but it is better to make is clear.
> There should probably be a statement along the lines: "TRA SHOULD (or
> even MUST) drop DHCPv4-over-IPv6 traffic that is not originated from
> configured server address".
Yes, we stated this in section 6. Seems it is not enough, ha. We'll emphasize
it more and also add the sentense you put here.

>
> Security considerations section should discuss cases, where TRA can be
> exploited to forward traffic. It is probably of limited usefulness, but
> still I think it could allow to attack IPv4 machines from IPv6 Internet.
> If port restrictions are added as suggested, this potential attack
> vector would be limited to DHCPv4 protocol only.
Yes. We'll put the case of DHCP protocol attack. BTW, I guess it's no different
from the situation today except the attacker and the victim(could be the host
or the DHCP server) are in different address families, right?

>
> Security considerations should discuss that DHCPv4 traffic over IPv6
> will most likely bypass existing firewalls (that can filter DHCPv4 over
> IPv4 and DHCPv6 over IPv6).
Good point. We'll add this effect.

>
> Editorial comments:
> Section 4, first paragraph: shoudl => should
>
> Second paragraph: Discussion about applicability would be useful. What
> if the host is a device that I cannot modify to run extra software?
>
> Paragraph above Fig. 2.
> Since Option 82 doesn't has => Since Option 82 doesn't have
Thanks and sorry for that :--)

> Hope that helps.

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