Re: [dhcwg] about v4configuration and co (1)

Ole Troan <> Tue, 13 August 2013 08:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3944321F9ADF for <>; Tue, 13 Aug 2013 01:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rqq+u0bgL-wC for <>; Tue, 13 Aug 2013 01:20:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4BBDB21F999E for <>; Tue, 13 Aug 2013 01:19:47 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjcFAMTqCVKQ/khM/2dsb2JhbABbgwa/XIEcFnSCJAEBBAE6PxALRlcGLodvBrdKkA8zB4MbdgOUDZUogx06gSwH
X-IronPort-AV: E=Sophos;i="4.89,867,1367971200"; d="scan'208";a="16610664"
Received: from ([]) by with ESMTP; 13 Aug 2013 08:19:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r7D8Jcrx030614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 08:19:39 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ole Troan <>
In-Reply-To: <>
Date: Tue, 13 Aug 2013 10:19:38 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Francis Dupont <>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [dhcwg] about v4configuration and co (1)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Aug 2013 08:20:09 -0000


>>> First I am explaining my comment at the dhc/sunset4 meeting yesterday:
>>> "DHCPv4 is not really over UDP/IP"
>>> What I mean is no genuine IPv4 stack is able to send or receive
>>> a DISCOVER message from a booting device: this message has the
>>> format of an UDP/IPv4/ethernet-like packet but has only the format.
>> can you explain what you mean by "DHCPv4 is not really over UDP/IP"?
> => I believe I explained what I mean by this statement?
>>> - DHCPv4 over softwire works well if all nodes already have IPv4
>>> addresses.  If they have none one enters in difficulties which are
>>> IMHO the direct consequence of the "DHCPv4 is not really over
>>> UDP/IP".  So if the requirements include to asignment of IPv4
>>> addresses to nodes without one (and they should include this) then
>>> the DHCPv4 over softwire is not a good solution.
>>> Another point is DHCPv4 over softwire can require a ALG (Application
>>> Level Gateway) at the server exit point in order to provide the
>>> IPv6 address (or any topological ID) to the DHCPv4 server.
>> I tested DHCPv4 over a softwire with my favourite implementation and
>> that worked out of the box.
> => did you check your favourite implementation is really using the
> IP stack? Usually DHCPv4 uses a link-layer access like BPF so relies
> on the correct support in the link-layer for this specific usage
> (so it can work with one implementation but not the other, if
> you are unlucky the client and the server won't interoperate, and
> you'll have nobody to blame because the case is not described in
> the specs...).

my favourite implementation does indeed use the IP stack.
that IP stack supports sending packets to the broadcast address from the unspecified address.
no magic with regards to that. my favourite implementation also give direct access from
applications to the link-layer for that matter. ;-)
I don't understand what you mean by "not described in the specs". 

>> DHCPv4 in that it uses broadcast requires a link-layer that supports
>> broadcast.
>> given that a softwire is a p2p link, it does support broadcast (and
>> multicast).
> => usually the issue with DHCPv4 and encapsulation is not the packet
> format (there is a straightforward way for it) but the sanity checks
> at the other (here DHCPv4 server) side: how the set the expected source
> address without a little idea of what it is?
> Note this doesn't make impossible to work, just it requires specific
> support (and specifications if you want interoperability).

sounds to me like you are describing problems that certain implementations would have with
implementing this. I gave existence proof of an implementation that doesn't.

>>> To finish it is not hard to modify a DHCPv4+DHCPv6 server code
>>> to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6
>>> or even both over IPv6 and IPv4. The idea is to plug the IPv6
>>> I/O subsystem to the DHCPv6 handler. IMHO it should not be
>>> significanly different (i.e., harder / easier) to support
>>> DHCPv6 over DHCPv4 (note this is for the server code).
>> just to make my own views clear:
>> - coupling IPv6 and IPv4 provisioning together is a bad idea
> => I believe you mean provisioning at the server side (note no
> supported solution requires such a coupling).
>> - I don't think requiring IPv4 specific configuration information
>> on a softwire is necessary, if you really have to do it I'd prefer
>> for the IPv4 provisioning protocol to run over the IPv4 data path
>> (aka the softwire). and the same solution could be used for Public
>> 4over6, LW46, MAP, L2TP...
> => the problem is sbout the IPv4 provisioning: if it includes IPv4
> address provisioning it should not run over the IPv4 data path.
> BTW the I-D is not enough clear about this point to be a critical
> requirement or not... (and I raised this concern in my review before
> the slide about real (vs info only) DHCPv4 over softwire slide).

you state that "IPv4 address provisioning should not run over the IPv4 data path".
what makes a softwire different from an Ethernet?
it supports broadcast, and the restriction that the first-hop router must be a DHCP relay or server
applies, but what makes this link-type so different that we need to invent new provisioning mechanics for it?

when we designed e.g. 6rd and MAP that was certainly not the intention.