Subject: 6MAN WG Last Call: <draft-ietf-6man-lineid-02.txt>

From: Bob Hinden <[email-masked]>
Date: Thu, 3 Nov 2011 08:32:56 -0700

All,

This message starts a two week 6MAN Working Group Last Call on advancing:

	Title           : The Line Identification Destination Option
	Author(s)       : Suresh Krishnan
                          Alan Kavanagh
                          Balazs Varga
                          Sven Ooghe
                          Erik Nordmark
	Filename        : draft-ietf-6man-lineid-02.txt
	Pages           : 14
	Date            : 2011-10-31
	
        http://tools.ietf.org/html/draft-ietf-6man-lineid-02.txt

as an Experimental RFC.  Substantive comments and statements of support for advancing this document should be directed to the mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 17 November 2011.

Regards,
Bob Hinden & Brian Haberman
6MAN Chairs

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Nov 2011 12:10:22 -0400

Support.

I have read this document.  It provides a useful function in practical 
fashion.  It is ready for publication.

Yours,
Joel M. Halpern

On 11/3/2011 11:32 AM, Bob Hinden wrote:
> Bob Hinden&  Brian Haberman
> 6MAN Chairs
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: David Allan I <[email-masked]>
Date: Thu, 3 Nov 2011 12:21:56 -0400

Support!

This document addresses an important issue in introducing IPv6 dual stack into broadband access networks. N:1 VLAN as per TR-101 is a common deployment model...

Dave

---

From: Glen Turner <[email-masked]>
Date: Fri, 04 Nov 2011 08:48:49 +1030

The contents of the Line Identification Destination Option are
essentially opaque.

Although this may allow a wide range of router implementations, in
practice it leads to a situation where new implementers must
reverse-engineer the dominant implementation in order to be assured of
compatibility.

An opaque field allows a wide range of router implementation practice at
the cost of ease of use of the field in provisioning databases. An
implementation of a provisioning database which can configure a range of
routers has to ask for the Identification Destination in hexadecimal.

If the contents of the field are in practice a MAC address there may be
a repetition of the experience with the RADIUS's Calling-Station-Id
where a lack of definition of the content of the field leads to programs
with two or so pages of parsing code to extract a wireless device's MAC
address.

If the contents of the field are in practice an interface name then
perhaps ifIndex would be more suitable.

If the contents of the field are in practice a customer provisioning
identifier then perhaps the field could be specified as a string so that
programmers know that the field can be typed or printed rather than
hexdumped. Some care should be taken to identify the character set, as
it is unlikely to be UTF-8.

If the authors decide that opaque is desirable then they should define
the textual representation of the field. That way the contents of the
field are defined identically across different manufacturers' router
configuration languages, ISP provisioning databases, etc.

Best wishes, Glen

---

From: Suresh Krishnan <[email-masked]>
Date: Sat, 5 Nov 2011 09:36:13 -0400

Hi Glen,

Thanks for the comments. Please find responses inline.

> The contents of the Line Identification Destination Option are

Yes. They are.

> it is unlikely to be UTF-8.

This is the case in the deployments that we know about. The line-id is 
essentially a string that is matched with the provisioning databases 
(AAA) to determine a prefix to send out.

> configuration languages, ISP provisioning databases, etc.

Will do. Would a simple statement e.g. that it is a null terminated text 
string be sufficient or did you want more details?

Thanks
Suresh

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 05 Nov 2011 14:31:57 -0700

> string be sufficient or did you want more details?

Or should we refer to the corresponding DHCPv4 relay option? I think the 
simple case is when operators reuse the syntax they use for line 
identification with DHCPv4. But I haven't look at exactly how that DHCP 
option is specified.

    Erik

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 6 Nov 2011 20:24:39 -0500

Hi Erik,
 
> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Saturday, November 05, 2011 5:32 PM
> To: Suresh Krishnan
> Cc: Glen Turner; 6man Mailing List; Brian Haberman; Bob Hinden
> Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-lineid-02.txt>
> 
> >> If the authors decide that opaque is desirable then they should 
> >> define the textual representation of the field. That way 
> the contents 
> >> of the field are defined identically across different 
> manufacturers' 
> >> router configuration languages, ISP provisioning databases, etc.
> >
> > Will do. Would a simple statement e.g. that it is a null terminated 
> > text string be sufficient or did you want more details?
> 
> Or should we refer to the corresponding DHCPv4 relay option? 
> I think the simple case is when operators reuse the syntax 
> they use for line identification with DHCPv4. But I haven't 
> look at exactly how that DHCP option is specified.

The corresponding DHCPv4 relay option (defined in RFC3046) and the
corresponding DHCPv6 relay option (defined in RFC4649) are both 
defined as opaque with no character set information. That is what
makes definition more difficult.

Thanks
Suresh

---

From: <[email-masked]>
Date: Tue, 8 Nov 2011 10:04:51 +0100

I support this I-D becoming an RFC. It's describing a solution that is needed to deploy IPv6 in certain Broadband Access scenarios.

Regards
        Olaf

> > as an Experimental RFC.  Substantive comments and
> statements of support for advancing this document should be
> directed to the mailing list.  Editorial suggestions can be
> sent to the authors.  This last call will end on 17 November 2011.
> >
> > Regards,

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Nov 2011 09:27:19 -0800

[This time it should make it to the list]

-------- Original Message --------
Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-lineid-02.txt>
Date: Tue, 08 Nov 2011 08:50:42 -0800
From: Erik Nordmark <[email-masked]>
To: Suresh Krishnan <[email-masked]>
CC: Erik Nordmark <[email-masked]>, Glen Turner <[email-masked]>, 
   6man Mailing List <[email-masked]>,        Brian Haberman 
<[email-masked]>,        Bob Hinden <[email-masked]>

> makes definition more difficult.

I guess I don't understand why we would want to constrain it any more
than the DHCP relay options.
It would be helpful to put a sentence in section 7 providing the
motivation for it being just an opaque byte string. Something like
	The Line Identification is an opaque sequence of "Option Length"
	number of bytes (with no NULL termination etc). That matches
	the lack of constraints on the corresponding DHCPv4 and DHCPv6
	relay options.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 08 Nov 2011 08:50:42 -0800

Erik

---

From: Glen Turner <[email-masked]>
Date: Fri, 11 Nov 2011 16:01:24 +1030

Hi Suresh,

> Will do. Would a simple statement e.g. that it is a null terminated text string be sufficient or did you want more details?

There's no need for it to be NUL-terminated. In fact that's asking for trouble because what do you do if the NUL and the field length don't match?

What application programmers need to know is:
- that the field can be printed
- what character set to use for the printing and input
- what to do if a non-compliant string is encountered (eg, non-printable chatacters, or a failed UTF-8 encoding). A reasonable action would be to never attempt to print the field, fail any comparisons, and generate a small number of log messages containing enough information for debugging but without allowing an attack vector on the logging device (ie, don't print the errorred string, hex dump it or escape non-printing characters).
- how to compare the field. Byte-by-byte makes sense; that is, the locale is irrelevant.

As you can see, there's a fair few issues avoided by that convenient word "opaque". It's a fine word to describe bytes on the wire: it says that middleboxes shouldn't tamper with the field. But it's a poor word for use at endpoints, as it amounts to underspecification of the field and thus divergent practices or reverse engineering.

For example, one compliant router could use a twos-complement counter, another could use ASCII, another could use a random nonce. Without further specification of the "opaque" field all that a compliant provisioning system can do is require the field to be input as hex. Ironically, only a non-compliant provisioning system could accept input as a string, which is the intended use of the field.

The contents of the DHCP Relay Agent Information Option fields in RFC3046 are said to be opaque but then it is immediately suggested that the contents are textual. For example,  "The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only". To my mind RFC3046 isn't a good specification because all it does is raise ambiguity in the implementer's mind and send them off to look at other implementations for guidance.

This is much more writing than the issue is worth. My apologies for taking up your time.

Best wishes, Glen

-- 
 Glen Turner <http://www.gdt.id.au/~gdt/>

---

From: Glen Turner <[email-masked]>
Date: Fri, 11 Nov 2011 16:01:24 +1030

Hi Suresh,

Best wishes, Glen