Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt

Ole Troan <otroan@employees.org> Wed, 30 October 2013 12:58 UTC

Return-Path: <otroan@employees.org>
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 9A57311E81D6 for <dhcwg@ietfa.amsl.com>; Wed, 30 Oct 2013 05:58:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.433
X-Spam-Level:
X-Spam-Status: No, score=-10.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 jzaF5O6AXyaE for <dhcwg@ietfa.amsl.com>; Wed, 30 Oct 2013 05:57:57 -0700 (PDT)
Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id A219D11E8227 for <dhcwg@ietf.org>; Wed, 30 Oct 2013 05:57:44 -0700 (PDT)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAMABcVKQ/khN/2dsb2JhbABZgwfAWYEmFnSCJQEBBAF5BQsLEjRJDgYuh2YGun6OEIE/B4MfgQ0DkC2ZZoMnO4Es
X-IronPort-AV: E=Sophos; i="4.93,601,1378857600"; d="asc'?scan'208"; a="19125708"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 30 Oct 2013 12:57:43 +0000
Received: from dhcp-lys01-vla250-10-147-113-158.cisco.com (dhcp-lys01-vla250-10-147-113-158.cisco.com [10.147.113.158]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9UCvd9k032242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 12:57:40 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_BF1B5561-2784-4BB8-BBB4-C104F275E569"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <CE952CF3.8EDA1%ian.farrer@telekom.de>
Date: Wed, 30 Oct 2013 13:57:39 +0100
Message-Id: <475F6A13-002D-481A-A73A-CDC36F9A0AD8@employees.org>
References: <CE952CF3.8EDA1%ian.farrer@telekom.de>
To: "<ian.farrer@telekom.de> Farrer" <ian.farrer@telekom.de>
X-Mailer: Apple Mail (2.1816)
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-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: Wed, 30 Oct 2013 12:58:03 -0000

Hi Ian,

> Thanks for the review. I¹ve updated the draft based on your comments. And
> some more answers in line.

thanks, some more comments inline.

>> yes, I think a clarification in the introduction would help.
>> stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see how
>> it applies to MAP.
>> which link-layer did you have in mind for this?
>> is this work meant to also provide stateful DHCPv4 for MAP tunnels?
> 
> [ian] It¹s not meant to be limited to any particular softwire or other v4
> type. If someone was to have a reason for using stateful DHCPv4 for MAP at
> some point in the future, then this IPv4 configuration

the analogy to doing address assignment with DHCPv4 on a MAP tunnel,
would be to do DHCPv4 address assignment on top of IPCP for a PPP link-layer.
MAP already provides the IPv4 address, so I can't quite see how stateful DHCPv4
makes sense with MAP. can you explain?

>> e.g. a configured RFC2473 tunnel or Public 4over6, could work.
>> 
>> when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't
>> really do that.
>> I don't see that described in this document?
> 
> [ian] The draft¹s concerned with how IPv4 configuration is transported,
> not what the specific v4 configuration is.

understood.

>> I think we need to evaluate if there should be a completely new option
>> for IPv4 address and port set, or
>> a the classic IPv4 address option combined with a new port set option.
> 
> [ian] There¹s a couple of drafts out there that do this at the moment:
> draft-sun-dhc-port-set-option & draft-farrer-dhc-shared-address-lease. I
> think that it¹s better to handle the format and other considerations
> around option formats and shared address leasing separate from the
> transport question covered in this draft.

OK.

>>>> Section 2:
>>>> Drop requirement 6, I can't see how you can evaluate that.
>>> 
>>> [ian] You can evaluate it on the following basis: If the requirements
>>> that are described in this document are not your requirements as an
>>> operator, then you shouldn't be forced to use whatever the conclusion of
>>> this document is. In practical terms, I see this as 'if MAP DHCP meets
>>> your requirements, you don't need to bring in DHCPv4 over Foo or
>>> whatever else'.
>> 
>> I didn't quite understand the implications of that.
> 
> [ian] During the discussion in Atlanta that led up to writing this
> document, an opinion voiced by several operators was: If I can provision
> everything I need using simple, static DHCPv6 (I.e. Option map), why
> should I have the additional overhead of a DHCPv4 providing additional
> DHCPv4 options and dynamic leasing which is unnecessary to me?
> 
> The requirement is there to evaluate whether a solution allows you to do
> that.

OK, so the requirement is to not make DHCPv4 mandatory, for the cases
where the underlaying mechanism provides the required information.
isn't that a no-op? if you don't care about DHCPv4 then don't use it...?

>>>> 8 is empty
>>>> 
>>> [ian] Will fix.
>>> 
>>>> I suggest you add a new requirement:
>>>> x. Fate sharing. The provisioning of IPv4 addressing and other
>>>> configuration information should be logically tied
>>>>    to the data-link layer that is uses to provide IPv4 connectivity.
>>> 
>>> [ian] This one's going to be more of a problem, as it pretty much
>>> directly conflicts with requirement 7, in that the two contradict each
>>> other. You can only implement data link fate sharing if you've got a hub
>>> and spoke architecture to locate the hub in (so that if it's not
>>> available, then IPv4 provisioning also fails)
>> 
>> which link-layer fails that?
>> I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 is
>> restricted to there being a DHCPv6 transport available.
> 
> [ian] There¹s a slot for this draft in Vancouver. Can we discuss it there
> as this has a direct effect on the outcome?

I'm not going to be there physically, but we're trying to do a remote participant experiment.

>>> In the case of a pure mesh network, with no hub and spoke, how could
>>> you have fate sharing for the data-link layer? The proposed requirement
>>> pre-supposes a specific underlying architecture.
>> 
>> is this the equivalent to the dentist's office case? can you give an
>> example of other data link-layers where IPv4 can be provisioned on a NBMA
>> link, without a router?
> 
> [ian] Not familiar with the Dentist office in this particular context.
> 
> The obvious example would be a single Ethernet segment with a DHCP server
> attached, but I¹m not sure how that¹s relevant to this discussion.
> 

indeed, I don't think we need to consider the mesh case without a BR for MAP.

>>> Can we put this one to the workgroup to ask if this should be included
>>> as a new req, as it' has not been previously discussed?
>>> 
>>>> 
>>>> Section 3:
>>>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
>>> 
>>> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6
>>> draft:
>>> 
>>> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>>>  dedicated DHCPv4 over DHCPv6 specific destination addresses,
>>>  differing from the addresses of the DHCPv6 only server(s).  To
>>>  implement this function, the relay checks the received DHCPv6 message
>>>  type and forwards according to the following logic:
>>> 
>>>  1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>>>      relayed to the configured DHCPv4 aware 4o6 Server's address(es).
>>> 
>>>  2.  For any other DHCPv6 message type, forward according to section
>>>      20 of [RFC3315].
>> 
>> DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages in
>> DHCPv6 servers and clients.
> 
> [ian] Or, you could add a minimal DHCPv6 encapsulation to a DHCPv4 server.

right, but then the DHCPv6 relay would have to support sending DHCPv6 messages
to multiple servers.

>> what do you mean by "independent DHCPv4 and DHCPv6 servers" then?
> 
> [ian] if you wanted to deploy DHCPv6 servers and DHCPv4overDHCPv6 servers
> as separate instances, you can. Given how complex the DHCPv6 server logic
> can become, there¹s some good reasons no to overload the DHCPv6 server
> with DHCPv4 functions as well.

absolutely. that applies even more to running DHCPv4 over the link-layer directly.

> 
>> could you clarify the requirements?
>> now they do read like they have been reverse engineered.
> 
> [ian] Extended the definition with an explanation.

ack.

[...]

>>>>        bullet 5. change to "Restricted to a broadcast capable
>>>> link-layer."
>>> 
>>> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, I
>>> don't see how this approach can work in a mesh environment. The
>>> 'broadcast capable' restriction is not correct as if a h&s softwire can
>>> support broadcast, then a ptp mesh softwire can as well. You could
>>> broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to
>>> get you any response.
>> 
>> MAP in mesh mode, still has a point to point tunnel to the BR.
>> we have not described MAP in a 'pure' mesh mode, i.e. without a BR.
> 
> [ian] This document isn¹t meant to be limited to MAP mesh. E.g. RFC5565.

yes, my point was that you don't need to create the corner case for MAP,
where there is no BR. we haven't described that anywhere, so don't use
that as a reason why MAP cannot provide a link-layer that you can run
DHCPv4 on top of.

>>>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from each
>>>> other since it 
>>>>        it is DHCPv6 that provides transport for DHCPv4. and support
>>>> for the new BOOTP messages
>>>>        are required in DHCPv6.
>>> 
>>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed
>>> separate from the DHCPv6 only server. What about changing to read?:
>>> 
>>> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'
>> 
>> as long as there is a DHCPv4 message capable DHCPv6 server.
> 
> [ian] Sure. But if you didn¹t have a DHCPv4 capable server, then you
> wouldn¹t have sent the DHCPv4pDHCPv6 client the option to tell it to
> attempt DHCPv4oDHCPv6 configuration.

from an architectural point of view, I don't really like signalling in IPv6 how IPv4 should be provisioned
and vice versa. Mark Townsley and I have an expired draft showing the complex state machine
that results in. I'd much rather prefer ships in the night.

cheers,
Ole