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

[Brian E Carpenter <brc@zurich.ibm.com>]

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.

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.

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.


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.

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.

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?

    Brian

Internet-Drafts@ietf.org 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