Subject: [dhcwg] about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Mar 2012 19:23:43 +0100

Two comments about draft-ietf-dhc-dhcpv4-over-ipv6-01.txt from
implementation and experiment:

 - when IMHO it is a good idea to weaken the "sits on the same,
  IPv6-accessable host with the DHCPv4 client." to the more standard
  for a relay "sits on the same link than the DHCPv4 client.",
  this should not be done with control: it is very nice to serve
  a DHCPv4 client with a CRA running on another box, but it is less
  nice to get 3 clients colocated with 3 CRAs on the same link
  duplicating all queries three time (:-).
  So I propose to recommend a flag which limits the scope of
  the CRA service. BTW I have no opinion about what should be
  its default value.

 - there can be a real issue with the server identifier as it is now
  possible for a TSV to have in fact no IPv4 address (or no IPv4
  address suitable for a server identifier content).
  Note the server identifier is required (cf RFC 2131) and
  some clients complain when it is not presented, but I think
  the deep source of the issue is its double function:
  "The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers." Of course the second doesn't match the IPv6 transport
  idea, in particular when one wants to see all DHCPv4 being
  transported over IPv6 for any reason (and I can see many...).

Regards

[email-masked]

---

From: Peng Wu <[email-masked]>
Date: Thu, 22 Mar 2012 10:02:24 +0800

Hi Francis,

Thank u for raising these comments in the mailinglist.
Please see inline.

>  the CRA service. BTW I have no opinion about what should be
I think the case of CRA locating on the host and on the link is no
doubt important.If you see from outside the host, what we do is
actually to have the DHCPv4 client to send and receive message in
IPv6. It already has the application scenarios of public 4over6,
lightweight 4over6 in SOFTWIRE WG. And I agree the case of CRA on the
link is reasonable, too, in the case where we cannot update the DHCP
code in the client.
Now to the issue you raised, I think in the 2nd case, the CRA should
be on the same link as the host, and it should have IPv6 access. So
it's kind of the gateway in the usual case, and naturally there is
only one CRA which serves all the clients.
If there do exists multiple CRAs on the same link, what about refering
to the standard procedure of multiple relay on the same link, if there
is any?

>  transported over IPv6 for any reason (and I can see many...).
Yes, the second usage doesn't match. About the first usage, what about
we fake an IPv4 address and fill in the server id field? We could
extract 32 bits from the interface id in the IPv6 address, or hash the
128 bit IPv6 address to for the 32 bits. Is it good enough for server
identification?
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Mar 2012 12:23:20 +0100

>  to the standard procedure of multiple relay on the same link, if there

=> all the relays forward to all the configured servers, for responses
they are sent to relays so there is no further duplication.

>  128 bit IPv6 address to for the 32 bits. Is it good enough for server

=> it is good but it breaks the second usage so it won't work...

Regards

---

From: Peng Wu <[email-masked]>
Date: Thu, 22 Mar 2012 22:51:11 +0800

Hi Francis,

> they are sent to relays so there is no further duplication.
So you believe this is especially harmful in the over-IPv6 context?
I'm sorry that I'm still a little lost...
Could you explain why and how the flag you proposed work? Thanks

> => it is good but it breaks the second usage so it won't work...
Sorry, apologize that I misunderstand what you point in the previous mail.
Here are some thoughts on this issue,
1)For the case of CRA co-locating with host, this should not be an
issue because we'll use IPv6 unicast, no matter what is written in
this field. We should state it in the draft.
For the case of CRA on the link:
2)Make it mandatory that the client send out DHCP message in broadcast
manner in this scenario, or
3)Make the CRA to be the gateway and relay unicast DHCP messages;

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Mar 2012 10:06:31 +0200

>  So you believe this is especially harmful in the over-IPv6 context?

=> no and BTW this is what you want when you have many relays to
serve the same link, or configure a relay with many server addresses.

>  Could you explain why and how the flag you proposed work? Thanks

=> as the same code is able to serve the colocated client or the
whole link, IMHO a flag is required so the administrator is able
to choose between the two available scopes of service.
Now about the way to implement it: check if the query comes
from the same box or not.

>  this field. We should state it in the draft.

=> you miss the point: some clients use the server-identifier to
unicast in IPv4 the request to the server (i.e., to the IPv4 /
the content of the server-identifier option).
So it is no related to the scope of the CRA service.

>  manner in this scenario, or

=> you can't change the behavior of the DHCPv4 client.

>  3)Make the CRA to be the gateway and relay unicast DHCP messages;

=> it doesn't work: nothing can be the IPv4 gateway for just a given
protocol and port.

Regards

PS: for anybody who is lost, the issue is the second part of:
  "The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers."
when you want to run the whole DHCPv4 protocol exchange(s) over
a not IPv4 transport.