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

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 23 Feb 2012 20:34:21 +0100

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.

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?

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.

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.

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.

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.

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.

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".

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.

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).

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

Hope that helps.

Tomek