[dhcwg] review of draft-ietf-dhc-dhcpv4-over-ipv6-02.txt

Francis Dupont <Francis.Dupont@fdupont.fr> Mon, 16 April 2012 13:01 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A356221F86B7 for <dhcwg@ietfa.amsl.com>; Mon, 16 Apr 2012 06:01:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Level:
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=-0.852, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_36=0.6, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX386HUcrjd8 for <dhcwg@ietfa.amsl.com>; Mon, 16 Apr 2012 06:01:57 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD6821F86A4 for <dhcwg@ietf.org>; Mon, 16 Apr 2012 06:01:56 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q3GD1tXK092227; Mon, 16 Apr 2012 15:01:55 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201204161301.q3GD1tXK092227@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: draft-ietf-dhc-dhcpv4-over-ipv6.all@tools.ietf.org
Date: Mon, 16 Apr 2012 15:01:55 +0200
Sender: Francis.Dupont@fdupont.fr
Cc: dhcwg@ietf.org
Subject: [dhcwg] review of draft-ietf-dhc-dhcpv4-over-ipv6-02.txt
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Apr 2012 13:01:57 -0000

Some editorial comments about draft-ietf-dhc-dhcpv4-over-ipv6-02.txt:

 - Abstract page 1: IMHO the abstract is not accurate (or was written
   far before protocol developments), for instance the "extending DHCP
   client and server behavior" is clearly wrong.

 - 1 page 3: perhaps you should add an appendix about usage scenarios
  (I can provide a real one for Stateless Deterministic NAT in DS-Lite
  mode if you want).

 - 3 page 4: I prefer the term "proxy" over the term "bridge" (because
  bridge is very layer 2 oriented, of course all of them are instance
  of the more generic "gateway")

 - 3 page 4: On-link -> On-Link (upper case L for the LCRA abbrev)

 - 3 page 4: if you really want to add something about multi-interface,
  the right place is in the LCRA definition, for example:
  "Note a LCRA serves only one link, e.g., the multiple link case is
   handled by multiple LCRA instances."

 - 2 page 4: TSV can listen -> TSV listens

 - 4 page 5: UDP(figure 2(a)). -> UDP (figure 2(a)).

 - 4 page 5: "TRA also communicates with a regular DHCPv4 server" is
   not fully true. The DHCPv4 server needs to handle CRA6ADDR
   suboptions, but note:
   * it is possible some DHCPv4 server provides a config hook for
     unknown RAI suboption, in this case the server code is not
     changed
   * I don't believe too much in the previous item because an IPv6
     address is not an opaque string of 16 bytes, i.e., there is an
     easy update to the server code which makes it suitable to handle
     CRA6ADDR suboptions...
   I don't know what to put here. Perhaps the current text is the
   best?

 - 4 page 5: Option(Option 82) -> Option (Option 82) or (better)
  Option (Option code 82)

 - 5 page 6: I can't get the intended meaning of
  "extract the semantic of IPv6 address". Perhaps it should be:
  "extract the IPv6 address"?

 - 6 page 7: I am not sure the MUST for the global address is
  really required, perhaps a SHOULD is enough? BTW you don't require
  any thing about the server/agent configured addresses...

 - 6 page 7: if it has onbe. -> if it has one.

 - 6 page 7: I don't buy the coexistence of a LCRA and a TRA because
  in this case it is far simpler to use a plain DHCPv4 relay. Note
  without a good reason to keep it the SHOULD fro LCRA could be
  upgraded to a MUST.

 - 6 page 7: the LCRA MUST serve any client on the link -> SHOULD
  (note the RFC 2131 doesn't require something to a relay :-)

 - 6 page 7: in the last sentence of 6 I'd like to get Tomasz's
  (Tomasza) idea: a CRA MUST be configured to serve either as a CRA or
  a LCRA, i.e., there is a configuration knob with no default.

 - 6 page 7: about:

   A TSV can also listen on IPv4 UDP port 67 like a
   normal DHCPv4 server, and process normally when receives IPv4 DHCPv4
   message.

   I coded this (i.e., a server which can support both standard DHCPv4,
   including of course behind a TRA, and the TSV function). So perhaps
   it is the time for a more visible MAY?

 - 7 page 8: if I have no concern about the "regular" in 4, this:

   This document places no new requirements on DHCPv4 servers that do
   not listen on UDPv6--in order to use an IPv4-only DHCPv4 server
   through an IPv6 connection, a TRA is required.

  is wrong. I suggest to add "other than to support the CRA6ADDR
  sub-option [section 5]"

 - 11 page 9: please ask Tomasz if he prefers Tomasz over the
   diminutive Tomek.

 - 12 page 9: the pagination is a disaster...

Thanks

Francis.Dupont@fdupont.fr

PS: I found in RFC 2131 this very interesting section:

3.6 Use of DHCP in clients with multiple interfaces

   A client with multiple network interfaces must use DHCP through each
   interface independently to obtain configuration information
   parameters for those separate interfaces.