Subject: IPv6 Address Option

From: "MILES DAVID" <[email-masked]>
Date: Wed, 23 Sep 2009 18:47:34 +0800

Folk,

A few months back some of us expressed a desire to proceed with the
draft-lourdelet-radext-ipv6-access-01 and recommend its adoption as a WG
item. In the recent Broadband Forum meeting in Tokyo it was announced
that the BBF will seek to finalize their document on IPv6 for PPP
environments (to which I am co-editor). With the lack of some essential
RADIUS AVP (such as IPv6-Address-Option) we are stuck between a rock and
a hard place.

Delaying the IPv6 for PPP document much beyond November is not an option
for a large number of operators who wish to get some IPv6 deployment
going. With this goal in mind I ask the WG and chairs to adopt this
draft as a starting point with a goal of getting to WGLC within the
coming months (after Hiroshima IETF). If it needs to be simplified down
to the essential AVP I am happy to work with the current authors to
create a draft which can be fast tracked.

The alternatives are ugly IMO

Regards

-David Miles

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Sat, 26 Sep 2009 09:16:53 +0200

Is there a response to my review?

http://ops.ietf.org/lists/radiusext/2009/msg00401.html

  Addressing the minor issues brought up in the review would allow
server implementations to support the document by simply updating their
dictionaries.  As it stands now, new data types will have to be defined,
which can be a significant barrier to adoption.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 26 Sep 2009 16:53:34 +0700

> which can be a significant barrier to adoption.

In your review you say "Defining a tag field *and* a 32-bit integer means
that you're
re-defining the meaning of a tag + integer attribute.  See RFC 2868, Section
3.1 for the historical definition. It would seem to be OK to have a 24-bit
lifetime.  That would allow everyone to use this attribute by simply
updating their dictionaries, rather than writing new code to handle a new
format.". but draft-ietf-radext-design-08, section 2.1.2 says (talking about
the tagging mechanism defined in RFC 2868) "New attributes SHOULD NOT use
this tagging method...".  Which is it?  

...

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 26 Sep 2009 17:08:56 +0700

> this tagging method...".  Which is it?

Even more interestingly, your latest missive seems to strongly imply that
adopting the RADIUS Design (Mis-)Guidelines will be a "significant barrier
to adoption" of new attributes designed following them...

---

From: Alan DeKok <[email-masked]>
Date: Sat, 26 Sep 2009 12:40:17 +0200

Glen Zorn wrote:
> ... but draft-ietf-radext-design-08, section 2.1.2 says (talking about

  I suggest racing against the design guidelines document.  After all,
it's only a draft.  If the IPv6 document can get published first, then
the design guidelines matter a lot less.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 26 Sep 2009 12:51:16 +0200

> to adoption" of new attributes designed following them...

  Perhaps there's an IETF process to obtain WG consensus and update
published documents?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 26 Sep 2009 20:09:11 +0700

>   Perhaps there's an IETF process to obtain WG consensus and update

What do you mean?

---

From: Alan DeKok <[email-masked]>
Date: Sat, 26 Sep 2009 16:27:10 +0200

>>   Perhaps there's an IETF process to obtain WG consensus and update

  Later documents can update earlier documents.  If the design
guidelines is as catastrophic as you claim, later documents can update
it, and define new attributes that don't follow it's recommendations.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 26 Sep 2009 17:21:27 -0700

> item. 

On June 25, 2009 there was a WG call for interest in the document: 
http://ops.ietf.org/lists/radiusext/2009/msg00273.html

Only one person other than yourself and the authors replied to the call for interest. 

In addition, the document has not been revised in response to WG comments. 

> In the recent Broadband Forum meeting in Tokyo it was announced

If there was interest from the Broadband Forum, why has noone bothered to
respond to the call for interest or to revise the document? 

> Delaying the IPv6 for PPP document much beyond November is not an option

If that is the case, why are the concerned parties not doing more to move it forward? 

> I am happy to work with the current authors to create a draft which can be fast tracked.

If you're volunteering to act as editor, that would be great.  Next step would be to issue a 
version of the document addressing outstanding comments.  We can then discuss the 
document at the October 13 Virtual Interim meeting.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 27 Sep 2009 10:27:37 +0700

Alan DeKok [mailto:[email-masked]] writes:

>   I suggest racing against the design guidelines document.  

What a great idea!  Since the Mis-Guidelines draft is in IESG evaluation &
our draft has yet to be accepted as a WG item, it's a race we're sure to
win!  A more likely scenario: we change our draft to match your "review",
then the Mis-Guidelines draft is published as an ACP (Alan's Current
Practice) & presto, we get to change it again.  It would be a classic of
obstructionism, if only it weren't so obvious.

> After all, it's only a draft.  

Hmm.  That didn't seem to be relevant when you used it a club (its real
purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

...

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 27 Sep 2009 12:32:24 +0700

Alan DeKok [mailto:[email-masked]] writes:

> >>> Even more interestingly, your latest missive seems to strongly
> imply
> >> that
> guidelines is as catastrophic as you claim, 

Actually, _you_ made the claim, I just quoted it.

> later documents can update

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Sep 2009 08:39:58 +0200

> Actually, _you_ made the claim, I just quoted it.

  Nonsense.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Sep 2009 08:41:16 +0200

> purpose) to beat up draft-zorn-radius-pkmv1-06 last month.  

  Are my comments really that influential?

  I've come along in the world.

  Alan DeKok.

---

From: Behcet Sarikaya <[email-masked]>
Date: Sun, 27 Sep 2009 09:43:13 -0700 (PDT)

Hi Bernard,

>
>From: Bernard Aboba <[email-masked]>
>To: [email-masked]; "[email-masked]" <[email-masked]>; David B. Nelson <[email-masked]>
>Cc: [email-masked]; Mark Townsley <[email-masked]>
>Sent: Saturday, September 26, 2009 7:21:27 PM
>Subject: RE: IPv6 Address Option
>
> >

No. Several people replie. They just supported the call without any comments, but they promised to comment.

>document at the October 13 Virtual Interim meeting. 

Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

Regards,

Behcet

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Sep 2009 13:18:16 -0700

> No. Several people replied. They just supported the call without any comments, but they promised to comment.

In looking at the archive, these are the only people whose response indicated support of the document: 

Glen Zorn (author): http://ops.ietf.org/lists/radiusext/2009/msg00276.html
Miles David: http://ops.ietf.org/lists/radiusext/2009/msg00349.html
Yungui Wang: http://ops.ietf.org/lists/radiusext/2009/msg00354.html

Aside from these individuals, who else has indicated support for the document?  Please provide links to their emails. 

>Well, we certainly would be happy to have David on board. However, I think the document already has an editor, actually two, i.e. Benoit and Glen.We could have three :).

The issue isn't how many editors the document has.  The issue is the pace at which the document has evolved in response to feedback.  

The IETF isn't a "work for hire" organization that exists to produce work in response to liaison requests.  If an SDO such as Broadband Forum wants a document to move forward, then they need to supply the manpower to complete the work, and enough people interested in it to provide appropriate review.  Providing deadlines without engaged people doesn't help. 

And if some aspect of the IETF process is acting as a bottleneck, the Design Guidelines document specifically provides a mechanism for the Broadband Forum to complete the work on its own, engaging the IETF for review.

---

From: "MILES DAVID" <[email-masked]>
Date: Mon, 28 Sep 2009 11:30:40 +0800

Hi Bernard,

My email was simply an opportunity to prompt continued discussions from
Stockholm (things had been somewhat quiet).

To the question of tagged AVP,  your suggested rewording of
radext-design-07 :

For these reasons, the tagging scheme described in RFC 2868 is
   not suitable for use as a generic grouping mechanism.  Where
   a tagging scheme is required for use with arbitrary data types,
   it is RECOMMENDED that:
      
        * A fixed tagging field be used so as to remove potential
          interoperability issues associated with determining whether
          an optional tag is present; 

        * The design make no assumption about the content of the
          data within tagged attributes."  

to require new AVP which implement tagged values must treat them as a
fixed/mandatory is to me the best approach _if_ it is decided that these
AVP should not fall under the guidelines of radext-extended-attributes.
My opinion is that radext-design-07 should be updated to include the
proposed text above. After that modification I believe the current text
in ipv6-access-01 around tags:

The Tag field is mandatory.  The Tag
      field values are greater than 0x00.

 Is sufficient to allow the adoption of this draft.

I see no other outstanding issues in the minutes or on the RADEXT issues
list for draft-lourdelet-radext-ipv6-access. Should I post your proposed
text as an issue to the list for tracking?

Cheers,

-David

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Sep 2009 07:42:32 +0200

MILES DAVID wrote:
> list for draft-lourdelet-radext-ipv6-access.

  My review isn't listed as an issue, but it may be useful to address
the comments it makes.

  Alan DeKok.

---

From: "MILES DAVID" <[email-masked]>
Date: Mon, 28 Sep 2009 14:20:54 +0800

Sorry Alan,

I missed that one.

My comments on each point:

>Uplink-IPv6-Address instead of IPv6-Address
	I know the supporting text says "is assigned to the uplink of
the user equipment" but uplink may be confusing (the uplink of what) -
Peer/Subscriber/Host-IPv6-Address perhaps?

>IPv6-Route-Option-Preference
	Per your review - I too agree that a signed integer is somewhat
confusing however this is a direct copy of a DHCP option from RFC 4191:
Prf (Default Router Preference)
            2-bit signed integer.  Indicates whether to prefer this
            router over other default routers.  If the Router Lifetime
            is zero, the preference value MUST be set to (00) by the
            sender and MUST be ignored by the receiver.  If the Reserved
            (10) value is received, the receiver MUST treat the value as
            if it were (00).

  Preference values are encoded as a two-bit signed integer, as
   follows:

      01      High
      00      Medium (default)
      11      Low
      10      Reserved - MUST NOT be sent

> IPv6-Route-Option-Lifetime:
> Auth-IPv6-Prefix-Valid-Lifetime:
> 
>   Defining a tag field *and* a 32-bit integer means that you're
> re-defining the meaning of a tag + integer attribute.  See RFC 2868,
> Section 3.1 for the historical definition.
> 
>   It would seem to be OK to have a 24-bit lifetime.  That would allow
> everyone to use this attribute by simply updating their dictionaries,
> rather than writing new code to handle a new format.

Again these 32-bit values are straight out of RFC 4191 and there is a
requirement to support a value of infinity (0xffffffff). I think you
could get away with a 24-bit value and a special recognition of
infinity, but it is not desirable. If we adopt a fixed tag definition
per Bernard's suggestion, do we still have a problem?

> Prefix-Lifetime-Service-Type
Re suggestion to make this a 32-bit integer instead of a 16-bit (2B)
integer. IMO this is not a big change one way or another - I have no
objection to changing this.

Cheers,

-David

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Monday, 28 September 2009 3:13 PM
To: MILES DAVID
Cc: Bernard Aboba; [email-masked]; [email-masked]; David B.
Nelson; [email-masked]; Mark Townsley
Subject: Re: IPv6 Address Option

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Sep 2009 08:36:25 +0200

> Peer/Subscriber/Host-IPv6-Address perhaps?

  Just something more specific than "IPv6-Address".  There are a lot of
possible uses for IPv6 addresses.  Having an attribute named just
"IPv6-Address" will be confusing.

> confusing however this is a direct copy of a DHCP option from RFC 4191:

  OK.  Is this attribute intended to transport that DHCP option, or to
mirror the functionality?

  There are no signed integers in RADIUS, and 16 bit integers are not
recommended.  I would suggest instead that the RADIUS definition of the
attribute be "2 octets", and that the definition refers to the
appropriate section of RFC 4191.

  i.e. leave the practical use of the attribute unchanged.  But change
the definition to refer to another specification, rather than
duplicating the definition here.

...
> per Bernard's suggestion, do we still have a problem?

  It's still a new data type, but I think the alternatives would be worse.

> objection to changing this.

  OK.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 28 Sep 2009 14:20:00 +0700

> "IPv6-Address" will be confusing.

Or useful; maybe they're the same thing?

> > confusing however this is a direct copy of a DHCP option 

I think it's actually from a Router Advertisement message, but no matter.

> from RFC 4191:

Since the meaningful part of the Attribute is only 2 bits, I'd prefer a
single octet.

> duplicating the definition here.

That's a fine idea.

...

> > objection to changing this.

Again, a single octet should suffice, no?

...

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 28 Sep 2009 08:04:51 -0700 (PDT)

Hi Bernard,
  There is also this:

https://ops.ietf.org/lists/radiusext/2009/msg00371.html

Regards,

Behcet

>To: [email-masked]; [email-masked]; "[email-masked]" <[email-masked]>; David B. Nelson <[email-masked]>
>Sent: Sunday, September 27, 2009 3:18:16 PM

---

From: Alan DeKok <[email-masked]>
Date: Tue, 29 Sep 2009 15:56:00 +0200

Glen Zorn wrote:
>>...  Having an attribute named just

  Sure, if we presume that RADIUS only ever transports one IPv6-address
attribute.  Why not call it IPv6-Address?

> Since the meaningful part of the Attribute is only 2 bits, I'd prefer a

  Fine by me.

...
> Again, a single octet should suffice, no?

  Fine by me.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Sep 2009 07:28:08 -0700

Mark Townsley wrote:

"Is this a wan interface IPv6 address, or a lan-side delegated prefix?
And, might we want both? Even a third that might be the management IPv6
address assigned to a loopback?

If the scope is far less here, that's fine with me, but in principle I
can imagine a BNG wanting to serve up (via DHCPv6 or PPP) or be aware
of (for running BFD or whatever kind of thing the BNG might want to do
with an RG) more than just one IPv6 address."

I think this is one of the issues that has confused members of the WG who have attempted to review the document. Overall, the  usage model underlying the document is unclear and this could potentially result in interoperability problems. 

For example, are we talking about prefix delegation, then presumably we are looking to utilize the attributes defined in RFC 4818. 

If we are not talking about prefix delegation, then are we utilizing the address assignment model of PPP IPv6CP or DHCPv6?  If it is IPv6CP, then it would not seem to make sense for the IPv6-Address in question to be that of the client interface, since that is already determined by the attributes defined in RFC 3162 (Framed-IPv6-Prefix and Framed-Interface-Id).  

If we are utilizing the address assignment model of DHCPv6, then is the NAS acting as a DHCPv6 server?  Since RADIUS is spoken between a NAS and a RADIUS server, if the DHCPv6 server does not reside on the NAS, then this raises questions about what entities are involved in the RADIUS protocol conversation, and whether authentication (or a Call Check) is taking place. 

Outlining the specific scenarios that under consideration and the requirements for a solution would help greatly in promoting progress on this document.