Subject: Re: I-D ACTION:draft-asadullah-v6ops-bb-deployment-scenarios-00.txt

From: Ciprian Popoviciu <[email-masked]>
Date: Wed, 01 Sep 2004 15:27:02 -0400

Brian,

Thank you for your comments and suggestions. Please find in line our 
answers, clarifications and questions. We are looking forward to your 
response and suggestions.

Regards,
Chip

At 05:10 PM 8/26/2004 +0200, Brian E Carpenter wrote:
>Just a few quick comments on this very long document, which I
>think fills a need (though whether it should be an RFC, or
>expanded into a book, I'm not quite sure).
>
>1) I think I disagree with one comment Pekka made, about the
>same material being repeated in several sections. I think each of the
>major sections should be complete in itself, to avoid complex cross-
>references.
>
>2) Here's a comment that I think applies to all four scenarios described.
>The case of subscribers that get more than a /64, actually a /48 if
>RFC 3177 is followed, is not described, unless I missed it. This may only
>apply to a minority of subscribers initially, but it must certainly
>be covered.

@@@
We touched on this subject partially when mentioning the use of DHCP-PD
used to assign /48 to customer premises routers. We are planning to
add more information on this topic so this comment will be integrated
in the next iteration.
@@@

>3) Just an observation: the document implies in all scenarios that GWR
>vendors will update their products to be fully dual stacked. I can only
>agree that is highly desirable, but you are asking for quite a lot.

@@@
This is true but our intent was to look forward to large scale deployments
where IPv6 is more then a service. We argued that the user can simply get
connectivity through dual stack PCs that talk to the SP edge access equipment
however, on the long run the users and providers will drive the CPE 
manufacturers
to get the GWR ready for dual stack use.
@@@

>4) Section 5.2.2.1.3
>
>>5.2.2.1.3 Data Forwarding
>>
>>    All IPv6 traffic will be sent to/from the ER and the host device. 
>> In    order to transport IPv6 packets over the cable operator's 
>> IPv4    network, the host and the ER will need to use tunneling 
>> mechanisms    such as 6to4 tunneling [RFC 3056].
>>
>>    The host will use its global IPv4 address to source the tunnel to 
>> the    ER.
>
>So, as Pekka also pointed out I think, you are assuming global IPv4
>addresses at this level. What about countries that are already running
>multiple levels of NAT in order to reach local ISPs? 6to4 is broken in
>that case. Also, you don't explain how the 6to4 relay is discovered -
>do you assume the anycast trick is used (RFC 3068)? And incidentally it
>means that all such hosts will have 6to4 prefixes, so baroque routing
>is likely. 6to4 was designed to *bypass* local ISPs without IPv6 support,
>not to *help* them.

@@@
Our intent was to describe non-tunnel based deployments but rather 
deployments similar
to the IPv4 ones. The cable access case study is special because of the current
state of DOCSIS. This is the reason why tunnels were used here. That being
said, based on the comments we received, it is clear that we need to expand 
a bit
more on the topic and provide some clarifications. We will make some 
additions and
keep in mind the point raised by this comment.
@@@

>5) Section 5.2.2.2
>
>>    The cable operator can provide IPv6 services to its customers, 
>> in    this scenario, by adding a GWR behind the CM. Since the GWR 
>> will    facilitate all IPv6 traffic to/from the host and the ER, the 
>> cable    network including the CM and CMTS do not need to support IPv6 
>> and    can remain IPv4 devices.
>
>But this also has to work when the subscriber goes to the local
>electronics store and buys $99 Wireless Access Gateway, without the
>cable operator lifting a finger. Incidentally, in this case, if
>you use 6to4, the GWR will have to be a full RFC 3056 6to4 router,
>but the hosts behind the GWR don't need to know anything about 6to4.

@@@
True, this falls a bit in the topic of who owns the GWR. Yes, having the GWR do
the 6to4 tunneling is one of the ways to deal with having a single globally
routable IPv4 address that might be used with NAT for existent v4 
connectivity.
We will elaborate on the topic since it was brought up in other feedback we 
received.
@@@

>6) Section 7.5
>
>>    The NAP can stop IPv6 traffic from customer that did not subscribe 
>> to    the service by using layer two filters based on the IPv6 
>> Ethertype    (0X86DD).
>
>I think this is irrelevant - it isn't related to a security threat. It's
>also getting into business model territory, which we try to
>avoid in the IETF.

@@@
In a bridged network, wouldn't this be useful as a means for an access 
provider to
keep its network IPv6 free if it so decides?
@@@

>7) Section 10, References
>
>You mention RFC 3056 in the text, but it isn't listed. Also, as noted above,
>do you also need a reference to RFC 3068?

@@@
Noted, we will make the necessary corrections.
@@@

>     Brian
>
>[email-masked] wrote:
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>
>>         Title           : ISP IPv6 Deployment Scenarios in Broadband 
>> Access Networks
>>         Author(s)       : S. Asadullah, et al.
>>         Filename        : 
>> draft-asadullah-v6ops-bb-deployment-scenarios-00.txt
>>         Pages           : 0
>>         Date            : 2004-8-18
>>
>>This document provides detailed description of IPv6 deployment 
>>and    integration methods and scenarios in today's Service Provider 
>>(SP)    Broadband (BB) networks in coexistance with deployed IPv4 services.
>>    Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB 
>> technologies    that are currently deployed, and discussed in this 
>> draft.  In this    document we will discuss main components of IPv6 BB 
>> networks and    their differences from IPv4 BB networks and how IPv6 is 
>> deployed    and integrated in each of these BB technologies.
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-00.txt

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Sep 2004 09:57:02 +0200

Just one follow up:

>> 6) Section 7.5
>>
>>>    The NAP can stop IPv6 traffic from customer that did not subscribe to
>>>    the service by using layer two filters based on the IPv6 Ethertype
>>>    (0X86DD).
>>
>>
> In a bridged network, wouldn't this be useful as a means for an access provider to

Well yes, but equally if it wants to keep its network free of Novell IPX or
Appletalk over Ethernet or any other Ethertype. I really don't see why
the IETF should advise providers how to *block* IPv6 specifically. This is
a document about how to support IPv6. Maybe you should turn it round:

   If any layer two filters for Ethertypes are in place, the NAP must
   permit the IPv6 Ethertype (0X86DD).

    Brian

Ciprian Popoviciu wrote:
> said, based on the comments we received, it is clear that we need to 
> expand a bit
>>> cable    network including the CM and CMTS do not need to support 
>>> IPv6 and    can remain IPv4 devices.
>>
>>
> We will elaborate on the topic since it was brought up in other feedback 
> we received.
> @@@
> 
>> 6) Section 7.5
>>
>>> This document provides detailed description of IPv6 deployment and    
>>> integration methods and scenarios in today's Service Provider (SP)    
>>> Broadband (BB) networks in coexistance with deployed IPv4 services.
>>> draft.  In this    document we will discuss main components of IPv6 
>>> BB networks and    their differences from IPv4 BB networks and how 
>>> IPv6 is deployed    and integrated in each of these BB technologies.

---

From: Adeel Ahmed <[email-masked]>
Date: Fri, 10 Sep 2004 16:22:58 -0500

Hello Brian,

Please see my comments in line:

>   permit the IPv6 Ethertype (0X86DD).

That's a very good point. We will make this change in the next revision of 
the draft.

Thanks for all your help !

Kind Regards,
Adeel.

>>>> networks and    their differences from IPv4 BB networks and how IPv6 
>>>> is deployed    and integrated in each of these BB technologies.