Subject: Re: [dhcwg] Re: [Int-area] DCHP-based authentication for DSL?

From: Richard Pruss <[email-masked]>
Date: Thu, 01 Nov 2007 17:04:04 -0700

Ted Lemon wrote, around 1/11/07 11:19 AM:
> On Nov 1, 2007, at 11:01 AM, Richard Pruss wrote:
>> The message you quote seems to be a what about the clients that do not 
>> support a new authentication method.  The answer is they work as 
>> always with PPPoE.
> 
> Richard, this really doesn't address Iljitsch's objection.   Existing 
> DHCP clients DO NOT support this authentication method.   From 20k feet 
> it may look like it's supported because the box was already doing it 
> with PPPoE, but down on the bare metal of the client's box, no such 
> functionality exists.   Replacing existing DHCP clients is a Very Hard 
> Problem.   You need to explain how you're going to solve this problem, 
> or else the rest of this discussion is academic.
> 

The selective quote you choose of mine seemed to leave out the answer to 
the question you asked:

I said:
"The new services are supported by new equipment and the expectation is 
that the customer can take the new gear, put in his old credentials and 
come up on the new services."

That means that they have new gear with new stacks, so we simply do not 
have the replace existing DHCP clients problem.  Typically existing 
clients use PPPoE and so their is no problem for them either.

Did thank clear it up?

Thanks for highlighting that I missed this one,
Ric

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Nov 2007 17:04:58 -0700

On Nov 1, 2007, at 5:04 PM, Richard Pruss wrote:
> "The new services are supported by new equipment and the  
> expectation is that the customer can take the new gear, put in his  
> old credentials and come up on the new services."
>
> That means that they have new gear with new stacks, so we simply do  
> not have the replace existing DHCP clients problem.  Typically  
> existing clients use PPPoE and so their is no problem for them either.
>
> Did thank clear it up?

So it sounds like what you're proposing is that people who use this  
new service will have to connect to the network through a network  
address translator box, which will do DHCP to the center with the  
authentication information you've described, and the actual equipment  
that they own will only do DHCP to the NAT box, and thus won't need  
to be modified?

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 2 Nov 2007 01:11:04 -0400

> From: Ted Lemon, November 01, 2007 8:05 PM
> expectation 
> > is that the customer can take the new gear, put in his old 
> credentials 
> > and come up on the new services."
> >
> So it sounds like what you're proposing is that people who 
> use this new service will have to connect to the network 
> through a network address translator box, which will do DHCP 
> to the center with the authentication information you've 
> described, and the actual equipment that they own will only 
> do DHCP to the NAT box, and thus won't need to be modified?

Yes.  The Home Gateway model you describe above is certainly a dominant
(if not the dominant) model for homes with multiple PCs.  

(Note: this does not preclude the service provider from concurrently
supporting existing DHCP/PPPoE Home Gateways, or even multiple bridged
PCs that are bridged onto a DSL line.  However clients not going through
an "auth" phase will likely be associated with different network
resources (such as VRFs) at the BRAS.)

Eric

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Nov 2007 22:16:39 -0700

> (if not the dominant) model for homes with multiple PCs.

Well, but let's be clear here.   This is not "a model" that "is  
dominant" in the scenario you are proposing.   It is the /only/ model  
that will work in the scenario these two drafts aim to support.

Right?

---

From: Richard Pruss <[email-masked]>
Date: Mon, 05 Nov 2007 09:41:14 +1000

> that will work in the scenario these two drafts aim to support.

No, that would fall very seriously short of the goals set by the 
DSLForum.  There are many more elements involved in the scenarios and 
allot more variations on the them.  When you look over the documents I 
will quote below watch our for the technology choices for service 
separation, and quality as the number of options is the main driver on 
the number of real world scenario's you see.  This of course also drives 
what information contributes or can contribute to authentication and 
most importantly what is enforced where.

You are digging in the correct direction by trying to understand the use 
cases in more depth.  The reason why four vendors in DSL broadband and a 
number of SP's in the space are recommending this approach does spring 
from an understanding the deployments and trying to reuse as much of the 
existing deployments and architecture as possible.

The current recommended DSL Forum architecture is in TR-101:
http://www.dslforum.org/techwork/tr/TR-101.pdf

The current draft of next generation WT-148 is:
http://www.arkko.com/ietf/intarea/dsl2006.887.03.doc

The living list of requirements for authentication for WT-146 is:
https://datatracker.ietf.org/documents/LIAISON/file457.doc

- Ric

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Nov 2007 11:19:17 -0700

On Nov 1, 2007, at 11:01 AM, Richard Pruss wrote:
> The message you quote seems to be a what about the clients that do  
> not support a new authentication method.  The answer is they work  
> as always with PPPoE.

Richard, this really doesn't address Iljitsch's objection.   Existing  
DHCP clients DO NOT support this authentication method.   From 20k  
feet it may look like it's supported because the box was already  
doing it with PPPoE, but down on the bare metal of the client's box,  
no such functionality exists.   Replacing existing DHCP clients is a  
Very Hard Problem.   You need to explain how you're going to solve  
this problem, or else the rest of this discussion is academic.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Nov 2007 10:24:43 -0700

On Oct 29, 2007, at 12:16 AM, Stig Venaas wrote:

[...]

At Ralph's request, I've gone back and read the archives for this  
discussion.   Much learned and useful argument has been presented,  
including Stig's most recent objection, which is certainly a good  
valid technical objection.

However, what I have *not* noticed, which I find kind of stunning, is  
anybody from the "let's do it" side of the argument answering  
Iljitsch's very cogent and telling objection here:

http://www1.ietf.org/mail-archive/web/int-area/current/msg01014.html

This objection is a showstopper.   If it can't be answered, there is  
no chance that this protocol can ever be deployed.   All the  
technical and procedural objections that have been discussed here are  
irrelevant if this one objection can't be answered.

So I think that before any further discussion on the merits of the  
wire protocol go forward, perhaps it would behoove this learned body  
to actually address Iljitsch's objection.   I must confess that I  
have not read every message in the archive, because there are a  
remarkable lot of them, so if someone can point me at the place where  
Iljitsch's objection was shown to be unnecessary, I would consider it  
a great favor.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Nov 2007 00:52:53 +0100

Ted Lemon wrote:
> anybody from the "let's do it" side of the argument answering Iljitsch's
> very cogent and telling objection here:
> 

  (quoting)

>> So how would a DHCP solution work when the user connects:
>>
>> - a Windows XP or MacOS X machine but Microsoft/Apple won't be
>>   including the new DHCP option for another 12 months
>> - a Windows 98 machine that is no longer getting updates from
>>   Microsoft
>> - a no brand home gateway which can't be upgraded by the user

  Those comments are objections to *change*.  They are not specific
objections to this proposal.  They apply equally well to DCHP + EAP,
DHCP + CHAP, new DHCP options for network functionality, or many other
things.

  I won't address DHCPv6, because I haven't been tracking it.

  But let's have a fair evaluation.  If we decide that PANA fits the
requirements perfectly, the above objections apply equally well to it.
Therefore, those objections should be applied to all proposed changes to
the network.  Or, they shouldn't be applied to any proposed change.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 05 Nov 2007 17:11:36 -0800

>requirements perfectly, the above objections apply equally well to it.

Actually, I'm not clear that the objections apply equally well to PANA.

On the Windows platform at least, there is an API that permits integration 
of new EAP lower layers.  That means that PANA support can be added by a 
third party with no required changes to the operating system.

Since DHCP/EAP requires change to the DHCP state machine, the work required 
would be considerably greater.

---

From: Richard Pruss <[email-masked]>
Date: Tue, 06 Nov 2007 11:33:09 +1000

Bernard Aboba wrote, around 6/11/07 11:11 AM:
> On the Windows platform at least, there is an API that permits 
> integration of new EAP lower layers.  That means that PANA support can 
> be added by a third party with no required changes to the operating 
> system.
>
> Since DHCP/EAP requires change to the DHCP state machine, the work 
> required would be considerably greater.
>
>
>
Does PANA not also require changes to the DHCP state machine to stop it 
running until PANA has authenticated on the link local address?

---

From: Ralph Droms <[email-masked]>
Date: Mon, 5 Nov 2007 21:36:05 -0500

No, PANA would not require changes to the DHCP client behavior if the  
first hop relay agent is configured to discard DHCP messages until  
PANA authentication is complete.  Presumably whatever mechanism is  
used to allow IP traffic after PANA authentication could also trigger  
the relay agent to allow DHCP forwarding.

Of course, I'm speculating wildly here about implementation details  
without the benefit of any system architecture docs...

- Ralph

On Nov 5, 2007, at Nov 5, 2007,8:33 PM, Richard Pruss wrote:

>> integration of new EAP lower layers.  That means that PANA support  
>> can be added by a third party with no required changes to the  
>> operating system.
>>
> Does PANA not also require changes to the DHCP state machine to  
> stop it running until PANA has authenticated on the link local  
> address?
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2007 23:03:03 -0700

> DHCP + CHAP, new DHCP options for network functionality, or many other

Look, I don't want to put too fine a point on this, because I would  
actually very much like to see DHCP authentication get some use.   But  
the reality is that we already have well-understood mechanisms for  
doing DSL connections with DHCP.   The only reason we're talking about  
doing something different is because we're trying to accommodate an  
installed base that would like to make a two-step transition away from  
PPPoE.

So while it's true that in order to accommodate this particular kind  
of transition with this particular kind of installed base you would  
need some kind of client-side change, or some kind of client-side  
agent, it is not true that we have to choose which way to make the  
client-side change before we decide whether or not doing things this  
way is a good idea.  It is entirely permissible to discuss whether or  
not the change is really a good idea.   And it was in that spirit that  
I asked why nobody had responded to Iljitsch's objection.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Nov 2007 07:10:01 +0100

Bernard Aboba wrote:
> be added by a third party with no required changes to the operating system.

  On Windows 98?  And even the answer is "yes", I don't think we can
realistically expect many organizations to write new code for 98 at this
time.

> required would be considerably greater.

  Yes.

  Alan DeKok.

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 6 Nov 2007 09:20:14 -0500

> From: Ralph Droms, November 05, 2007 9:36 PM
> 
> No, PANA would not require changes to the DHCP client 
> behavior if the first hop relay agent is configured to 
> discard DHCP messages until PANA authentication is complete.  

I am assuming you are talking about discarding DHCP messages for the
second DHCP assigned IP address when the lease for the first address
expires.  In old PANA threads such as:
http://www1.ietf.org/mail-archive/web/pana/current/msg00376.html
They worried quite a bit about uncoordinated state machines resulting in
slow client logon.  Up to 30 second delays were mentioned. 

Since random duration global IP address assignment delays of up to 30
seconds is not acceptable, I am expect that PANA has fixed this.  Could
one of the PANA people explain how?  

BTW: even with the DHCP message for the 1st IP address, there are PANA
drafts which require DHCP client modifications.  For example:
ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-ietf-dhc-paa-opt
ion-05.txt
"defines new DHCPv4 and DHCPv6 options that contain a list of IP
addresses to locate one or more of PANA Authentication Agents (PAA)."

> Presumably whatever mechanism is used to allow IP traffic 
> after PANA authentication could also trigger the relay agent 
> to allow DHCP forwarding.

This would again result in DHCP Timeouts unless coordination of the
client state machine is occurring.  (And even if there is coordination
with the client, there is ugly system behavior if the 2nd client DHCP
message is initiated before the relay agent has completed updating its
filters!)

Eric
 
> Of course, I'm speculating wildly here about implementation 
> details without the benefit of any system architecture docs...
> 
> - Ralph
> 
> >>> requirements perfectly, the above objections apply 
> equally well to 
> >>> it.
> >>
> > Does PANA not also require changes to the DHCP state 
> machine to stop 
> > it running until PANA has authenticated on the link local address?
> >
> >

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 6 Nov 2007 10:28:51 -0500

> one of the PANA people explain how?  

I am not sure what exact PANA deployment scenario is being discussed
here, but 30 seconds delay mentioned in the old PANA thread is between
the time when DHCP is started and the time when an IPv4 link-local
address is configured after DHCP timeouts.

> addresses to locate one or more of PANA Authentication Agents (PAA)."

This is the default method for obtaining PAA's IP address.  This does
not mean this is the only way.  PANA allows other methods for
configuring PAA's IP address if defined.  Also, a particular
deployment where PAA always resides in access router may simply use
default gateway address as PAA's address and I believe all DHCP
clients understands Router option.

> message is initiated before the relay agent has completed updating its

I am not sure what coordination of the client state machine exactly
means, but to avoid the ugly behavior, a PAA implementation can delay
returning PANA authentication result until relay agent completes
filtering installation.

Yoshihiro Ohba

---

From: Alan DeKok <[email-masked]>
Date: Tue, 06 Nov 2007 23:24:43 +0100

Iljitsch van Beijnum wrote:
> Some things are harder to change than others. The problem with DHCP is
> that, unless I'm very much mistaken, for operating systems like Windows
> and MacOS, only the vendor can do this.

  Programs with root/admin permissions can shut off the native DHCP
stack, open raw sockets, and forcibly set IP parameters by hand.  This
kind of thing has been done before.

> Using PANA with link-local
> addresses may be hard (for instance, on Windows 98) or easy (if you can
> do this with IPv6 link-locals).

  Application-layer changes really have a lot of benefits.

  Alan DeKok.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Nov 2007 00:02:29 +0100

> address is configured after DHCP timeouts.

Apparently my message from earlier today (yesterday by the time this  
reaches the net) didn't make it, so once again:

A lot of this complexity can be avoided by using IPv6 link-local  
addresses, because those are created independently from "real" address  
assignment. This is of course only helpful if IPv6 is spoken on both  
ends, so that would leave the Windows 98 case out in the cold.

I believe it would be orders of magnitude easier to add PANA  
capability to a commercial OS because PANA doesn't need special access  
to the network and doesn't clash with existing capabilities. You could  
probably even run it from a browser as a java applet.

DHCP delays could be avoided by the DSLAM caching DHCP requests from  
unauthenticated hosts and only responding to those when the  
authentication has completed. However, if a short delay is unavoidable  
I don't think that's a show stopper, usually people connect after  
rebooting or some such, a process that takes a lot more time than  
having to wait for a DHCP retransmit or two.

And last but not least: I'm still waiting to hear how the DSL Forum or  
others intend to address IPv6. Apart from simply needing this  
capability in the near future, the prospect of having to rehash all of  
this in short order to add IPv6 isn't very atractive.

---

From: Richard Pruss <[email-masked]>
Date: Wed, 07 Nov 2007 20:29:37 +1000

> this in short order to add IPv6 isn't very atractive.
I suggest you address that question in a liaison from the IETF to the 
chairs of the DSLForum architecture group if you expect a serious answer 
on what the overall DSL architecture is for IPv6.

- Ric

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Nov 2007 11:38:22 +0100

On 7 nov 2007, at 11:29, Richard Pruss wrote:

> I suggest you address that question in a liaison from the IETF to  
> the chairs of the DSLForum architecture group if you expect a  
> serious answer on what the overall DSL architecture is for IPv6.

How is doing that helpful in our evaluation of the request made by the  
DSL Forum along with the notion that DHCP is the right solution for  
this?

The lack of ANY discussion of IPv6 coupled with the fact that DHCP is  
fundamentally incompatible with IPv6 as good as impunes this entire  
excercise.

I'm not seeing any progress here. I think it's time to wrap all of  
this up and tell the DSL Forum that what they want can't be blessed by  
the IETF so either they're going to do what they're going to do  
without that blessing or they start PARTICIPATING in the IETF process  
in some way rather than restate the same thing until the IETF produces  
the desired result.

Chairs: I suggest that it's time for a consensus call of some kind.

---

From: Richard Pruss <[email-masked]>
Date: Wed, 07 Nov 2007 20:51:48 +1000

Iljitsch van Beijnum wrote, around 7/11/07 8:38 PM:
>> chairs of the DSLForum architecture group if you expect a serious 
>> answer on what the overall DSL architecture is for IPv6.
> 
> DSL Forum along with the notion that DHCP is the right solution for this?
> 

I do not see DHCP as being "fundamentally incompatible" with IPv6.

> 
> I'm not seeing any progress here. I think it's time to wrap all of this 
> up and tell the DSL Forum that what they want can't be blessed by the 
> IETF so either they're going to do what they're going to do without that 
> blessing or they start PARTICIPATING in the IETF process in some way 
> rather than restate the same thing until the IETF produces the desired 
> result.

Please bear in mine that I am not the DSLForum and I would not project 
you irritation with me onto the DSLForum.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Nov 2007 13:14:58 +0200

> running until PANA has authenticated on the link local address?

You don't have to stop the DHCP state machine. PANA authentication would
normally complete while DHCP client is still retrying. In case it does not,
then all we need to do is to trigger the DHCP client to trying again. No
changes to the DHCP state machine.

Another solution for the dealing with legacy hosts can be to not gate the
DHCP configuration, but still require PANA authentication.

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 7 Nov 2007 13:24:46 +0200

> Chairs: I suggest that it's time for a consensus call of some kind.

This is the 4th time we are discovering

a. There is no clear justification why something like DHCP-auth is needed.
b. DHCP-auth is a bad idea. 

Alper

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Nov 2007 12:22:56 +0100

On 7 nov 2007, at 11:51, Richard Pruss wrote:

>> How is doing that helpful in our evaluation of the request made by  
>> the DSL Forum along with the notion that DHCP is the right solution  
>> for this?
>> The lack of ANY discussion of IPv6 coupled with the fact that DHCP  
>> is fundamentally incompatible with IPv6 as good as impunes this  
>> entire excercise.

> I do not see DHCP as being "fundamentally incompatible" with IPv6.

If that is the case, then why is there a completely separate DHCPv6  
protocol?

>> this up and tell the DSL Forum that what they want can't be blessed  
>> by the IETF so either they're going to do what they're going to do  
>> without that blessing or they start PARTICIPATING in the IETF  
>> process in some way rather than restate the same thing until the  
>> IETF produces the desired result.

> Please bear in mine that I am not the DSLForum and I would not  
> project you irritation with me onto the DSLForum.

Irritation is irrelevant. What's relevant is that the IETF is a slow  
moving standards organization. Unless a lot of people are very wrong,  
any work started today will be relevant during the period in time  
where we run out of IPv4 addresses. The way I see it, that makes it  
necessary for any and all technologies that the IETF works on, and  
especially the ones that it starts new work on, must be able to work  
with both IPv4 and IPv6. Maybe the IPv6 part isn't going to be  
implemented immediately. That's a decision that each vendor / service  
provider has to make for themselves. But the IETF can't ignore IPv6,  
which, so far, pretty much all participants in this discussion have  
been doing.

---

From: Mark Townsley <[email-masked]>
Date: Wed, 07 Nov 2007 15:45:16 +0100

> which, so far, pretty much all participants in this discussion have 
This would not be the first proposal to enter the IETF with its primary 
focus on IPv4. Indeed, during my tenure on the IESG I have reviewed a 
number of documents which either did not have IPv6 basics included at 
all, or did in passing with a number of associated errors and omissions. 
It is for this that I asked Margaret Wasserman to give a tutorial 
presentation at the int-area meeting a year or so ago to identify common 
problems that she had seen with documents which do not correctly 
consider IPv6. I think she did a great job.

So, while you certainly are solving problems with IPv6 in the forefront 
of your mind, not all of the IETF, or industry at large, is. It is 
clearly our job as shepherds of IPv6 to make sure that anything 
developed for IPv4 works with IPv6, and as well to design new and 
improved capabilities into IPv6 that do not exist in IPv4. However, to 
suggest that new work on IPv4 be halted because the authors did not 
start out with IPv6 in the forefront of their minds is rather unrealistic.

Back to the issue at hand, I see no technical reason why EAP in DHCPv6 
would not work in largely the same fashion as the proposed EAP in 
DHCPv4. I doubt the authors have any aversion at all to specifying this 
in detail, with the help of the IETF to ensure that it is done correctly.

As for IPv6 deployment for DSL, I will be raising this at the 
architecture group session and plenary during the next quarterly DSL 
Forum meeting in the hopes of spurring more active development and 
deployment.

- Mark

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Nov 2007 16:13:13 +0100

On 7 nov 2007, at 15:45, Mark Townsley wrote:

[...]

> However, to suggest that new work on IPv4 be halted because the  
> authors did not start out with IPv6 in the forefront of their minds  
> is rather unrealistic.

I certainly don't have a problem with people starting with IPv4 -  
after all, that's still what brings in the money.

The problem here is that the suggested work isn't something that's  
limited to IPv4, in the same way that work on OSPFv2 is limited to  
IPv4. What we're talking about is authentication, something that needs  
to happen before people get access to the network. By doing this over  
IPv4 we are likely to create two problems:

1. Running IPv6-only -> no authentication -> no access
2. Running dual stack isn't addressed so it probably requires  
additional "stuff" that's left out of the spec -> bad interoperability

> Back to the issue at hand, I see no technical reason why EAP in  
> DHCPv6 would not work in largely the same fashion as the proposed  
> EAP in DHCPv4. I doubt the authors have any aversion at all to  
> specifying this in detail, with the help of the IETF to ensure that  
> it is done correctly.

Well, at least that would be something. The practical problem with  
that is that the boxes involved now have to snoop two different  
protocols, which probably means that this isn't going to be  
implemented in practice any time soon. On a more fundamental level,  
this makes implementation of DHCPv6 a de facto requirement for IPv6  
hosts, something I REALLY don't like.

In my opinion, if doing something is creates so many problems that  
usually means the approach is wrong.

Also, when you need to make changes at both ends, that's an  
opportunity to get stuff right, because you don't get to do that all  
that often.

> Forum meeting in the hopes of spurring more active development and  

Great.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 7 Nov 2007 11:26:00 -0500

> in detail, with the help of the IETF to ensure that it is done correctly.

On the other hand, since both DHCPv6 and PANA requires an IP address
to operate, I don't see a reason why IETF needs to re-invent the wheel
to carry EAP over IP.  I think this is one important factor to
understand why people are so concerned with EAP/DHCPv4 proposal.

Yoshihiro OHba

---

From: Mark Townsley <[email-masked]>
Date: Wed, 07 Nov 2007 17:57:45 +0100

> understand why people are so concerned with EAP/DHCPv4 proposal.
I agree that the motivations for EAP in DHCP are not as clear for IPv6
as for IPv4. I can't see how this wouldn't be expected given that, due
to wildly different deployment levels, residential IPv4 access has a
fairly constrained environment in terms of realistic design choices, and
residential IPv6 access has a great deal more flexibility at this point
in time. This is complicated by the fact that IPv4 and IPv6 have very
different properties when it comes to address assignment, filtering,
support of link-local addressing and support for multiple addresses on a
single interface. In this particular instance, trying to wedge the best
solution for IPv6 into IPv4, while noble, may end up as unrealistic and
misguided as trying to wedge an IPv4 solution into IPv6.

- Mark

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 7 Nov 2007 13:50:09 -0500

> ends, so that would leave the Windows 98 case out in the cold.

I fully agree.  I can think of the following sequence if CPE has an
IPv6 link-local address and needs a service IPv4 address:

1. CPE configures an IPv6 link-local address and run PANA with the
link-local address.

2. Run DHCPv4 to obtain a service IPv4 address

If a service IPv6 address is also required, CPE can run DHCPv6 or IPv6
stateless address configuration in parallel with 3.

There are a number of deployment scenarios possible with PANA.  The
above scenario is just one example.  I am sure we can find out a PANA
deployment scenario that can fit DSL if people pay more positive
attention to PANA.

Yoshihiro Ohba