Subject: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering for DHCP authentication

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

Should this conversation not move to the int-area?

Alper Yegin wrote, around 6/11/07 5:19 AM:
> 1. CPE configures a pre-PANA IP address using DHCP
> 2. CPE runs PANA
> 3. CPE configures "session IP address" using DHCP
>   
>
The PANA idea if using short lease/long lease DHCP address switching in 
DSL deployments is simply not feasible.  BRAS's with over 60K 
subscribers are common and many providers have central city pops of more 
than a million subscribers.

During a pop restart the 60 second lease on a million subscribers would 
at best result in a sustained load of more than 16000 DHCP requests / 
second smashing through the relays and into the DHCP servers until the 
users had gradually authenticated.

- Ric

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

---

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

Does the short lease/long lease scenario scale the DHCP server load  
by more than a factor of two?

- Ralph

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

> The PANA idea if using short lease/long lease DHCP address  
> switching in DSL deployments is simply not feasible.  BRAS's with  
> over 60K subscribers are common and many providers have central  
> city pops of more than a million subscribers.
>
> During a pop restart the 60 second lease on a million subscribers  
> would at best result in a sustained load of more than 16000 DHCP  
> requests / second smashing through the relays and into the DHCP  
> servers until the users had gradually authenticated.
>
> - Ric
>
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 6 Nov 2007 22:39:43 -0500

> From: Ralph Droms, November 05, 2007 9:37 PM
> 
> Does the short lease/long lease scenario scale the DHCP 
> server load by more than a factor of two?

Ralph,

The messages the DHCP servers will double.  
The messages with L3 edge (BRAS) will more than double.  
The messages with the CPE will more than triple.  

(Below is some rough math. I might have missed a message or two, but the
general trend is what I am trying to show.)

-----------------------------------------
CPE Messages
-----------------------------------------
DHCP Auth, assuming a 2 message EAP Method, the messages used by EAP
would be equal
+ 6 Messages (draft-pruss-dhcp-auth-dsl-01)

PANA+DHCP Method
+ 4 Messages: DHCP 1st IP address
~ (+2) DHCP renews per 60 seconds until authenticated
+ 11 Messages PANA with BRAS (draft-ietf-pana-pana-18, section 4.1)
+ 4 Messages: DHCP 2nd IP address

-----------------------------------------
L3 Edge (BRAS) Messages
-----------------------------------------
DHCP Auth, EAP Method
+ 8 Messages (draft-pruss-dhcp-auth-dsl-01)

PANA Method
+ 4 Messages: DHCP 1st IP address
~ (+2) DHCP renews per 60 seconds until authenticated
+ 11 Messages PANA with CPE (draft-ietf-pana-pana-18, section 4.1)
+ 2 messages min for validating with EAP Server
+ 4 Messages: DHCP 2nd IP address

-----------------------------------------
L2 Edge (DSLAM or Access Switch) Messages
-----------------------------------------
DHCP Auth, EAP Method
+ 6 Messages snooped (draft-pruss-dhcp-auth-dsl-01)

PANA+DHCP Method
+ 4 Messages Snooped: DHCP 1st IP address
~ (+2) DHCP renews per 60 seconds until authenticated
If snooping: 11 Messages PANA (draft-ietf-pana-pana-18, section 4.1)
Else if explicit policy distribution like ANCP, ~4 messages (one policy
per address)
+ 4 Messages Snooped: DHCP 2nd IP address

Eric

---

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

First of all, there is no way use of PANA would lead to more DHCP traffic.
How can that be true when carrying EAP over DHCP always at the minimum
contribute 2 additional round-trips just for the sake of transporting EAP?  

In the worst case (DHCP-configured pre-PANA address), there are two round
trips for that 1st DHCP. Even in that case PANA is no worse than DHCP-auth.

And then there are better cases, e.g. use of link-local address as pre-PANA
address, rapid commit, etc.

As for your 11-msg PANA call flow count, the example you used is the most
verbose one. If you turn on the optimizations (agent-side initiation,
piggybacking) it reduces to 2 round trips.

So, in the worst case scenario (full dhcp, pana, another full dhcp), PANA
has additional 2 round-trips. By kicking in more optimized deployment
choices, this difference can be diminished.

Alper

> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[email-masked]]
> Sent: Wednesday, November 07, 2007 5:40 AM
> To: Ralph Droms (rdroms)
> Cc: [email-masked]; Internet Area
> Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WG rechartering
> forDHCPauthentication
>

---

From: Ralph Droms <[email-masked]>
Date: Wed, 7 Nov 2007 07:06:15 -0500

Eric - I was mostly responding to Ric's description of the excessive  
load on DHCP servers in the short-lease/long-lease scenario.  As I  
understand the short-lease/long-lease scenario, if we assume that  
authentication takes place in the short-lease window, the load on the  
DHCP servers would double.  Significant, sure, but not game-changing  
in the way Ric implied.

- Ralph

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Nov 2007 08:04:59 -0500

Hi Ralph,

Doubling the load on the DHCP servers probably will not change the game.

The extra load on the L3 Edge/BRAS could easily change the game (and
hence the emails from Peter (Redback) & Bill (Juniper)).  

The extra complexity with the CPE has always been my biggest concern,
and is why I entered the thread many weeks ago.

Eric 

> From: Ralph Droms, November 07, 2007 7:06 AM
> 
> Eric - I was mostly responding to Ric's description of the 
> excessive load on DHCP servers in the short-lease/long-lease 
> scenario.  As I understand the short-lease/long-lease 
> scenario, if we assume that authentication takes place in the 
> short-lease window, the load on the DHCP servers would 
> double.  Significant, sure, but not game-changing in the way 
> Ric implied.
> 
> - Ralph
> 
> > (Below is some rough math. I might have missed a message or 
> two, but 
> > the general trend is what I am trying to show.)
> >
> > ~ (+2) DHCP renews per 60 seconds until authenticated If 
> snooping: 11 
> > Messages PANA (draft-ietf-pana-pana-18, section 4.1) Else 
> if explicit 
> > policy distribution like ANCP, ~4 messages (one policy per address)

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 7 Nov 2007 09:43:31 -0500

> From: Alper Yegin, November 07, 2007 6:04 AM
> 

? You say below "full dhcp, pana, another full dhcp".  Sounds like
doubling the DHCP traffic to me.

But there is another issue.  It is very normal for AAA servers to take
time for all the sessions to authenticate after a BRAS reboot or
pop-wide power failure.  PANA has the potential to introduce a large
amount of additional DHCP traffic simply due to short lease timer renews
being requested prior to authentication completion.

This sounds like a pretty effective distributed denial of service attack
to me.

> How can that be true when carrying EAP over DHCP always at 
> the minimum contribute 2 additional round-trips just for the 
> sake of transporting EAP?  

I was trying to make the EAP method equivalent between the two cases.
Am I missing something?
 
> In the worst case (DHCP-configured pre-PANA address), there 
> are two round trips for that 1st DHCP. Even in that case PANA 
> is no worse than DHCP-auth.
> 
> And then there are better cases, e.g. use of link-local 
> address as pre-PANA address, rapid commit, etc.
> 
> As for your 11-msg PANA call flow count, the example you used 
> is the most verbose one. If you turn on the optimizations 
> (agent-side initiation,

I chose the best message flow I could find within
draft-ietf-pana-pana-18.  As I read your words above, I cannot match all
the potential variations to the DSLF requirements.  Is there another
documented DHCP+PANA message flow somewhere which meets the DSLF
requirements which I should use instead?

Eric
 
> 
> So, in the worst case scenario (full dhcp, pana, another full 
> dhcp), PANA has additional 2 round-trips. By kicking in more 
> optimized deployment choices, this difference can be diminished.
> 
> 
> Alper
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 Nov 2007 00:33:40 +0200

> hence the emails from Peter (Redback) & Bill (Juniper)).

Hmmm... I followed up this feedback with Bill Welch in more technical
detail, and if you remember it ended with a "And yes your observation is
correct, the DHCP auth solution with EAP has the same issues."

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

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 13 Nov 2007 00:52:59 +0200

> doubling the DHCP traffic to me.

If you compare it with EAP/DHCP, which adds at least two additional
round-trips to usual DHCP, then you'd see even in that worst case (for PANA)
scenario, the DHCP traffic using PANA is same as that of EAP/DHCP solution.

> being requested prior to authentication completion.

You seem to assume the short leases are too short. 

> I was trying to make the EAP method equivalent between the two cases.

Yes. Ric said dedicated DHCP messages will carry EAP and in the very best
case that means two additional round-trips of DHCP for the sake of shuttling
EAP.

> the potential variations to the DSLF requirements.  Is there another

What requirements are you referring to? The ones that DSLF provided to IETF
does not really seem to talk about variations you are referring to. 

> requirements which I should use instead?

Have you read the PANA spec? 

All these optimizations are documented there. Of course you cannot find call
flows depicting every possible scenario in this IETF document.  

Alper

---

From: "Peter Arberg" <[email-masked]>
Date: Mon, 12 Nov 2007 15:13:59 -0800

I do not think you and Bill were talking about the same issues
in the email.

It is clear that any solution which requires a temporary ip-address
will create more turn on a BRAS, and the subscriber setup rate will
very likely go down compared to a solution which will finish 
authentication before ip-address allocation.

Peter

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: 12. november 2007 14:34
> To: 'Eric Voit (evoit)'; 'Ralph Droms (rdroms)'
> Cc: [email-masked]; 'Internet Area'
> Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc 
> WGrecharteringforDHCPauthentication
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 14 Nov 2007 00:51:41 +0200

Hi,

> authentication before ip-address allocation.

Can you please elaborate on the impact of using a link-local or
DHCP-assigned IP address prior to running access authentication? Details
would help us understand the level of impact, and let us see if we can
identify any remedies.

Thanks.

Alper

---

From: Richard Pruss <[email-masked]>
Date: Wed, 14 Nov 2007 09:23:43 +1000

> would help us understand the level of impact, and let us see if we can
Well if you use link local you need to stop the DHCP client stack which 
means changing the DHCP stack which you have said is scary many times.  
Secondly to run PANA with link local to the NAS, you need to re engineer 
all the layer 2 SAVA security because the link local addresses look like 
spoofed addresses to the layer 2 switches and would be dropped. If you 
couple that with all the rest of the extra mess of PANA discovery stuff 
then it is obvious that DHCP authentication it is much, much cleaner and 
leaner.

If you run DHCP-assigned address prior to authentication.  The whole 
layer 2 network is exposed to attack by unauthenticated IP end-point.  
The SAVA done by DSLAMs and first hop switches is eliminated because 
unauthenticated  users have DHCP assigned addresses.  Not to mention 
thet obvious point that every renew during the unauthenticated period is 
extra messaging which for 60K-500K  subscriber access networks are 
effectively huge extra message loads on everything in the DHCP path.  
Plus the point that you are now saying that 60 seconds is too short for 
the renew, which means that from around 10-15 second logins, which we 
have today, the latency is going to 60 seconds +.  Worse than that, the 
worst time for access is after a massive power outage where we have 
heard of is 20 minutes during recoveries due to AAA server loads and for 
this vulnerable time with PANA the DHCP has 20 extra renew per client 
which is millions of extra messages smashing things up.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 15 Nov 2007 01:23:01 +0200

Hi,

 

Alper> If you are using link-local IP address prior to PANA, that means you
don't attempt to configure an IP address using DHCP prior to successful
completion of PANA. That does not alter DHCP state machine.

Secondly to run PANA with link local to the NAS, you need to re engineer all
the layer 2 SAVA security because the link local addresses look like spoofed
addresses to the layer 2 switches and would be dropped. 

Alper> This statement gives me the impression that L2 SAVA is based on
snooping DHCP only and it cannot be touched at all. Well, this cannot be
true if you consider IPv6. It has to deal with link-local IP addresses and a
lot more. See
http://ietf.org/internet-drafts/draft-baker-sava-implementation-00.txt. And
btw, somehow I see IPv6 is being characterized as a "future" thing that does
not exist today, but I know IPv6 is deployed in several DSL networks. 

If you couple that with all the rest of the extra mess of PANA discovery
stuff then it is obvious that DHCP authentication it is much, much cleaner
and leaner.

Alper> If you can provide a technical point regarding the discovery, we can
understand better.

If you run DHCP-assigned address prior to authentication.  The whole layer 2
network is exposed to attack by unauthenticated IP end-point.  The SAVA done
by DSLAMs and first hop switches is eliminated because unauthenticated
users have DHCP assigned addresses.  

Alper> I don't see anything wrong with SAVA there. Up until the host
reconfigures its IP address using second DHCP after successful PANA, there
is the pre-PANA address that SAVA system checks.

Alper> And. unauthenticated IP end-point does not have be a thread, because
the network can limit that host's traffic to just "running PANA with the
PAA."

Not to mention thet obvious point that every renew during the
unauthenticated period is extra messaging which for 60K-500K  subscriber
access networks are effectively huge extra message loads on everything in
the DHCP path.  

Alper> As I have explained to Eric, if you are concerned about "load on DHCP
path", loading more things to DHCP like access authentication is not going
to help with reducing that load. This is fundamentally contradicting.

Plus the point that you are now saying that 60 seconds is too short for the
renew, which means that from around 10-15 second logins, which we have
today, the latency is going to 60 seconds +.  

Alper> Sorry I couldn't follow this. What latency is that 60+? DHCP lease
for the pre-PANA address shall be long enough to accommodate typical access
authentication latency in order to reduce the possibility of renewals. 

Worse than that, the worst time for access is after a massive power outage
where we have heard of is 20 minutes during recoveries due to AAA server
loads and for this vulnerable time with PANA the DHCP has 20 extra renew per
client which is millions of extra messages smashing things up.

Alper> Have you considered how many EAP/DHCP retransmissions are going to
occur due to EAP retranmissions during that 20 minutes? Assuming no crazy
EAP implementation or configuration would have a 60-second timeout for
retranmissions, the answer is at least "more", if not "a lot more".

Alper

---

From: Richard Pruss <[email-masked]>
Date: Thu, 15 Nov 2007 15:16:19 +1000

Alper Yegin wrote, around 15/11/07 9:23 AM:
> Alper> If you are using link-local IP address prior to PANA, that means 
> you don’t attempt to configure an IP address using DHCP prior to 
> successful completion of PANA. That does not alter DHCP state machine.

<RMP> Well do not run until after PANA state for DHCP is an alteration 
of the DHCP state machine and of course a change in the DHCP client.

> spoofed addresses to the layer 2 switches and would be dropped.
> 
> true if you consider IPv6. It has to deal with link-local IP addresses 
> and a lot more. See 
> http://ietf.org/internet-drafts/draft-baker-sava-implementation-00.txt. 
> And btw, somehow I see IPv6 is being characterized as a “future” thing 
> that does not exist today, but I know IPv6 is deployed in several DSL 
> networks.
<RMP>  Fred is proposing how SAVA for IPv6 could possibly work one day 
in the future.  There is a huge difference between that and the IPv4 
SAVA which is deployed.  I know of no residential DSL services in the 
work.  This is one thing I would love to learn I am wrong about, please 
name a provider doing residential IPv6 over DSL.

> stuff then it is obvious that DHCP authentication it is much, much 
> cleaner and leaner.
> 
> Alper> If you can provide a technical point regarding the discovery, we 
> can understand better.
<RMP> Provide a side to side comparison of PANA verse DHCP Auth 
including L2 switches and SAVA security in L2 and it is very obvious. I 
notice you have been careful just to cast smoke over the number Eric put 
out but not provided your own.

> unauthenticated  users have DHCP assigned addresses. 
> 
> Alper> I don’t see anything wrong with SAVA there. Up until the host 
> reconfigures its IP address using second DHCP after successful PANA, 
> there is the pre-PANA address that SAVA system checks.
> 
> Alper> And… unauthenticated IP end-point does not have be a thread, 
> because the network can limit that host’s traffic to just “running PANA 
> with the PAA.”
<RMP> How?  Please specify which elements need to run what shiny new 
protocols and how this done.

> access networks are effectively huge extra message loads on everything 
> in the DHCP path. 
> 
> Alper> As I have explained to Eric, if you are concerned about “load on 
> DHCP path”, loading more things to DHCP like access authentication is 
> not going to help with reducing that load. This is fundamentally 
> contradicting.
> 
> have today, the latency is going to 60 seconds +. 
> 
> Alper> Sorry I couldn’t follow this. What latency is that 60+? DHCP 
> lease for the pre-PANA address shall be long enough to accommodate 
> typical access authentication latency in order to reduce the possibility 
> of renewals.
<RMP>Latency from user line up until services is now some unspecified 
large number.

> 
>  
> 
> Worse than that, the worst time for access is after a massive power 
> outage where we have heard of is 20 minutes during recoveries due to AAA 
> server loads and for this vulnerable time with PANA the DHCP has 20 
> extra renew per client which is millions of extra messages smashing 
> things up.
> 
> Alper> Have you considered how many EAP/DHCP retransmissions are going 
> to occur due to EAP retranmissions during that 20 minutes? Assuming no 
> crazy EAP implementation or configuration would have a 60-second timeout 
> for retranmissions, the answer is at least “more”, if not “a lot more”.

<RMP>Assuming both proposals use the same EAP method through the AAA 
path, main difference is all the extra messages on the DHCP path to the 
server from PANA. Unless of course you fully couple PANA to the DHCP 
relay stack and do local caching for the relay responses as you have 
said in the past.  Which when one gets down to the real implementation 
impact of PANA has to do exactly the same things as DHCP Auth in the CPE 
and the BRAS DHCP stacks, and has the additional impacts to other 
elements that DHCP auth leaves untouched.

- Ric

---

From: "Alper Yegin" <[email-masked]>
Date: Sat, 17 Nov 2007 01:45:32 +0200

> > you don't attempt to configure an IP address using DHCP prior to

Not starting the DHCP client is the simplest way. And that, obviously, has
no change whatsoever on the DHCP SM or client.

> > And btw, somehow I see IPv6 is being characterized as a "future" thing

NTT. Since 2001.

> out but not provided your own.

I already provided the numbers in response to Eric's email. Let me know if
you have a specific question.

Meanwhile, I hope you are seeing the fundamental problem: You cannot reduce
DHCP "load" if you "overload" DHCP with EAP.

> > Alper> And. unauthenticated IP end-point does not have be a thread,
> > because the network can limit that host's traffic to just "running PANA
> > with the PAA."

There is no protocol in there. It's all filtering.

> > Alper> As I have explained to Eric, if you are concerned about "load on
> > DHCP path", loading more things to DHCP like access authentication is
> > Alper> Sorry I couldn't follow this. What latency is that 60+? DHCP

I didn't understand your point (or conclusion?).

> > for retranmissions, the answer is at least "more", if not "a lot more".
> 
> said in the past.  

I never said such a thing. I suspect you are confusing someone else's
statement about some other scenario/proposal.

> Which when one gets down to the real implementation

Disagree, as explained throughout this thread.

Alper

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Nov 2007 20:21:41 +0100

(I have a certain oppinion on DHCPAuthentication vs PANA as well but it
  seems many things have been already told.)

Alper Yegin wrote:
[...]
>> This is one thing I would love to learn I am wrong about, please 

NERIM in France since about 2003.

But Alper - can you cite how NTT is doing it?  How many customers?  How
many addresses delivered to customer?  What kind of addresses are
delivered?   What transition mechanism?  I can for NERIM.

I'm talking from a 2001 experience of actually picking up the phone and
calling NTT and asking them for IPv6 access.

All these things are important in order to really answer the question
raised above.

It may all be in that 'residential' keyword.  How much 'residential' is
a SOHO?  What does 'residential' really mean in Japanese?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 20 Nov 2007 00:26:23 +0200

Hi Alex,

I need to let NTT folks answer that.

Meanwhile, the point I was trying to make is, IPv6 over DSL is not a future
thing that we can blindly ignore. Tossing the ball back to DSLF is just a
recipe for avoiding discussions. 

Alper

> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: Saturday, November 17, 2007 9:22 PM
> To: Alper Yegin
> Cc: [email-masked]; [email-masked]; 'Internet Area'
> Subject: Re: [Int-area] Re: [dhcwg] Discussion of dhc

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 12:26:13 +0900 (JST)

(due to some technical problem, I missed int-area ML. so
please forgive me to send this message again.)

From: "Alper Yegin" <[email-masked]>
Subject: RE: [Int-area] Re: [dhcwg] Discussion of dhc WGrecharteringforDHCPauthentication
Date: Tue, 20 Nov 2007 00:26:23 +0200

> I need to let NTT folks answer that.

Which means Me , Alper ? :-p

> > But Alper - can you cite how NTT is doing it?  

http://www.ipv6style.jp/en/statistics/services/index.shtml

is a good reference what we're doing in Japan. Not only by NTT.

Talking about ISP service, please see 

http://www.v6.ntt.net/index_e.html

> > How many customers?  

We can not disclose without proper permission from company, sorry about that.

> > How many addresses delivered to customer?  
> > What kind of addresses are delivered?   

Please look at RFC4241.
Actually, we've modified a bit in addition to this model.
Basically, we've added RA onto the uplink between CPE and Access Concentrator
because of some operating system like Windows Vista uses the strong model
for its network design.

If I could have a chance, I am grad to tell about our architecture
in Vancouvor in some proper place.

> >What transition mechanism?  

No transition mechanism.

Also,  we've already commercialized "softwire" service named "OCNIPv6".
Basically, this is as same as we've discussed within SOFTWIRE WG of IETF.

> > a SOHO?  What does 'residential' really mean in Japanese?

SOHO as well as just an apartment or house.

One my house in Tokyo had been equipped with residential IPv6/v4 dual ADSL
service from my own company.

I believe that this is residential :-)

(Now I personally am using FTTH service from NTT as well with IPv6 
softwire commercial service on it.)

Best regards,

Shin Miyakawa
NTT Communications Corporation

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 12:24:03 +0900 (JST)

Please look at RFC4241.

No transition mechanism.

Best regards,

Shin Miyakawa

---

From: Shin Miyakawa <[email-masked]>
Date: Tue, 20 Nov 2007 12:24:03 +0900 (JST)

Please look at RFC4241.

No transition mechanism.

Best regards,

Shin Miyakawa

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 20 Nov 2007 16:38:02 +0100

Shin Miyakawa-san, thanks for the reply; to see such widespread adoption 
of IPv6 in Japan is motivating.

Shin Miyakawa wrote:
[...]
>>> What kind of addresses are delivered?   

Looked at it.  It says mainly PPPv6 and DHCPv6 prefix delegation.  For 
our discussion here that sounds as supportive argument for DHCP, PPP and 
IPv6.  It doesn't say PANA.

> in Vancouvor in some proper place.

To me it sounds as a nice presentation slot for one of the IPv6 or DHC 
related working groups.  But probably this has already been presented.

> softwire commercial service on it.)

I'm happy to see this at IETF.

FTTH (Fiber-To-The-Home) supporting IPv6 is interesting too.  Is there a 
IPv6-over-FTTH document somewhere?

Alex

---

From: Jari Arkko <[email-masked]>
Date: Thu, 29 Nov 2007 16:53:35 +0200

Ric, Alper,

"SAVA" as in the IETF effort? Or the specific approach that DSL networks
use to guard against address spoofing? I think the latter... lets keep
the SAVA arguments out of this discussion. There's a BOF in this IETF
about this, and it is far too early to state anything about the end
results. But so far all the designs we have talked about in that group
for IPv6 have involved support for both stateless and DHCP.

Jari