Subject: Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07

From: David Hankins <[email-masked]>
Date: Fri, 21 Jan 2011 13:08:30 -0800

On Sat, Dec 11, 2010 at 11:04 AM, Ted Lemon <[email-masked]> wrote:

>   DHCPv6 server administrators should not configure DHCP servers to return
> more
>   than one AFTR-Name option in any given context.   If more than one
> AFTR-Name
>   option is sent, it will be treated as an error by the client.
>

After deliberation, I'm willing to relax this to SHOULD (along with the
other SHOULD for multilple names in one option) and provide the operator
direction.  I think for the long term, DHCP servers are going to need to be
able to determine when only a single value like this is "supposed" to be
sent in a given option, and to provide UI hints to the operator rather than
just not working and making the operator go hunt down logs on clients.

That is, server validation of operator configuration should happen in the
server, and not in the client (unless we're going to invest in a command
channel to send client parse errors back to server operator eyes).

In fact, it wouldn't be a bad idea if we described the sets of validations
and limitations we want to make on DHCPv6 options in the future, so that
software designers today can make a language so that new options can be
defined along with correct validation of configuration.

  It is an error for the DHCP server to return more than one AFTR-Name
> option.
>   If a DHCP client receives more than one AFTR-Name option, it SHOULD
> ignore all
>   AFTR-name options.
>

You're also changing the target behavior; I had it picking the first value.

I'm thinking of two cases in client class; clients that pass a text string
(e.g., writing a config file like ISC dhclient's /sbin/dhclient-script does)
are likely to just pass whatever long list of domain names the server has
supplied to the configuration knob it writes out; "aftr1.foo.com
aftr2.foo.com etc".  In this case, we expect the B4 to use the first name
and ignore the others.  The second possible client implementation passes a
binary structure or calling parameter to another task in the same running
system; this structure probably only has one field for the name, or maybe it
is just a 16 octet IPv6 address and the "dhcpv6 client" end of the software
does the resolution on B4's behalf.  I'm suggesting this client also should
trim the list down to just the first name.

I think the current language, that it MUST select the first option and MUST
select the first name appearing in the first option, fits current
implementation (ISC dhclient) and both environments (you'd have to reduce
the long list down to fit your single parameter call-out).

What I was doing, is I was referring (for simplicity's sake) to "the client"
to mean either software component; the DHCPv6 client or the B4 element it is
configuring, one of these two need to perform this validation (and it
doesn't really matter which one).

I've updated the text to add a new terminology, "a B4 system", as distinct
from the B4 element and the DHCPv6 client but whose specifications may be
implemented by either party (or even a third party in the middle, some
common system configuration software).

Hopefully this alleviates your concern that it changes DHCPv6 client
behavior.

-- 
David W. Hankins
SRE
Google, Inc.

---

From: David Hankins <[email-masked]>
Date: Fri, 21 Jan 2011 13:27:29 -0800

On Sun, Dec 12, 2010 at 11:42 PM, <[email-masked]>wrote:

> This version is almost Ok. I still have two comments:
>

Thank you for your constancy in review and participation.

I suggest to change

> "It SHOULD NOT permit the configuration of multiple names within one
>   AFTR-Name option."
>
> To
>
> "It MUST NOT permit the configuration of multiple names within one
>   AFTR-Name option."
>

So far as I'm aware, DHCPv6 servers today do not implement any restriction
on how many names can be configured if the server is informed that the
format of the new option is the RFC 3315 format domain name (in fact, in ISC
DHCP's v6 implementation, I called the atom to do RFC 3315 domain names a
"domain list" atom).

>From my point of view it can be validated that only one option can be
configured, but Ted has reminded me that this is not the case in all
currently conforming DHCPv6 server implementations.

So this would mean that current DHCPv6 implementations could not conform to
specification without software changes, something I was trying to avoid
(incompletely) with the "MUST / SHOULD" language this version of the draft
had.

"
>   If the client receives more than one AFTR-Name option, it MUST use
>   only the first instance of that option.
>
>   If the AFTR-Name option contains more than one FQDN, as distinguished
>   by the presence of multiple root labels, the client MUST use only the
>   first FQDN listed in configuration.
> "
>
> To "If the DHCP Client receives more than one AFTR-Name option or if the
> AFTR-Name option contains more than one FQDN, the DHCP Client MUST ignore
> the received AFTR-Name option(s))".
>

I think this would require a software change in current DHCPv6 client
implementations.  I can't speak for B4 implementations, but if I were a B4
implementor, I would also be concerned that if I conformed to this direction
and some other (it only takes one) B4 implementation didn't, then my
software would not work where other software does, and this reasoning would
not be very obvious to customers.

If we're shaping conformance language away from concrete validation and
towards current implementation practice, then I think we should do it both
on the server and client side.

(2) Multi-interface use case: this text has been introduced in 07:
>
> "   Note that a client may have multiple network interfaces, and these
>   interfaces may be configured differently; some may be connected to
>   networks that call for DS-Lite, and some may be connected to networks
>   that are using normal dual stack or other means.  The client should
>   consider the above on an interface-by-interface basis.  For example,
>   if the client is attached to multiple networks that provide the AFTR
>   Name option, then the client MUST configure a tunnel for each
>   interface separately as each DS-Lite tunnel provides IPv4
>   connectivity for each distinct interface."
>
>
> The text does not elaborate on how an interface is identified and how the
> server/client will proceed to enforce the received configuration for the
> appropriate interface. BTW, this issue is not specific to DS-Lite and it is
> generic to any MIFed device.
>

For this reason, I didn't want to elaborate.  The goal is to include text
that reminds the implementor that perhaps they should not follow a mindset
that they will have only one B4 element on their system, in the case where
they plan to have multiple external network interfaces, since we just
finished explaining carefully that there should be only one domain name sent
to configuration.  The danger is that they may configure only one tunnel
endpoint, either having only one B4 element running, or multiple endpoints
for each interface all using some single endpoint.  These would all be bad
decisions, which may seem reinforced by the specification's demand for a
single name.

Can you suggest simpler language?

-- 
David W. Hankins
SRE
Google, Inc.

---

From: <[email-masked]>
Date: Tue, 1 Feb 2011 08:28:47 +0100

Dear David,

Thank you for your answer.

I read the new version and the answers below:

* I still vote for clear language without taking care of the current implementations: since the aim is to convey one single option enclosing only one name; then the client and the sever behaviours should be provided accordingly (i.e., use of "must" instead of the "should").

* I see your point about the multi-interface text. This is fair. I would just add a sentence like:

"Means to bind a FQDN_NAME configuration to a given interface in a MIFed device are out of scope of this document."

Anyway, please do whatever you think it is appropriate to make this document progress.

Cheers,
Med

________________________________
De : David Hankins [mailto:[email-masked]]
Envoyé : vendredi 21 janvier 2011 22:27
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Alain Durand; [email-masked] list; Softwire Chairs
Objet : Re: [Softwires] WG last call on draft-ietf-softwire-ds-lite-tunnel-option-07

On Sun, Dec 12, 2010 at 11:42 PM, <[email-masked]<mailto:[email-masked]>> wrote:
This version is almost Ok. I still have two comments:

I suggest to change

To

So far as I'm aware, DHCPv6 servers today do not implement any restriction on how many names can be configured if the server is informed that the format of the new option is the RFC 3315 format domain name (in fact, in ISC DHCP's v6 implementation, I called the atom to do RFC 3315 domain names a "domain list" atom).

>From my point of view it can be validated that only one option can be configured, but Ted has reminded me that this is not the case in all currently conforming DHCPv6 server implementations.

So this would mean that current DHCPv6 implementations could not conform to specification without software changes, something I was trying to avoid (incompletely) with the "MUST / SHOULD" language this version of the draft had.

"

To "If the DHCP Client receives more than one AFTR-Name option or if the AFTR-Name option contains more than one FQDN, the DHCP Client MUST ignore the received AFTR-Name option(s))".

I think this would require a software change in current DHCPv6 client implementations.  I can't speak for B4 implementations, but if I were a B4 implementor, I would also be concerned that if I conformed to this direction and some other (it only takes one) B4 implementation didn't, then my software would not work where other software does, and this reasoning would not be very obvious to customers.

If we're shaping conformance language away from concrete validation and towards current implementation practice, then I think we should do it both on the server and client side.

The text does not elaborate on how an interface is identified and how the server/client will proceed to enforce the received configuration for the appropriate interface. BTW, this issue is not specific to DS-Lite and it is generic to any MIFed device.

For this reason, I didn't want to elaborate.  The goal is to include text that reminds the implementor that perhaps they should not follow a mindset that they will have only one B4 element on their system, in the case where they plan to have multiple external network interfaces, since we just finished explaining carefully that there should be only one domain name sent to configuration.  The danger is that they may configure only one tunnel endpoint, either having only one B4 element running, or multiple endpoints for each interface all using some single endpoint.  These would all be bad decisions, which may seem reinforced by the specification's demand for a single name.

--
David W. Hankins
SRE
Google, Inc.

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************