[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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

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