Subject: RE: Agenda issue

From: Sheng Jiang <[email-masked]>
Date: Thu, 05 Mar 2009 11:00:27 +0800

Hi, Fred,

We have submitted a new draft, draft-jiang-incremental-CGN-00. I think we are
already on the vows agenda. Are we? If no yet, please count us in. Thanks.

Best regards,

Sheng 

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]] On Behalf Of Fred Baker
>Sent: Thursday, March 05, 2009 10:16 AM
>To: IPv6 Operations
>Subject: Agenda issue
>
>I have gotten a number of folks asking for time on the agenda, but I 
>have a problem:
>
>
>-rw-rw-r--  1 fred  fred   19268 Sep 10 05:33 draft-ietf-v6ops-ra- 
>guard-01.txt
>-rw-rw-r--  1 fred  fred   61870 Sep 29 08:52 draft-miyata-v6ops- 
>snatpt-02.txt
>-rw-rw-r--  1 fred  fred   48468 Oct  1 10:58 draft-endo-v6ops- 
>dnsproxy-01.txt
>-rw-rw-r--  1 fred  fred   43841 Oct 15 10:48 draft-ietf-v6ops-tunnel- 
>security-concerns-
>01.txt
>-rw-rw-r--  1 fred  fred   18562 Oct 15 10:48 draft-krishnan-v6ops- 
>teredo-update-04.txt
>-rw-rw-r--  1 fred  fred   53090 Oct 30 10:22 draft-wbeebee-ipv6-cpe- 
>router-03.txt
>-rw-rw-r--  1 fred  fred   36662 Nov  3 10:15 draft-bajko-v6ops-port- 
>restricted-ipaddr-a
>ssign-02.txt
>-rw-rw-r--  1 fred  fred   48973 Nov  3 11:06 draft-luo-v6ops-6man- 
>shim6-lbam-00.txt
>-rw-rw-r--  1 fred  fred   30429 Nov  3 14:26 draft-chown-v6ops-rogue- 
>ra-02.txt
>-rw-rw-r--  1 fred  fred  134587 Nov  3 16:14
>draft-thaler-v6ops- teredo-extensions-02.tx t
>-rw-rw-r--  1 fred  fred   16462 Feb 17 14:52 draft-rgaglian-v6ops- 
>v6inixp-01.txt
>-rw-rw-r--  1 fred  fred    9716 Feb 18 08:01 draft-denis-v6ops-nat- 
>addrsel-00.txt
>-rw-rw-r--  1 fred  fred   41369 Feb 23 22:05 draft-bnss-v6ops- 
>upnp-00.txt
>-rw-rw-r--  1 fred  fred   19211 Mar  4 14:11 draft-vyncke-vdv-v6ops- 
>conf-stats-00.txt
>
>
>I see four new drafts post-Minneapolis. The Rogue RA and Teredo drafts, 
>whose last call completed several months ago and the write-up is 
>awaiting new drafts, don't have new drafts.
>
>Hello? Anyone out there? I need new drafts (cut-off date is Friday) for 
>anything folks expect to discuss in the WG meeting...
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 5 Mar 2009 00:55:22 -0800

OK. I truly wish you had put the working group moniker in the draft  
name (individual submission to a named working group), as it is hard  
to keep track of work in a working group with individual submission  
names.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 05 Mar 2009 17:28:47 +0800

For sure. We know the draft name rules. When we wrote the draft, we were not sure
which WG it should be submitted. It seems relevant to both v6ops and behave. We can
fix it in 01 version by putting v6ops into the draft name.

Best regards,

Sheng

>From: Fred Baker [mailto:[email-masked]] 
>Sent: Thursday, March 05, 2009 4:55 PM
>To: Sheng Jiang
>Cc: 'IPv6 Operations'; 'Brian Carpenter'
>Subject: Re: Agenda issue
>
>OK. I truly wish you had put the working group moniker in the 
>draft name (individual submission to a named working group), 
>as it is hard to keep track of work in a working group with 
>individual submission names.
>
>> We have submitted a new draft, 
>draft-jiang-incremental-CGN-00. I think 
>> we are already on the vows agenda. Are we? If no yet, please 
>count us 
>> in.
>> Thanks.
>>
>> Best regards,
>>
>> Sheng
>>
>>> I see four new drafts post-Minneapolis. The Rogue RA and Teredo 
>>> drafts, whose last call completed several months ago and 
>the write-up 
>>> is awaiting new drafts, don't have new drafts.
>>>
>>> Hello? Anyone out there? I need new drafts (cut-off date is Friday) 
>>> for anything folks expect to discuss in the WG meeting...
>>>
>>
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 5 Mar 2009 18:32:17 -0800

> [mailto:[email-masked]] On Behalf Of Sheng Jiang
> Sent: Thursday, March 05, 2009 1:29 AM
> To: 'Fred Baker'
> Subject: RE: Agenda issue
> 
> which WG it should be submitted. It seems relevant to both 
> v6ops and behave.

As a BEHAVE co-chair, I haven't seen a request for agenda time 
for draft-jiang-incremental-CGN-00, nor any discussion about the 
draft on the BEHAVE mailing list.

> We can fix it in 01 version by putting v6ops into the draft name.

Renaming a draft starts it at -00.

Anyway, regarding your draft:  it says that the CGN has to terminate 
the 6-over-4 tunnel.  Couldn't some other device -- not necessarily 
the CGN -- terminate that tunnel?  If so, then I believe your
proposal is very much just a NAT44 ("CGN") and a 6-over-4 tunnel
from the in-home gateway to some device that terminates the
tunnel and has IPv6 Internet connectivity.  This tunnel concentrator
might belong to the ISP providing IPv4 service, but it might also be
offered by someone else on the Internet (as a separate service), in
which case the 6-over-4 tunnel might actually go *across* the 
service provider's NAT44 ("CGN").

-d

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 06 Mar 2009 12:03:39 +0800

>From: Dan Wing [mailto:[email-masked]] 

>Renaming a draft starts it at -00.

Thanks, we can rename it with 00 and WG name.

>Anyway, regarding your draft:  it says that the CGN has to 
>terminate the 6-over-4 tunnel.  Couldn't some other device -- 
>not necessarily the CGN -- terminate that tunnel?  If so, then 
>I believe your proposal is very much just a NAT44 ("CGN") and 
>a 6-over-4 tunnel from the in-home gateway to some device that 
>terminates the tunnel and has IPv6 Internet connectivity.  
>This tunnel concentrator might belong to the ISP providing 
>IPv4 service, but it might also be offered by someone else on 
>the Internet (as a separate service), in which case the 
>6-over-4 tunnel might actually go *across* the service 
>provider's NAT44 ("CGN").

Yes, your understanding is right. NAT44 and 6-over-4 tunnel can be splitted. They
are separate technologies.

In our proposal, we suggest to integrate NAT44 and 6-over-4 tunnel into a same
device box (CGN) so that ISPs can deploy it with a clear IPv6 migration strategy.
Here, we may extend the concept of CGN a little bit. When we talk about CGN, we are
actually referring to a carrier-grade device, which integrates NAT functions and
other integrated technologies.

Best regards,

Sheng

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 6 Mar 2009 08:01:59 -0800

For the case of IPv6, I think what you are calling
"DS HG" is pretty much the same as what is called
"Enterprise Border Router (EBR)" and the CGN is pretty
much the same as what is called: "Enterprise Border
Gateway (EBG)" in VET ('draft-templin-autoconf-dhcp').
You could also check the diagrams in RANGER to see if
they satisfy your needs ('draft-templin-ranger').

The CPE people might also want to check VET, which is
really a superset of ISATAP.

Fred
[email-masked]

> From: Sheng Jiang [mailto:[email-masked]]
> Sent: Thursday, March 05, 2009 8:04 PM
> To: 'Dan Wing'
> Cc: 'IPv6 Operations'; [email-masked]; [email-masked]
> Subject: RE: draft-jiang-incremental-CGN-00
> 
> >> >>> -rw-rw-r--  1 fred  fred   30429 Nov  3 14:26
draft-chown-v6ops-
> >> >>> rogue-

---

From: Fred Baker <[email-masked]>
Date: Fri, 6 Mar 2009 08:25:52 -0800

On Mar 5, 2009, at 6:32 PM, Dan Wing wrote:

>> For sure. We know the draft name rules. When we wrote the  draft,  
>> we were not sure which WG it should be submitted. It seems relevant  
>> to both v6ops and behave.
>
> As a BEHAVE co-chair, I haven't seen a request for agenda time for  
> draft-jiang-incremental-CGN-00, nor any discussion about the draft  
> on the BEHAVE mailing list.

It may be that Brian asked me first. He was of the opinion that this  
is more operational in nature than about the specifics of the NAT  
operation, and I agreed to give it some air time. We'll see what  
happens to it.

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 6 Mar 2009 08:34:21 -0800

> >> we were not sure which WG it should be submitted. It seems 
> >> relevant to both v6ops and behave.
> >

That sounds fair.  BEHAVE certainly has enough on its plate already.

-d

---

From: Brian Carpenter <[email-masked]>
Date: Sat, 7 Mar 2009 08:26:23 +1300

Dan,

We're describing a scenario. Obviously, there are other similar
scenarios. That's
why v6ops seems like the obvious place for a first discussion, imho.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 6 Mar 2009 13:22:39 -0800

> From: Brian Carpenter [mailto:[email-masked]] 
> Sent: Friday, March 06, 2009 11:26 AM
> To: Dan Wing
> Cc: Sheng Jiang; IPv6 Operations; Brian Carpenter; [email-masked]
> Subject: Re: draft-jiang-incremental-CGN-00
> 
> Dan,
> 
> scenarios.

I had asked my question learn if there is benefit to have the ISP's 
NAT44 also terminate the IPv6-over-IPv4 tunnel.

> That's why v6ops seems like the obvious place for a 
> first discussion, imho.

I concur.

-d

> terminate
> >  > >>> -rw-rw-r--  1 fred  fred   43841 Oct 15 10:48 
> draft-ietf-v6ops-
> >  > >>> tunnel-
> >  > >>> security-concerns-
> >  > >>> 01.txt

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 6 Mar 2009 17:27:17 -0500

http://www.ietf.org/internet-drafts/draft-wbeebee-ipv6-cpe-router-04.txt

Sorry, we forgot that the -00 submission for I-D's was March 4th, 2009
and thus did not release a draft-ietf-v6ops-ipv6-cpe-router-00.txt.  As
folks may know this draft is a work item of the v6ops WG as of the
Minneapolis IETF during November 2008.  Soon as IETF opens up -00
submission again during the March IETF, we will submit the -00 version
of this draft.  We didn't want to wait any longer to release this new
version so that folks could get a few weeks of review before IETF 74.

Gross items taken care of in this version.

1. Added DS-Lite section to the draft.
2. Added text to cater to Brian Carpenter's comment that the CPE Rtr
should not hard code it's data forwarding table to existing 200::/3
prefix.
3. Added more explanatory text to strong host model portion of the
document to address question raised by Dave Thaler at the mike during
IETF 73.
4. Augmented the Abstract to cater to comments from the mike during IETF
73 as to how other task forces may use this document.
5. Added ND Proxy section catering to comments from Teemu.

Hemant & Wes

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 09 Mar 2009 10:51:35 +0800

Hi, Templin,

Yes, the mechanisms described in VET are possible to be used in our proposed
incremental v4/v6 transition CGN. We would mention it when we resubmit our draft
with v6ops in the draft name later. 

Many thanks and best regards,

Sheng

>From: Templin, Fred L [mailto:[email-masked]] 
>Sent: Saturday, March 07, 2009 12:02 AM
>To: Sheng Jiang; Dan Wing
>Cc: IPv6 Operations; [email-masked]; [email-masked]
>For the case of IPv6, I think what you are calling "DS HG" is 
>pretty much the same as what is called "Enterprise Border 
>Router (EBR)" and the CGN is pretty much the same as what is 
>called: "Enterprise Border Gateway (EBG)" in VET 
>('draft-templin-autoconf-dhcp').
>You could also check the diagrams in RANGER to see if they 
>satisfy your needs ('draft-templin-ranger').
>
>The CPE people might also want to check VET, which is really a 
>superset of ISATAP.
>
>Fred
>> >proposal is very much just a NAT44 ("CGN") and a 6-over-4 
>tunnel from 
>> >the in-home gateway to some device that terminates the 
>tunnel and has 
>> >IPv6 Internet connectivity.
>> >IPv4 service, but it might also be offered by someone else on the 
>> >Internet (as a separate service), in which case the
>> >6-over-4 tunnel might actually go *across* the service provider's 
>> >NAT44 ("CGN").
>> 
>> >> >draft name (individual submission to a named working 
>group), as it 
>> >> >is hard to keep track of work in a working group with individual 
>> >> >submission names.
>> >> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Mar 2009 09:47:46 +1300

Dan,

Sorry if my previous response was rather brief; I was supposed
to be on vacation for a couple of days.

Below..

> NAT44 also terminate the IPv6-over-IPv4 tunnel.

As Sheng suggested, the idea is operational convenience by combining
the two functions in one box.  I think we'd like to make IPv6 support
seem like an easy step for an ISP that has decided they have to deploy
NAT anyway. If you end up with all the specifics of a given subscriber
being handled by the same box, there should be operational and
administrative savings.

    Brian

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 12 Mar 2009 17:35:03 -0400

Thanks for this new draft. I have a few comments:
1. The statements around strong hosts in 5.3.2 are confusing to me.
 - I had to go searching for what a strong host is -- perhaps a
reference to RFC 1122 would be useful, if that is the right reference?
 - The statements in the current version (section 5.3.2) are: "The
Unnumbered model is incompatible with the strong host model on the CPE
router. The unnumbered model may be inappropriate for use with certain
deployments where a device that uses the strong host model can operate
as a CPE Router." It's not clear to me just what it is that's
incompatible vs. inappropriate. Could this be clarified a little?

2. Has any thought been given to the role a CPE router should play in
supporting a local domain name scheme? Most routers today do have their
own DNS function, and send their own IP address to LAN hosts as the DNS
server to use. Many people have said (in various places) how undesirable
it will be for people to have to type IPv6 addresses when they're
accessing a particular LAN host, and how nice it would be if all LAN
hosts could be accessed by URLs, with the CPE router providing
resolution. It's been suggested that some form of Dynamic DNS might be
used, for hosts to tell the CPE Router what name they want to use, and
the IP address(es) associated with that name. The problem is that many
forms of Dynamic DNS currently exist, so it isn't really "standard". It
would be nice if there were some standard recommendation for hosts to
create entries in the CPE router DNS function.

3. Please change "DSL Forum" to "Broadband Forum" in the Abstract.  

Thanks,
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Friday, March 06, 2009 5:27 PM
To: IPv6 Operations
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: Posted a new copy of CPE Rtr draft

Hemant & Wes

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 12 Mar 2009 18:02:45 -0400

-----Original Message-----
From: Stark, Barbara [mailto:[email-masked]] 
Sent: Thursday, March 12, 2009 5:35 PM
To: Hemant Singh (shemant); IPv6 Operations
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

<hs> 
If you scanned the archives of v6ops, the incompatibility has been
clarified. Anyway, here is a summary of what transpired and why this
text.  Some division of NTT ( I think its NTT West) in Japan uses a
Windows PC in the customer's home where the PC has some patch provided
by the SP to install on the PC and then this PC acts as a CPE Rtr.
These comments in our draft relate to such a deployment and Shin from
NTT asked us to add such a blurb in our draft.  Obviously suck hacked up
router code on Windows will have problems with strong vs. weak host
model.  We didn't want to go into any mode details with this text and
since Shin who raised this issue was fine with our text, we'd like to
leave it like that.
</hs>

2. Has any thought been given to the role a CPE router should play in
supporting a local domain name scheme? 

<hs> 
Even in one rev before this rev of the CPE Router, in section 8.6, we
have mentioned local DNS.
[For local DNS queries for configuration, the CPE Router may include a
DNS server to handle local queries.]
</hs>

Most routers today do have their own DNS function, and send their own IP
address to LAN hosts as the DNS server to use. Many people have said (in
various places) how undesirable it will be for people to have to type
IPv6 addresses when they're accessing a particular LAN host, and how
nice it would be if all LAN hosts could be accessed by URLs, with the
CPE router providing resolution. It's been suggested that some form of
Dynamic DNS might be used, for hosts to tell the CPE Router what name
they want to use, and the IP address(es) associated with that name. The
problem is that many forms of Dynamic DNS currently exist, so it isn't
really "standard". It would be nice if there were some standard
recommendation for hosts to create entries in the CPE router DNS
function.

<hs>
Will do - thanks for this correction.

Thanks for the review.

Hemant
</hs>

Thanks,
Barbara

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 16 Mar 2009 13:55:36 +0100

Hello,
        I have a question on section 5:
could you please explain why stateful DHCPv6 is the recommended method for assigning a global IPv6 address to the  WAN interface? Are you suggesting excluding the possibility to use SLAAC to number WAN interface?

Thanks,
Best Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Friday, March 06, 2009 11:27 PM
To: IPv6 Operations
Cc: Hemant Singh (shemant); Wes Beebee (wbeebee)
Subject: Posted a new copy of CPE Rtr draft

Hemant & Wes

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 16 Mar 2009 10:09:33 -0400

>could you please explain why stateful DHCPv6 is the recommended method
for assigning a global IPv6 address to the  WAN interface? Are you
suggesting >excluding the possibility to use SLAAC to number WAN
interface?

No, we are not at all suggesting that the WAN interface not acquire its
global IPv6 address using SLAAC. Either of SLAAC or stateful DHCPv6 is
fine for the WAN interface to acquire its global address with. We only
mandate stateful DHCPv6 if the CPE Rtr has to acquire an IA_PD option.
Please also note this sentence from section 5.

[Further, in the numbered model, we recommend the CPE Router WAN
interface acquire its global IPv6 address using stateful DHCPv6 for
administrative control of the router.]

A SP may want more administrative control of the CPE Rtr and DHCPv6
provides that.  

Hemant

---

From: Fred Baker <[email-masked]>
Date: Mon, 16 Mar 2009 11:22:42 -0700

On Mar 16, 2009, at 5:55 AM, Maglione Roberta wrote:

> could you please explain why stateful DHCPv6 is the recommended  
> method for assigning a global IPv6 address to the  WAN interface?  
> Are you suggesting excluding the possibility to use SLAAC to number  
> WAN interface?

I don't understand him to be *precluding* anything. However, I do  
believe that he is saying that an ISP generally has more to configure  
on a CPE router than the interface address; it will have the  
recommended DNS server, the prefix that the SOHO/Residence will subnet  
internally, if DS-Lite is in use it will have the necessary  
information to configure a tunnel, and so on. He is saying that if  
that is the case, one may as well get the interface address from the  
DHCP server as well.

I think the question before the house is whether the ISPs, such as  
Telecom Italia, agree with that viewpoint. Certainly you can *use*  
SLAAC in your network. Would you rather the specification *recommend*  
SLAAC? If so, do you have a recommendation regarding the other  
matters? Would you prefer that the document simply recommend that CPE  
equipment support both options?

I am not expressing an opinion here; I know of networks in which DHCP  
seems like a better choice and networks in which SLAAC is a perfectly  
reasonable solution. I think it is important that you - and other ISPs  
- state their opinions however.

---

From: Mark Smith <[email-masked]>
Date: Tue, 17 Mar 2009 07:08:58 +1030

On Mon, 16 Mar 2009 11:22:42 -0700

> - state their opinions however.

(not representing a ISP here, but work at one, and these
sorts of issues are some of the ones I have to worry about)

I think DHCP is the better option. The link to the customer's WAN
interface is the first customer unique or specific part of the
network connection, so having some non-upstream-router harder or hard
state in your management systems i.e. DHCP database, can make
troubleshooting and billing easier. It also encourages the model that
ISPs give out subnets to all customers (unless there is a PD option for
RAs that I'm not aware of), not end-node addresses.

Regards,
Mark.

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 17 Mar 2009 11:30:04 +0100

Hello,
   I agree with you on two aspects:
- in a broadband access environment the CPE router requires not only the IPv6 address but also additional configuration info like DNS, NTP and so on,  and I agree DHCP is a good tool to be used for this purpose.
- as SP, we need to have centralized administrative control of the CPE router both to centralize the prefix distribution and to simplify, as you pointed out, troubleshooting and billing procedures. My point is that the DHCP Server is not the only possible centralized point of our network. Today for IPv4 we can use AAA Radius server to store subscribers profile, thus moving to IPv6 one option could be to keep a similar approach and store IPv6 prefix in AAA radius server then use RADIUS attributes to influence DHCP tasks.

The difference I see between using SLAAC vs steful DHCPv6 to number WAN link comes in the picture if you consider both a scenario where there is a routed CPE and a scenario where there are hosts directly connected to the SP network (you can see this second case either like a migration step where some customers still have an old IPv4 only CPE that simply behaves as bridge for IPv6 connections or a Wimax access where there is no CPE.)  . When I use WAN numbered model I need to provide to my customer at least one IPv6 address for the WAN link and delegate a prefix to number the home network, from the AAA RADIUS perspective it would be desirable to use a common address allocation method in both scenarios described above. If I use SLAAC + DHCP-PD I do not need to know at the session set up time if my customer has a routed CPE thus that /64 is used to number the WAN link or if there is an host behind a legacy IPv4 only CPE thus that /64 is used to number the host interface. In both cases my AAA Radius Server will have a /64 for SLAAC and a /x (probably /56) for DHCP PD. In both scenarios DHCP stateless is still used to obtain other configuration parameters.

In my opinion even with SLAAC using AAA RADIUS you can achieve centralized administrative control. Any comments?
> Would you rather the specification *recommend* SLAAC? If so, do you have a recommendation regarding > the other matters? Would you prefer that the document simply recommend that CPE equipment support
> both options?
 I'm not saying one approach is better than other I was trying to understand the reasons behind the recommendation made in the draft. You may consider the scenario I described before out of scope, but I would prefer the document recommend that CPE equipment support both SLAAC and stateful DHCPv6.
Anyway I interesting in hearing both your comments and additional opinions.

Thanks,
Best Regards,
Roberta

-----Original Message-----
From: Mark Smith [mailto:[email-masked]]
Sent: Monday, March 16, 2009 9:39 PM
To: Fred Baker
Cc: Maglione Roberta; 'Hemant Singh (shemant)'; Wes Beebee (wbeebee); IPv6 Operations
Subject: Re: Posted a new copy of CPE Rtr draft

Regards,
Mark.

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 15:17:10 +0100

Hi,

Thank you for the revision. I read it trough and I have following comments/questions/nits:

- 5.3.1: I guess SLAAC can also be used to aquire global IPv6 address for WAN interface as said in 5.?

- After reading the document I was not completely certain what level of DHCPv6 server functionality it is envisioned to be implemented by CPE. In 5.5. it is said that CPE router can pass DNS server information to clients -> does this mean CPE router should have at least Stateless DHCPv6 server in order to serve these queries? Or alternatively, is it ok for CPE router to act as DHCPv6 relay and relay information requests to SP? Which way is preferred (MUST/SHOULD/MAY..)? I understand stateful DHCPv6 server functionality is a question mark still.

- You mention DNS64 in the document (8.6), do you envision CPE router could implement NAT64 as wall? I think NAT64 could be left out or just mentioned shortly - without going into details (so that completing this work would not pend on NAT64 work's progress), but how do you see?

- Last paragraph of 7 says "A route SHOULD be added..." and later:"... null route MAY be automatic.". Should it say "A _null_ route SHOULD be added"?  I was unclear which route should be added to prevent routing loops, or just a route.

- 7.1. In 3GPP case the /64 prefix is not only for LAN interfaces, but also for the WAN interface. Thus I'd rather say:".. across multiple LAN interfaces, possibly including WAN interfase as well, and the CPE router..". Then "..any two LAN interfaces.." -> "..any two interfaces..". And still later "..if any two disparate LAN interfaces..." -> "..if any two disparate interfaces..".

- 7.1. Says "..has more than multiple prefixes available.." should it just be:"..has multiple prefixes available.."?

- 10. introduces WAN_IP_ACQUIRE_TIMEOUT constant. I would like to see comment here that particular L2 specifications may override this constant with some other value, as this is L2 dependent. In some L2 mechanisms one can see right at the L2 setup whether it supports native IPv4/IPv6 and it can be detected quickly if the address family is available natively or not. Also in some cases where L2 is setup on-demand, there is no time to wait for this long timeouts (user may be waiting) but its better proceed quickly with tunnel setups. 

Best regards,

	Teemu

>[mailto:[email-masked]] On Behalf Of ext Hemant 
>Singh (shemant)
>Sent: 06 March, 2009 14:27
>To: IPv6 Operations
>Sorry, we forgot that the -00 submission for I-D's was March 
>4th, 2009 and thus did not release a 
>draft-ietf-v6ops-ipv6-cpe-router-00.txt.  As folks may know 
>this draft is a work item of the v6ops WG as of the 
>Minneapolis IETF during November 2008.  Soon as IETF opens up 
>-00 submission again during the March IETF, we will submit the 
>-00 version of this draft.  We didn't want to wait any longer 
>to release this new version so that folks could get a few 
>weeks of review before IETF 74.
>
>2. Added text to cater to Brian Carpenter's comment that the 
>CPE Rtr should not hard code it's data forwarding table to 
>existing 200::/3 prefix.
>3. Added more explanatory text to strong host model portion of 
>the document to address question raised by Dave Thaler at the 
>mike during IETF 73.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 20 Mar 2009 11:36:25 -0400

Teemu,

Thanks for the review.  Please see inline below between <hs> and </hs>.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 10:17 AM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

Hi,

Thank you for the revision. I read it trough and I have following
comments/questions/nits:

- 5.3.1: I guess SLAAC can also be used to aquire global IPv6 address
for WAN interface as said in 5.?

<hs>
Yes. We will fix the statement sentence in 5.3.1 for SLAAC.
</hs>

- After reading the document I was not completely certain what level of
DHCPv6 server functionality it is envisioned to be implemented by CPE.
In 5.5. it is said that CPE router can pass DNS server information to
clients -> does this mean CPE router should have at least Stateless
DHCPv6 server in order to serve these queries? Or alternatively, is it
ok for CPE router to act as DHCPv6 relay and relay information requests
to SP? Which way is preferred (MUST/SHOULD/MAY..)? I understand stateful
DHCPv6 server functionality is a question mark still.

<hs>
Yes, as you say, at least a stateless DHCPv6 server will be needed to
pass parameters like DNS IP to the clients in the home.  However, soon
as CPE Rtr supports cascading CPE Rtrs or the Rtr is sub-delegating more
PDs than what the SP gave to the Rtr, then the CPE Rtr has got to
support stateful DHCPv6 server - this is obvious.  A relay agent won't
suffice if multiple prefixes are delegated to LAN clients.
</hs>

- You mention DNS64 in the document (8.6), do you envision CPE router
could implement NAT64 as wall? I think NAT64 could be left out or just
mentioned shortly - without going into details (so that completing this
work would not pend on NAT64 work's progress), but how do you see?

<hs>
We have deliberately stayed away from NAT64 so far.  However, if a CGN
document says the CGN cannot support NA64 and the CPE Rtr must do so, we
are open to adding NAT64 to the CPE Rtr.
</hs>

- Last paragraph of 7 says "A route SHOULD be added..." and later:"...
null route MAY be automatic.". Should it say "A _null_ route SHOULD be
added"?  I was unclear which route should be added to prevent routing
loops, or just a route.

<hs>
It's the same null route.  We will make the text better as follows:

[Old text]
A route SHOULD be added to the routing table (to prevent routing loops)
that is lower priority than any route except the default route. The
choice to drop the packet or send an ICMPv6 Destination Unreachable to
the source address of the packet is implementation-dependent. The
installation of the null route MAY be automatic. 

[New text]
A null route SHOULD be added to the routing table (to prevent routing
loops) that is lower priority than any route except the default route.
The choice to drop the packet or send an ICMPv6 Destination Unreachable
to the source address of the packet is implementation-dependent. The
installation of this null route MAY be automatic.
</hs>

- 7.1. In 3GPP case the /64 prefix is not only for LAN interfaces, but
also for the WAN interface. Thus I'd rather say:".. across multiple LAN
interfaces, possibly including WAN interfase as well, and the CPE
router..". Then "..any two LAN interfaces.." -> "..any two
interfaces..". And still later "..if any two disparate LAN
interfaces..." -> "..if any two disparate interfaces..".

<hs>
Disagree. You are suggesting one implement ND Proxy between the WAN and
LAN interfaces.  For the CPE Rtr, the WAN and LAN interface(s) are two
different routing domains - if one can perform routing between domains,
why support ND Proxy?  We are also making the last sentence better in
section 7.1 as follows:

[Old text]
However, if the CPE Router has more than multiple prefixes available for
use on LAN interfaces(s), and still any two interfaces on the LAN have
disparate MAC layer, the CPE Router MUST NOT support ND Proxy.

[New text]
However, if the CPE Router has multiple prefixes available for use on
LAN interfaces(s), and still any two interfaces on the LAN have
disparate MAC layer, the CPE Router MUST NOT use ND Proxy between the
two interfaces.
</hs>

- 7.1. Says "..has more than multiple prefixes available.." should it
just be:"..has multiple prefixes available.."?

<hs>
Sure, we will fix the English.
</hs>

- 10. introduces WAN_IP_ACQUIRE_TIMEOUT constant. I would like to see
comment here that particular L2 specifications may override this
constant with some other value, as this is L2 dependent. In some L2
mechanisms one can see right at the L2 setup whether it supports native
IPv4/IPv6 and it can be detected quickly if the address family is
available natively or not. Also in some cases where L2 is setup
on-demand, there is no time to wait for this long timeouts (user may be
waiting) but its better proceed quickly with tunnel setups. 

<hs>
Sure thing.  A new line will be added to the definition as follows:

The default value of the WAN_IP_ACQUIRE_TIMEOUT can be overridden by
link-type specific documents.

Best Regards and thanks much.

Hemant & Wes.
</hs>

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 18:13:30 +0100

Thanks for quick reply, I was ok with other things than this one:

>- 7.1. In 3GPP case the /64 prefix is not only for LAN 
>interfaces, but also for the WAN interface. Thus I'd rather 
>say:".. across multiple LAN interfaces, possibly including WAN 
>interfase as well, and the CPE router..". Then "..any two LAN 
>interfaces.." -> "..any two interfaces..". And still later 
>"..if any two disparate LAN interfaces..." -> "..if any two 
>disparate interfaces..".
>
><hs>
>Disagree. You are suggesting one implement ND Proxy between 
>the WAN and LAN interfaces.  For the CPE Rtr, the WAN and LAN 
>interface(s) are two different routing domains - if one can 
>perform routing between domains, why support ND Proxy?  We are 
>also making the last sentence better in section 7.1 as follows:

Yes. That is what has to be done in the link types we have to support. I don't see any other way when there is just single /64 received from point-to-point WAN interface (in RA) which has to be enough for numbering the "CPE" itself and all the devices in Ethernet LAN behind. Please let me know if there is a better way.

Only alternative I see is to have NAT66 in CPE similar to IPv4 NAT we already have to share the single IPv4 address we get from operator.

It would be very nice if there would be DHCPv6 PD available for "CPE" to ask for prefixes for LAN, but unfortunately that is not always the case.

I think we discussed this in IETF#73 corridor, but I have forgotten details... So maybe I should write a link-type specific document, which would describe this behaviour (maybe corner-case from IETF point of view, but the most important use-case from my point of view)? After all, I guess it is better to describe it rather than have it just as implementation-specific design choice?

Best regards,

	Teemu (I will not be able to make the v6ops meeting as I have to be in shara BOF)

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Fri, 20 Mar 2009 13:36:48 -0400

Hmmm...  

I wonder, would ULA's on the LAN side suffice?  Or is this a zero-LAN
model?

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 1:14 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

>LAN interfaces.  For the CPE Rtr, the WAN and LAN
>interface(s) are two different routing domains - if one can perform 
>routing between domains, why support ND Proxy?  We are also making the 
>last sentence better in section 7.1 as follows:

Yes. That is what has to be done in the link types we have to support. I
don't see any other way when there is just single /64 received from
point-to-point WAN interface (in RA) which has to be enough for
numbering the "CPE" itself and all the devices in Ethernet LAN behind.
Please let me know if there is a better way.

Only alternative I see is to have NAT66 in CPE similar to IPv4 NAT we
already have to share the single IPv4 address we get from operator.

It would be very nice if there would be DHCPv6 PD available for "CPE" to
ask for prefixes for LAN, but unfortunately that is not always the case.

I think we discussed this in IETF#73 corridor, but I have forgotten
details... So maybe I should write a link-type specific document, which
would describe this behaviour (maybe corner-case from IETF point of
view, but the most important use-case from my point of view)? After all,
I guess it is better to describe it rather than have it just as
implementation-specific design choice?

Best regards,

	Teemu (I will not be able to make the v6ops meeting as I have to
be in shara BOF)

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 20 Mar 2009 13:38:55 -0400

Teemu,

If your SP does not dole out a PD to the CPE Rtr and as you say, your
common case is just one /64 doled out to the WAN interface with PPP.
Ok, so if your LAN interface(s) are assigned addresses using SLAAC,
since SLAAC needs a /64, how can you possibly use the WAN's /64 to
assign addresses to the LAN interface(s)?  It's not possible.  Yes, you
could run a DHCPv6 server in the device and then sub-delegate the /64.
Hopefully such a DHCPv6 server sub-delegation is legal in IPv6
standards...   

Alternatively, you can use ULA for the LAN and use the CPE Rtr as a
router between WAN and LAN and not have anything to do with ND Proxy.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 1:14 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

Best regards,

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 18:54:53 +0100

Hemant,

Well, the RFC4389 describes this functionality of sharing the prefix between WAN and LAN.

I don't see how the ULAs could be used for global communication by devices in LAN.

Best regards,

	Teemu

>From: ext Hemant Singh (shemant) [mailto:[email-masked]] 
>Sent: 20 March, 2009 10:39
>To: Savolainen Teemu (Nokia-D-MSW/Tampere); [email-masked]
>Cc: Wes Beebee (wbeebee)
>If your SP does not dole out a PD to the CPE Rtr and as you 
>say, your common case is just one /64 doled out to the WAN 
>interface with PPP.
>Ok, so if your LAN interface(s) are assigned addresses using 
>SLAAC, since SLAAC needs a /64, how can you possibly use the 
>WAN's /64 to assign addresses to the LAN interface(s)?  It's 
>not possible.  Yes, you could run a DHCPv6 server in the 
>device and then sub-delegate the /64.
>Alternatively, you can use ULA for the LAN and use the CPE Rtr 
>as a router between WAN and LAN and not have anything to do 
>with ND Proxy.
>
>Hemant
>
>interfaces, but 
>the WAN and 
>Yes. That is what has to be done in the link types we have to 
>support. I don't see any other way when there is just single 
>/64 received from point-to-point WAN interface (in RA) which 
>has to be enough for numbering the "CPE" itself and all the 
>devices in Ethernet LAN behind.
>Only alternative I see is to have NAT66 in CPE similar to IPv4 
>NAT we already have to share the single IPv4 address we get 
>from operator.
>
>It would be very nice if there would be DHCPv6 PD available 
>for "CPE" to ask for prefixes for LAN, but unfortunately that 
>is not always the case.
>
>I think we discussed this in IETF#73 corridor, but I have 
>forgotten details... So maybe I should write a link-type 
>specific document, which would describe this behaviour (maybe 
>corner-case from IETF point of view, but the most important 
>use-case from my point of view)? After all, I guess it is 
>better to describe it rather than have it just as

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 20 Mar 2009 14:05:31 -0400

Another alternative, might be for the router to allow the its owner to
put it in a bridged mode, instead of router mode. The "CPE router" could
still get its own IPv6 address from the WAN, as a host should. But all
devices in the LAN would effectively just be hosts off the WAN, and
there would be no real LAN. There would be no ULA either. The question
is whether the design of the WAN would limit the number of hosts that
could be given addresses across that one interface. If that were the
case, then this wouldn't work, and the CPE router would be forced to do
a NAT66.

In many ways, this case is very similar to that of the cascaded router
that isn't given a prefix.

I don't think this is a corner case.
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hemant Singh (shemant)
Sent: Friday, March 20, 2009 1:39 PM
To: [email-masked]; [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

Teemu,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 1:14 PM
To: Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

Best regards,

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625

---

From: <[email-masked]>
Date: Fri, 20 Mar 2009 19:15:27 +0100

Hi,

In the case I look the network allocates unique /64 for the PPP link, and thereby allows 2^64-1 or so addresses configured from that prefix (network reserves one address for the router on the SP side of the point-to-point link).

Do we have terminology issue here? You could indeed say all hosts configure IPv6 address from the prefix received via WAN interface, so from that point of view all these hosts are logically connected to WAN, although in reality they go trough the ND proxy device.

It cannot be bridged, as the link types are different (PPP and Ethernet), but proxied mode. 

Best regards,

	Teemu

>From: ext Stark, Barbara [mailto:[email-masked]] 
>Sent: 20 March, 2009 11:06
>To: Hemant Singh (shemant); Savolainen Teemu 
>(Nokia-D-MSW/Tampere); [email-masked]
>Cc: Wes Beebee (wbeebee)
>Another alternative, might be for the router to allow the its 
>owner to put it in a bridged mode, instead of router mode. The 
>"CPE router" could still get its own IPv6 address from the 
>WAN, as a host should. But all devices in the LAN would 
>effectively just be hosts off the WAN, and there would be no 
>real LAN. There would be no ULA either. The question is 
>whether the design of the WAN would limit the number of hosts 
>that could be given addresses across that one interface. If 
>that were the case, then this wouldn't work, and the CPE 
>router would be forced to do a NAT66.
>
>In many ways, this case is very similar to that of the 
>cascaded router that isn't given a prefix.
>
>[mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
>The information transmitted is intended only for the person or 
>entity to which it is addressed and may contain confidential, 
>proprietary, and/or privileged material. Any review, 
>retransmission, dissemination or other use of, or taking of 
>any action in reliance upon this information by persons or 
>entities other than the intended recipient is prohibited. If 
>you received this in error, please contact the sender and 
>delete the material from all computers. GA625
>
>
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Mar 2009 11:17:32 -0700

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Friday, March 20, 2009 10:14 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> devices in Ethernet LAN behind. Please let me know if there 
> is a better way.
> 
> Only alternative I see is to have NAT66 in CPE similar to 
> IPv4 NAT we already have to share the single IPv4 address we 
> get from operator.

I feel compelled to point out that 
draft-mrw-behave-nat66-02.txt, "IPv6-to-IPv6 Network Address 
Translation (NAT66)" does not share IPv6 addresses.

-d

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 20 Mar 2009 14:21:02 -0400

Right, Teemu.  What I was saying that if a /64 is allocated to the WAN,
then one cannot sub-delegate this /64 to the LAN interface(s) if the LAN
uses SLAAC because SLAAC has a MUST for /64 and sub-delegation would
have to go for a longer prefix.  Certainly, if no sub-delegation is
used, then as you say, use other addresses from the same prefix for LAN
- that is fine.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 20, 2009 2:15 PM
To: [email-masked]; Hemant Singh (shemant); [email-masked]
Cc: Wes Beebee (wbeebee)
Subject: RE: Posted a new copy of CPE Rtr draft

Hi,

In the case I look the network allocates unique /64 for the PPP link,
and thereby allows 2^64-1 or so addresses configured from that prefix
(network reserves one address for the router on the SP side of the
point-to-point link).

Do we have terminology issue here? You could indeed say all hosts
configure IPv6 address from the prefix received via WAN interface, so
from that point of view all these hosts are logically connected to WAN,
although in reality they go trough the ND proxy device.

It cannot be bridged, as the link types are different (PPP and
Ethernet), but proxied mode. 

Best regards,

	Teemu

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Mar 2009 11:22:49 -0700

> [mailto:[email-masked]] On Behalf Of Stark, Barbara
> Sent: Friday, March 20, 2009 11:06 AM
> To: Hemant Singh (shemant); [email-masked]; 
> [email-masked]
> Cc: Wes Beebee (wbeebee)

That would create a reliance on the ISP network for the in-home 
network to function.  It would be ashame if my security system,
IP-enabled television and Blu-Ray player, TiVo, NAS, etc., 
all break if the access link is down.

Perhaps to avoid that problem the router could get smarter and
hand out ULAs if it notices the WAN is down.  But that idea 
feels pretty fragile, too.

-d

> support. I
> for "CPE" to
> The information transmitted is intended only for the person 
> or entity to which it is addressed and may contain 
> confidential, proprietary, and/or privileged material. Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is 
> prohibited. If you received this in error, please contact the 
> sender and delete the material from all computers. GA625
> 
> 
>

---

From: Antonio Querubin <[email-masked]>
Date: Fri, 20 Mar 2009 08:39:50 -1000 (HST)

On Fri, 20 Mar 2009, [email-masked] wrote:

> Date: Fri, 20 Mar 2009 19:15:27 +0100 From: [email-masked] 
> To: [email-masked], [email-masked], [email-masked] Cc: 
> [email-masked] Subject: RE: Posted a new copy of CPE Rtr draft
> 
> Hi,
>

That assumes the WAN link is PPP.  However, it could be bridged ethernet, 
in which case the ND proxy seems the path of least resistance.

Antonio Querubin
whois:  AQ7-ARIN

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Mar 2009 11:58:03 +1300

> Thanks for the review.  Please see inline below between <hs> and </hs>.
...

> are open to adding NAT64 to the CPE Rtr.

I'd be very surprised to see a CGN document making such a statement.
The case you are suggesting is, I think, where the CPE has no path
to a NAT64 (either a NAT64 provided by the subscriber's ISP, built
into a CGN or not, or some NAT64 elsewehere). The scenario discussion
in BEHAVE may clarify this, but for now we can say nothing IMHO.

    Brian