Subject: [Softwires] draft-ietf-softwire-ds-lite-tunnel-option-06

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Nov 2010 10:22:37 -0800

I was unable to edit the tunnel option draft prior to the cut-off date.

In the meantime please find what will be -06 of the draft here, for
discussion during the upcoming meeting;

  http://www.mercenary.net/~dhankins/drafts/draft-ietf-softwire-ds-lite-tunnel-option-06.txt

-- 
David W. Hankins	"If you don't do it right the first time,
Network Mercenary		you'll just have to do it again."
						-- Jack T. Hankins

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2010 16:48:05 -0800

Please change this:

   The AFTR-Name option consists of option-code and option-len fields
   (as all DHCPv6 options have), and a variable length tunnel-endpoint-
   name field, containing a partially qualified host name or fully
   qualified domain name that refers to the AFTR the client is asked to
   connect to.

To this:

   The AFTR-Name option contains a single fully-qualified domain name,
   the tunnel-endpoint name field.   This name may be fully- or partially-
   qualified, and specifies the AFTR to which the client is is expected to
   connect.

My reason for asking for this change is that the text as it appears in the document says more than is necessary (presumably any DHCP client or server implementation already knows how to construct or unpack a DHCP option), and the extra text obscures the essence of the specification.

Please change this:

   The OPTION_AFTR_NAME option MAY appear in the root scope of a DHCPv6
   packet.  It MUST NOT appear inside any IA_NA, IA_TA, IA_PD, IAADDR,
   or similar.  Any OPTION_AFTR_NAME option received inside any other
   option MUST be ignored.

   The OPTION_AFTR_NAME option MUST NOT appear more than once in a
   message.  Clients that receive more than one OPTION_AFTR_NAME options
   MUST discard all instances of that option, acting as if none were
   sent.

To this:

   The OPTION_AFTR_NAME option is only valid in the root scope of a DHCPv6
   packet.  Any OPTION_AFTR_NAME option received inside any other
   option SHOULD be ignored.

   DHCP servers SHOULD send a maximum of one OPTION_AFTR_NAME option.  Client
   behavior in the event that a server returns more than one such option is
   undefined.

My reason for requesting this change is that DHCP option specifications should not place new and arbitrary requirements on DHCP servers and clients to enforce particular behaviors.   It is an administrative error to configure more than one AFTR option, or to configure it in such a way that it is not returned in the root scope.   It is sufficient to say that this won't work--it is not necessary to place onerous new requirements on DHCP clients and servers.

Please delete the following text from section 4, for the same reason:

   A DHCPv6 server MUST NOT send more than one OPTION_AFTR_NAME option.

   A DHCPv6 server MUST NOT send the OPTION_AFTR_NAME option as a
   suboption in other options; it MUST appear only in the root scope of
   any DHCPv6 messages made in response to clients (Reply, Advertise, et
   al).

   A client that supports the B4 functionality of DS-Lite (defined in
   [I-D.softwire-ds-lite]) and conforms to this specification MUST
   include OPTION_AFTR_NAME on its OPTION_ORO.

What if the client doesn't send an ORO?

   Because it requires DNS name to address resolution, and the use of
   the domain-search path, a client MAY also wish to include the
   OPTION_DNS_SERVERS and OPTION_DOMAIN_LIST options on its OPTION_ORO.

You might want to phrase this differently:

   DHCP clients requesting this option SHOULD also request the OPTION_DNS_SERVERS
   and OPTION_DOMAIN_LIST options, since these will be required to resolve the
   provided FQDN.

Please delete this text, since it inappropriately specifies new behavior for DHCP clients:

   If the client receives the OPTION_AFTR_NAME option, it MUST verify
   the option contents as described in Section 3.

   If the client receives more than one OPTION_AFTR_NAME option, it MUST
   discard all instances of that option.

Here, wouldn't it be easier just to say that if there is no '.' label (the zero-length label) at the end of the name, you have to use the domain search list?

   If the tunnel-endpoint-name field has less than or equal to 2 labels
   (not including the terminating zero-length label), the client (B4)
   iterates through any configured domain-search [RFC3646] path.

Thanks for publishing the new draft--sorry for all these additional edits at this late date.

---

From: Alain Durand <[email-masked]>
Date: Tue, 9 Nov 2010 17:50:04 -0800

On Nov 9, 2010, at 7:48 PM, Ted Lemon wrote:

Why can't we just say: "pass this to the local DNS resolver" and be done? Why should the process of going through the search list be specified in this draft?

   - Alain.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2010 18:15:05 -0800

> Why can't we just say: "pass this to the local DNS resolver" and be done? Why should the process of going through the search list be specified in this draft?

This is a good point.   I think there's a tension here between being overly prescriptive and not saying anything at all, though.   Is there an RFC that describes resolver in such a way that it could be referenced here?   It's all in RFC1034, but not in such a way that you could make a meaningful and concise reference to it.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 06:07:53 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ted Lemon
> Sent: Wednesday, November 10, 2010 10:15 AM
> To: Alain Durand
> Cc: [email-masked]
> Subject: Re: [Softwires] draft-ietf-softwire-ds-lite-tunnel-option-06
> 
> > Why can't we just say: "pass this to the local DNS resolver" and be done? Why
> should the process of going through the search list be specified in this draft?
> 
> This is a good point.   I think there's a tension here between being overly
> prescriptive and not saying anything at all, though.   Is there an RFC that
> describes resolver in such a way that it could be referenced here?   It's all in
> RFC1034, but not in such a way that you could make a meaningful and concise
> reference to it.

I do not thing it should say "pass this to the local DNS resolver" but rather
"pass this to the local name resolution library".   Whether it gets resolved with
DNS or hosts file or whatever else isn't important from the perspective of
this option, and in practice I think people will just call getaddrinfo() on the
value, rather than some DNS-specific API.

-Dave

---

From: Ralph Droms <[email-masked]>
Date: Wed, 10 Nov 2010 14:14:19 +0800

And is there a description of the "local name resolution library" (quoting Dave) that meets the requirements of the softwires usage expectation?  That is, does the softwires WG expect "the usual" behavior by just handing the contents of the option to the local name resolution library, or by formulating several different FQDNs according to some specific rules, or ???

- Ralph

On Nov 10, 2010, at 10:15 AM 11/10/10, Ted Lemon wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Alain Durand <[email-masked]>
Date: Tue, 9 Nov 2010 22:21:17 -0800

> And is there a description of the "local name resolution library" (quoting Dave) that meets the requirements of the softwires usage expectation?  That is, does the softwires WG expect "the usual" b…

There is no special requirement here beside just resolve the FQDN...
This is, I'm sure, not the first DHCP option like this, why should we say anything special here?

  - Alain.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 06:26:05 +0000

> Behalf Of Ralph Droms
> Sent: Wednesday, November 10, 2010 2:14 PM
> To: Ted Lemon
> Cc: [email-masked]
> And is there a description of the "local name resolution library" (quoting Dave)
> that meets the requirements of the softwires usage expectation?  That is, does
> the softwires WG expect "the usual" behavior by just handing the contents of
> the option to the local name resolution library, or by formulating several
> different FQDNs according to some specific rules, or ???

The usual behavior.  Just take the string in the option, and pass it to the
standard APIs (or their equivalents).  There's nothing different here than
(say) what a browser does with the hostname portion of a URI.

If you want something to reference, maybe RFC 3493 section 6.1.
Other relevant references would be RFC 1123 section 6.1.1, and
end of section 1 of draft-iab-idn-encoding-04 (waiting for RFC # to
be assigned by the RFC editor).

There might be a better reference but at least those are some.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 06:27:59 +0000

> Behalf Of Alain Durand
> Sent: Wednesday, November 10, 2010 2:21 PM
> To: Ralph Droms
> Cc: [email-masked]

Good point.  We don't need to say much of anything here.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Nov 2010 22:32:21 -0800

> This is, I'm sure, not the first DHCP option like this, why should we say anything special here?

Ordinarily we only support fully-qualified domain names, so the search list issue doesn't come up.   This is the only DHCP option I know of that allows a partial domain name.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 00:13:25 -0800

On Nov 10, 2010, at 2:33 PM, Alain Durand wrote:
> I have not heard any requirement to have anything else in that option.

The document itself specifies the use of the search list, so that's the reason for the discussion.   If there's no requirement for unqualified or partially-qualified domain names, I think it would be better to take it out of the draft.   It adds a lot of complexity, a lot of room for error, and no obvious value, since if the DHCP server is providing the search list, presumably it could be configured to simply provide a fully-qualified domain name.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 08:45:11 +0000

> Sent: Wednesday, November 10, 2010 4:13 PM
> To: Alain Durand
> Cc: [email-masked]
> The document itself specifies the use of the search list, so that's the reason for
> the discussion.   If there's no requirement for unqualified or partially-qualified
> domain names, I think it would be better to take it out of the draft.   It adds a lot
> of complexity, a lot of room for error, and no obvious value, since if the DHCP
> server is providing the search list, presumably it could be configured to simply
> provide a fully-qualified domain name.

Personally I'd prefer saying less, rather than more.
That is, it's a string that is to be passed to the name resolver library.
I wouldn't mention the search path, since that's not done by the DHCP client,
it's done (or not) by the name resolver library.

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 04:36:38 -0800

> it's done (or not) by the name resolver library.

Fair enough, but just to be clear, the format that's being used by this option is a format for passing FQDNs, not a format for passing labels.   So the resolver is not supposed to use a search list at all when interpreting options in this format.   That is what the zero-length label at the end is supposed to mean.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 10 Nov 2010 13:36:32 +0000

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2010 8:37 PM
> To: Dave Thaler
> Cc: Alain Durand; [email-masked]
> > I wouldn't mention the search path, since that's not done by the DHCP
> > client, it's done (or not) by the name resolver library.
> 
> Fair enough, but just to be clear, the format that's being used by this option is a
> format for passing FQDNs, not a format for passing labels.   So the resolver is
> not supposed to use a search list at all when interpreting options in this format.
> That is what the zero-length label at the end is supposed to mean.

It is my understanding that if the string passed to a name resolver library
contains dots, no search list should be used.  (Reference: RFC 1535)

The Windows name resolver library does strictly adhere to this
(it never uses a search list with a string containing dots).

-Dave

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 15:29:19 -0800

> (it never uses a search list with a string containing dots).

Ah, good to know.  In this case, if the behavior described in the current draft is desired, it does need to be specified, since it differs from the behavior specified in RFC 1535. However, I think the behavior described in the draft is unnecessary, so maybe it's better to just get rid of it.

---

From: Alain Durand <[email-masked]>
Date: Wed, 10 Nov 2010 16:08:42 -0800

> Ah, good to know.  In this case, if the behavior described in the current draft is desired, it does need to be specified, since it differs from the behavior specified in RFC 1535. However, I think…

Fully agreed. Let's keep this thing simple, just as any other FQDN option ever defined for DHCP.

Chair hat on:  authors, please update the draft to remove any text that will make this option differ from regular FQDN treatment and publish on the normal ID stream.

   - Alain.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 11 Nov 2010 17:10:35 -0800

> This is, I'm sure, not the first DHCP option like this, why should we say anything special here?

As far as I am aware, the prescribed behavior by the two operators who
required the DNS-name format, that it be processed with the domain
search path, is in fact the first DHCPv6 option of its kind using this
format.

All other DHCPv6 options reference RFC 3315 section 8, which backreferences
to RFC 1035, which clearly stipulates that the zero label at the end of a
domain name string of labels indicates the location of the root label:

   "Since every domain name ends with the null label of
    the root, a domain name is terminated by a length byte of zero."

This is, in fact, new work.  And it will not work with e.g. ISC DHCP
software (which will explicitly refer to the root label in wire->config
format exchanges: "aftr.example.com.") without hacks (intentionally
stripping the trailing dot in the AFTR software) or modifications
(changing ISC dhclient source code to do the same).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 17:17:03 -0800

> (changing ISC dhclient source code to do the same).

Do I take this to mean that you are not in favor of the use of the search path with this option?

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 11 Nov 2010 17:33:11 -0800

> contains dots, no search list should be used.  (Reference: RFC 1535)

And then there is the unix world of stub resolvers, where the search
string is used after an initial attempt on any query with one or more dots
("ndots:1" is the default configuration).

And yet it is unlikely that someone is going to name their AFTR endpoint
'example.com'.

Consequences;

1) The root receives queries for (and formulates NXDOMAIN responses)
   'aftr.site'.  The client then moves on to try its search path.  Despite
   negative cache entries in recursive resolvers, this is littering.

2) Windows (no search behavior on any dots) and Unix (behavior I
   described) becomes incompatible.  The two types of client, given
   the same aftr-name option contents will process these contents in
   different ways, either requiring specialized configuration, or
   defining a standard behavior by fiat or muscle.

So I believe a standard description of the process that both can implement
equally (with the same consequent behaviors) and does not trouble the root
nameservers needlessly is in order.

I think what is essentially a "ndots:2" configuration setting, which I
have verbosely described, is the correct method.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 11 Nov 2010 17:40:40 -0800

> search path with this option?

That's one workaround.  I am neither for nor against it.  The search
path behavior was required in the WG discussions that were causative
in the -06 revision of the draft.  I am simply reflecting that
discussion and consensus.

---

From: Alain Durand <[email-masked]>
Date: Mon, 15 Nov 2010 06:11:15 -0800

> discussion and consensus.

David:

I've not heard a very strong case for that search path and I certainly do not believe this is the consensus of the working group.

I understand that the exact behavior of a DHCP client receiving a FQDN option is not necessarily covered adequately in DHC documents,
but I do not think this is the time now to embark in such an endeavor.

At the moment, I believe that this should be left at the discretion of implementors.

  - Alain.

---

From: Dave Thaler <[email-masked]>
Date: Mon, 15 Nov 2010 21:16:18 +0000

> Behalf Of David W. Hankins
> Sent: Thursday, November 11, 2010 5:33 PM
> To: [email-masked]
> > It is my understanding that if the string passed to a name resolver
> > library contains dots, no search list should be used.  (Reference: RFC
> > 1535)
> 
> And then there is the unix world of stub resolvers, where the search string is
> used after an initial attempt on any query with one or more dots ("ndots:1" is
> the default configuration).
> 

Do the following two strings have the same behavior on Windows and Unix:
1) "example"  (search path applied)
2) "example.com." (no search path applied, note trailing dot)
?

If so, then compatibility is straightforward to configure.

-Dave

> I think what is essentially a "ndots:2" configuration setting, which I have
> verbosely described, is the correct method.
> 
> --

---

From: Ted Lemon <[email-masked]>
Date: Mon, 15 Nov 2010 17:21:30 -0800

> but I do not think this is the time now to embark in such an endeavor.

This isn't correct.  The situation is that the behavior of the client with respect to FQDN options is clearly specified, but is different than what is specified in the current version of the ds-lite draft. So if we are *okay* with the default behavior, it would be preferable to use it instead of specifying this new, different behavior.

---

From: Alain Durand <[email-masked]>
Date: Tue, 16 Nov 2010 08:52:40 -0800

On Nov 15, 2010, at 8:21 PM, Ted Lemon wrote:

On Nov 15, 2010, at 9:13 AM, "Alain Durand" <[email-masked]<mailto:[email-masked]>> wrote:

I think we are on agreement on this one.

  - Alain.

---

From: Alain Durand <[email-masked]>
Date: Tue, 16 Nov 2010 09:57:06 -0800

David:

I went back to the email Mohamed Boucadair sent to the list to explain the requirements.
See attached for full reference. The key point is:

Begin forwarded message:

>   In addition to the technical reasons mentioned in previous e-mails, I
>   would like to raise that operational issues should be also taken
>   into account for the provisioning of the DS-Lite AFTR reachability
>   information.  In particular, we are considering two levels of
>   redirection:
> 
>   o  The first level is national-wise is undertaken by the DHCP: a
>      regional-specific FQDN will be returned;
> 
>   o  The second level is done during the resolution of the regional-
>      specific FQDN to redirect the customer to a regional CGN among a
>      pool deployed regionally.

That is, what the DHCP server returns is a region specific FQDN, not an unqualified domain name.

As such, I see no reason to include the search path text in the draft.

  - Alain.

Subject: RE: [Softwires] DHCP option for DS-lite
From: "[email-masked]" <[email-masked]>
To: Alain Durand <[email-masked]>, Softwires list <[email-masked]>
Date: Mon, 18 Oct 2010 08:06:58 -0700

   Dear Alain, all,

   In addition to the technical reasons mentioned in previous e-mails, I
   would like to raise that operational issues should be also taken
   into account for the provisioning of the DS-Lite AFTR reachability
   information.  In particular, we are considering two levels of
   redirection:

   o  The first level is national-wise is undertaken by the DHCP: a
      regional-specific FQDN will be returned;

   o  The second level is done during the resolution of the regional-
      specific FQDN to redirect the customer to a regional CGN among a
      pool deployed regionally.

   Distinct operational teams are responsible for each of the above
   mentioned levels.  A clear separation between the functional
   perimeter of each team is a sensitive task for the maintenance of the
   services we are running.  In particular, regional teams will require
   to introduce new resources (e.g., new CGN devices) to meet an
   increase of customer base.  The introduction of these new devices
   (addressing, redirection, etc.) is implemented locally.  Having this
   regional separation provides flexibility to manage portions of
   network operated by dedicated teams.

   In order to be able to meet this operational constraint, the AFTR
   option name is part of our requirements.

   Cheers,

   Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Alain Durand
Envoyé : jeudi 14 octobre 2010 18:59
À : Softwires list
Cc : Ralph Droms
Objet : Re: [Softwires] DHCP option for DS-lite

I went back to the other thread on this topic  "DHCPv6 AFTR name option is needed".
The only technical argument brought forward is that some ISPs would like to use a level of indirection via DNS
to achieve load balancing (where the DNS has some form of measurement of the current load of the system).
They point at VoIP for a precedent in that space.

I would like to offer several remarks:

1) In the current DS-Lite model, the B4 element would only find out the tunnel end-point at config (boot) time.
     There is no provision in the spec to regularly refresh this information. This means that whatever is configured
     is going to stay that way for possibly a very long time.
2)  It is unclear that the load information that the DNS was using at the time
     of the AAAA resolution is a good indicator of what the load will be hours or days later.
3) Thus, it is unclear that such a system provide any better load distribution that a simple round-robin
     that can trivially be implemented in a DHCP server
4) If one follows that logic, the DNS redirection just add a round trip time for no benefits.
5) The analogy with VoIP does not hold here because the VoIP client can do the AAAA query
     just before placing a call. The load information coming from the DNS has a better chance of being accurate for the next few minutes.

I would like to invite the proponents of the DNS indirection to provide technical arguments as why the above remarks are incorrect.

   - Alain.

On Oct 12, 2010, at 12:00 PM, Alain Durand wrote:

> Dear wg:
> 
> draft-ietf-softwire-ds-lite-tunnel-option<mailto:[email-masked]> has been reviewed by the IESG with input from the dhc wg. Their conclusion was that having both an IP option and an FQDN option
> to describe the tunnel-end-point was redundant. After many discussion between the IESG and the authors, the authors decided to remove the FQDN option, leaving only
> the IP address option in place.
> 
> The rationale is that the B4 element should remain as simple as possible and presenting multiple tunnel-end point alternative would seriously complicate
> the implementation on the client side. For example, the client would have to keep track which end-point is currently the best alternative and we would have to develop
> a complex mechanism to do that. Load balancing is better achieve by the DHCP server sending the proper tunnel end-point to the B4 element. There are cases where
> more complex B4 elements could benefits from having multiple tunnel endpoint to choose from, but those are not expected to be the common case and they should
> be dealt with differently.
> 
> Our AD, Ralph Droms, asked us to verify there is consensus in the wg to do this.
> 
>> David, Alain - The authors made a significant change to draft-ietf-softwire-ds-lite-tunnel-option, deleting the FQDN option based on IESG review and input from the dhc WG.  The -05 rev is getting de facto > review now, but you'll need to determine WG consensus for the changes in the -05 rev.
>> 
>> - Ralph
> 
> If you have a strong opinion that the decision of the authors is the wrong one, please speak up now. This window for comments will end in 7 days, on 10/19.
> 
>   - Alain.

*********************************
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.
********************************

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Nov 2010 15:14:47 -0500

> I think we are on agreement on this one.

Yes, I think so too.   I just wanted to clarify that one side issue.