Subject: Re: Draft on ISP broad-band deployment scenarios

From: Ciprian Popoviciu <[email-masked]>
Date: Wed, 01 Sep 2004 12:38:56 -0400

Pekka,

First we would like to thank you for the detailed comments and suggestions 
made on this draft. They are very appreciated!

Please find in line our response and questions. We are looking forward to 
your response.

Regards,
Chip

At 01:17 PM 8/24/2004 +0300, Pekka Savola wrote:
>Hi,
>
>Sorry for delay in sending in a few personal comments...
>
>On Thu, 19 Aug 2004, Pekka Savola wrote:
> > Adeel Ahmed, Ciprian Popoviciu, and Salman Asadullah from Cisco did a
> > lot of work in a very short time and produced a really extensive
> > scenarios document discussing the IPv6 deployment scenarios for
> > broadband (DSL, cable, etc.).
>
>A couple of general observations:
>
>  0) is the document aiming to only describe the scenarios, or is the
>goal to also provide analysis where potential gaps have been
>identified, and where e.g., a tunneling mechanism would be needed?  If
>the latter, it probably needs to be expanded a bit.

@@@
Pekka, to put this document in perspective, here are some elements of our 
original intent:
- focus on production type deployments. We did not intend to discuss tunneling
unless it is the only alternative currently available due to limitations of 
a given access
technology (cable).
- present the possible deployment scenarios and identify the major elements
for each one in terms of enabling IPv6 services.
- highlight changes that have to be made in the deployment process and some
issues that the SP has to keep in mind while planning such a deployment.

As you can see, the document is rather large as it is so we did not consider
going into more detail then we already did. We did want however to underline
topics that should be kept in mind during deployment, even items that should be
further investigated. We believe that this approach is what you mentioned above
but maybe we need to highlight more some aspects of the document. Could you 
clarify
your comment above so that we make sure we properly understand the changes you
suggest? We would like to make this work as useful as possible.
@@@

>  1) the doc seems to be lacking large-scale v6 enablement
>considerations, w/o customer interaction and manual config.  That is,
>at least in section 5, I got the impression that for the customer to
>enable v6 over a tunnel, the customer and the ISP would have to do
>some manual configuration.  This seems unscalable and unfeasible.
>Shouldn't we try to have mechanisms where the nodes automatically
>detect if IPv6 is available through a tunnel, and activate it if so?

@@@
This is a good point that we should elaborate on. It is also true that
while in some cases simple provisioning is available (use of autoconfig or
DHCP-PD) in others there might not be a solution available today. In such 
cases,
based on your comment above, it looks like you would like to see us clearly
identify such limitations and possibly open the door for further work. Is this
correct?

The tunnel case might be an unfortunate example as it might be a temporary 
solution
until an updated DOCSIS allows a more practical approach.
@@@

>  2) the document seems to make some assumptions e.g., when it specifies to
>use 6to4 e.g., for cable.  Are all of the networks using public v4
>addresses?  What if the customer has deployed a NAT box so that the public
>address is consumed by that box?  Further, I'm not sure whether the
>situation where the customer has deployed some equipment has been considered
>throughout the document.

@@@
Again, it is a case very specific to the current state of Cable access. 
Nevertheless
we could probably offer more detail for this case. For example, one 
solution would
be to have the box that is doing the NAT for the user also terminate the 
tunnel.

This is another point that we need to clarify however, the Gateway Router 
(GWR) can
be SP owned but also it can be customer owned and in that case it would 
reflect a
customer deployed equipment like a box that does NAT for v4.
@@@

>  3) there's duplicated text in very many of the sections which applies
>to about all the scenarios, for example:
>
>    Depending on the design of the edge portion of the ISP network, some
>    Edge Routers might have to run iBGP for IPv6. In this case it is
>    expected that two peer sessions are established between the Edge
>    Router and a pair of redundant Route Reflectors.
>
>.. instead of duplication, would there be a good logical place to put
>all the "generic considerations" wrt. access networks (e.g., about
>prefix summarization, etc.) into a dedicated section? -- And just
>describe the access-network -specific issues under the access
>network.. that might remove duplicate text and make the document more
>concise.
>
>This might force the reader to think about the generic issue and how they
>map to the specific access network scenario a bit more, but it would
>probably improve the readability and correctness.
>
>The tradeoff of course is that each access network description would no
>longer be readable on its own without reading the rest, but that should
>probably be acceptable ... as it is, there seems to be significant overlap
>with the sections, especially with DSL, Ethernet, and WLAN, but a bit
>otherwise as well.
>
>If that was done, it might be possible to push down from 60 pages to
>20-30 pages, and even increase the amount of unique content in the
>process.

@@@
Before writing the document we actually discussed this topic amongst 
ourselves. Our
thought is that some items might seem similar between sections but they 
might not be
in all their details. Moreover, we did want to provide each Access 
Technology section
a certain completeness and independence in order to make the sections more 
readable,
without having to send the reader very far through referencing. Even if we 
were to compress
the repeated subsections we doubt that the document will shrink to only 30 
pages.
We received pro and con arguments on this topic so for now we would like to 
keep it
in this format as it might even be easier to further flesh out some 
sections based on the
feedback received. As the document evolves we can revisit the formatting if 
it proves
advantageous.
@@@

>  4) the doc could probably include a summary section just before
>Acknowledgements (btw, Security Considerations section needs to be
>added), which could list action items for the IETF standardization (if
>any gaps were identified), or some other summary of issues which still
>need to be taken care of -- or is it just a matter of implementation
>and deployment? :-)

@@@
Agreed, good idea, we will work on this item.
@@@

>substantial
>-----------
>
>5.2.1 Deploying IPv6 in a Bridged CMTS Network
> 
>
> 
>
>    In IPv4 the CM and CMTS act as Layer-2 bridges and forward all data
>    traffic to/from the hosts and the ER. The hosts use the ER as their
>    Layer-3 next hop. If there is a GWR behind the CM it can acts as a
>    next hop for all hosts and forward data traffic to/from the ER.
>
>==> doesn't this seem in conflict with 5.2.1.3 which says that the equipment
>is doing a significant amount of snooping?  How much of this is required to
>support v6 bridging?  The doc should be very clear where this support is
>needed...
>
>[[ I wrote the below before I read 5.2.1.3:
>
>Do the bridged-mode cable modem systems use something like the
>bridged-mode DSL to make it look like that the customers share the LAN and
>are bridged, but actually aren't? (see draft-melsen-mac-forced-fwd-02.txt)
>
>If yes, that snooping functionality needs to be upgraded to v6.  If not,
>does that mean that all the ARP/ND traffic is flooded to everyone, and
>ARP/ND spoofing/hijacking is trivial?
>]]

@@@
We will add some clarification in where the snooping is applied. Your 
comment is valid, the
bridged-mode cable modem systems act similar to the bridged-mode DSL.
@@@

>semi-editorial
>--------------
>
>2. IPv6 Based BB Services
>
>
>    At this point IPv6 based services are seen as a differentiator
>    that enables SPs to take advantage of the large IPv6 address
>    space and allows them to better position themselves against the
>    competition. Another reason of IPv6 being very popular in some
>    countries is the government driven financial incentives and
>    favorable legislation to the ISPs who are deploying IPv6.
>
>==> one thing possibly worth mentioning here is that some ISPs might see
>IPv6 as a way to drive down customer support costs (I've heard this from one
>SP at least), because NATs which break apps and in general behave in strange
>ways would disappear.

@@@
Agreed, we will add this point.
@@@

>==> maybe add after this paragraph something along the lines:
>
>    Below, we illustrate a few deployed cases for IPv6-based BB services.
>    It is not an exhaustive list.

@@@
It would be worth pointing out that in this document we went not only for
describing some scenarios already deployed but also some that could be 
deployed.
We wanted to present as complete of a list as possible.
@@@

>...
>
>It should be noticed that
>    where a home user generally gets a single IPv4 address (dynamic
>    or static), the IPv6 service provides a full subnet (/64).

@@@
We will underline this point even thought it might be apparent from the 
addressing sections.
@@@

>==> actually, the current recommendation (RFC 3177) is even larger: a /48
>per home :-).  This should probably be mentioned..

@@@
True. We sort of touched on that with our DHCP-PD recommendations. There 
are also
SPs that might assign prefixes between /48 and /64 with the intent of charging
for address space.
@@@

>    2. IPv4 Cable (HFC) Network, GWR at customer site
> 
>
> 
>
>    In this case the cable network, including the CM and CMTS remain
>    IPv4 devices. The host, GWR and ER are upgraded to dual-stack. This
>    scenario is also easy to deploy since the cable operator just needs
>    to add GWR at the customer's site.
>
>==> is this necessarily this simple?  What is the cable operator already has
>deployed v4-only GWR for other purposes?  Does it need to be upgraded to
>dual-stack?  Or what if the user has added a box of its own, e.g., a
>firewall/NAT/wireless router?  I guess it again needs to be upgraded.

@@@
These are deployment issues that we could elaborate a bit more on. The 
provider usually
is not responsible for the additional equipment added by the customer and 
under the
constraints of a service deployment that is limited by the current state of 
DOCSIS it is likely that
the provider will have to provide a new device to the subscriber. We will 
add a note on this
topic.
@@@

>   4. Dual-stacked Cable (HFC) Network, Standalone GWR and CMTS support
>       IPv6
> 
>
> 
>
>    In this scenario there is a standalone GWR connected to the CM.
>    Since the IPv6 functionality exists on the GWR the CM does not need
>    to be dual-stack. The  CMTS is upgraded to dual-stack and it can
>    incorporate the ER functionality. This scenario may also require HW
>    and SW changes on the GWR and CMTS.
>
>==> I don't really understand the cable architecture very well, so this may
>be an obvious point .. but I don't see how just upgrading GWR and CMTS could
>be enough, if the CM doesn't support v6?  Does that require some sort of
>tunneling, or..?  But in that case, v6 support shouldn't be needed in CMTS
>in the first place?

@@@
The CM will still be a Layer 2 bridge and will bridge IPv4 and IPv6 
traffic. Therefore the CM
does NOT need to support IPv6. Changes to the DOCSIS specification will 
need to be made
in order for the CM to support IPv6 unicast and multicast traffic.
@@@

>5.2.2.2.4 Routing
> 
>
>    For 6to4 tunneling,a static 2002::/16 route and a default IPv6 route
>    can be manually configured on the GWR with the IPv6 address of the ER
>    as the next hop. A similar IPv6 route will need to be configured on
>    the ER pointing back to the GWR at customer site.
>
>==> does that require manual configuration at ER for each customer?
>Hopefully not! (AFAICS, there's nothing needed for 6to4, but manual
>tunneling would need it.)

@@@
We will discuss provisioning in more detail and hopefully this question 
will be answered in
that context. It is worthwhile to note that we don't advocate the use of a 
specific tunneling
mechanism for this temporary solution for Cable Networks. We will more 
clearly identify
items to be considered when making the selection for the tunnel but the 
selection will
be left to the person planning the deployment.
@@@

>    If using maunual tunneling, the GWR and ER can use static routing or
>    they can also configure RIP-ng. The RIP-ng updates can be transported
>    over a manual tunnel, which does not work when using 6to4 tunneling.
>
>==> is there a particular usage case for RIP-ng over cable modem to the GWR?
>I can't see any valid scenario for doing so....

@@@
This is a valid point. We need to provide more context to the statement, 
but it is worthwhile
to note that it is a current practice in IPV4 networks where business 
customer do run RIPv2
between the CM/GWR and the CMTS. Those customer routes are redistributed in 
the ISP's IGP.
@@@

>    The CMTS/ER should protect the ISP network and the other subscribers
>    against attacks by one of its own customers. For this reason uRPF and
>    ACLs should be used on all interfaces facing subscribers. Filtering
>    should be implemented with regard for the operational requirements of
>    IPv6 (ICMPv6 types).
>
>==> I don't understand what you mean by the last sentence?

@@@
We probably used too few words. We wanted to say that while configuring IPv6
ACLs, one has to make sure that the ACLs do not stop IPv6 specific controll
plane traffic (like ND, DHCP-PD etc).
@@@

>5.2.2.5.4 Routing
> 
>
> 
>
>    The CM/GWR can use a static defaul route pointing to the CMTS/ER or
>    it can run a routing procotol such as RIP-ng or OSPFv3 between itself
>    and the CMTS. Customer routes from behind the CM/GWR can be carried
>    to the CMTS using routing updates.
>
>==> are there really any customers or ISPs which would be allowing running a
>dynamic routing protocol across the cable modem fabric?  I'd be surprised to
>see this...

@@@
Same comment as above.
@@@

>    In IPv6, with [RFC3306] there is a better mechanism available for ASM
>    IPv6 address allocation than in IPv4. This reduces the problems of
>    using ASM in IPv6 to some degree. On the other hand, the protocol MSDP
>    standard with PIM-SM is not currently defined for IPv6. In general,
>    SSM for IPv6 is also considered to be the protocol to promote for the
>    majority of future interdomain IP multicast applications and it is
>    less complex solution to operate.
>
>==> you might want to check out and refer to
>draft-ietf-mboned-ipv6-multicast-issues-00.txt which discusses exactly this
>issue, and solutions if you'd still need ASM.

@@@
Yes, we are aware of this work and we will reference it. We didn't really
want to get into a model other then SSM despite the fact that there are 
feasible
ways for ASM. The idea was that SPs will be more inclined to go for an SSM 
model
at first (maybe even on a longer run) because of the business model of content
delivery (video/audio). Probably we should however have a discussion on the 
topic.
Do you see the ASM discussion important beyond referencing the draft you 
mentioned?
@@@

>6.2.1 POINT-TO-POINT MODEL
> 
>
>==> this model has the built-in assumption that ATM is used as
>point-to-point.  Is this strictly necessary, or could you just use any other
>media as well?

@@@
Could you please clarify this comment?
@@@

>    If a Customer Router is present:
>
>[...]
>    - it dynamically acquires through autoconfiguration the address for the
>    link between itself and the Edge Router. This step is followed by a
>    DHCP-PD [RFC 3633] request for a prefix shorter then /64 that in turn is
>    divided in /64s and assigned to its interfaces connecting the hosts on
>    the customer site.
>
>==> s/present/present, either:/
>
>==> the router doesn't autoconfigure the address unless it has been
>configured to act as a host on its upstream interface... which would
>probably be bad practice.. so either the upstream link has no global
>addresses (which would be OK), or it could just use a subnet from the
>DHCP-PD prefix.

@@@
Why would you see it as a bad practice having the router acquire via stateless
autoconfig an address for the uplink to the provider? We should probably 
discuss
all options for completeness purposes.
@@@

>    MLD authentication, authorization and accounting is usually
>    configured on the edge router in order to enable the ISP to do
>    controll the subbscriber access of the service and do billing for
>    the content provided.
>
>==> the non-standardized methods for adding AAA to IGMP/MLD have been
>proposed, but they're generally considered very broken models, and I'm not
>sure how much text we should have about them, at least without disclaimers.
>The right thing to do would probably be to encrypt the data, and provide the
>decryption key only to those who pay (or whatever for the stream.

@@@
We believe that such a feature is important to all SPs that deploy mcast 
services
for video and audio streaming. Maybe this is not critical at the start of 
the service
but would be when the service offering solidifies. Such a feature offers more
granularity in controlling and charging a customer then the key proposal. 
With the key
proposal the user would have access to possibly a predefined package of 
channels while
with proper MLD AAA the user can select any channel, any time and be 
charged only for
that use.
@@@

>9. Acknowledgements
>
>==> would it be appropriate to refer to the earlier work by C. Mickles et
>al., here?  Depends on how much it has influenced your work, I guess..

@@@
We referenced this work repeatedly in the draft and that in itself would 
suggest that
it would be good to recognize the authors in the acknowledgments section. 
Good point.
@@@

@@@
We will include all editorial comments you made below.
@@@

>editorial
>---------
>
>==> some lines go over the maximum of 72 chars/line
>
>==> you should spell out the acronyms when they're first used like "Service
>Provider (SP)".
>
>==> there are a couple of non-ascii characters, like the apostrophe in
>"IPv6's" in the second paragraph of section 1, in 2nd para of sect 2, etc.
>
>    that are currently deployed, and discussed in this draft.  In this
>
>==> s/draft/memo/ (also later in section 3, and later on)
>[[ "memo" is a more generic term which also applies when/if a draft becomes
>RFC ]]
>
>    For instance in Japan, Cable TV and dish services are not very
>
>==> s/Cable/where Cable/
>
>    Provider's network namely Cable/HFC, BB Ethernet, xDSL and WLAN.
>
>==> s/network/network,/
>
>    This drafts briefly discusses the other elements of a provider's
>
>==> s/drafts/memo/
>
>   Following important pieces such as:
>
>==> reword to something like: "We'll consider at least the following
>important steps:" ?
>
>    IPv6 deployment is signficant.
> 
>
>==> s/sign/signi/
>
>    A. IPv6 Tunneling: As a temporrary solution, the Access Provider can
>
>==> s/rrary/rary/
>
>    least impact on the Access Provider network however it is not suitable
>
>==> s/however/, however,/
>
>    C. MPLS 6PE Deployment: If the Access Provider is running MPLS in its
>    IPv4 core it could use 6PE to forward IPv6 traffic over its MPLS core.
>
>==> add reference to the 6PE draft?
>
>    In an IPv4 routed CMTS network the CM still acts as a Layer-2
>    device and bridges all data traffic between its Ethernet interface
>    and cable interface
>
>==> the line ended abruptly, is something missing or was this just an
>unnecessary line break?
>
>   When deploying IPv6 in a routed CMTS network, the CM will still acts
>
>==> remove "will" or s/acts/act/
>
>    In this scenario the CMTS isupgraded to dual-stack to support IPv4
>
>==> s/is/is /
>
>           _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>         ()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
>                          6to4 tunnel
>
>==> s/6to4/IPv6-over-IPv4/ (to be more generic..?)
>
>    messges on its downstream interface which will be used by the hosts to
>
>==> s/mess/messa/
>
>     In this case the cable operator can offer IPv6 services to it's
>
>==> s/it's/its/ (similar elsewhere)
>
>    The CM/GWR can use a static defaul route pointing to the CMTS/ER or
>
>==> s/defaul/default/
>
>    enhance security. The Privacy extenssions for autoconfiguration should
>
>==> s/extens/exten/
>
>    valid customer controll traffic such as: Router and Neighbor
>
>==> s/controll/control/
>
>    Router for that subsrciber's PVC. The hosts can use stateless or
>
>==>s/rc/cr/
>
>    DHCP-PD should be planned in a maner that allows as much summarization
>
>==> s/maner/manner/
>
>    should be planned in a maner that allows maximu summarization BRAS.
> 
>
>==> same here, + s/maximu/maximum/
>
>[[there were a large number of other typos I didn't correct, as a lot
>of them were duplicated across the document]]
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Tue, 7 Sep 2004 14:43:04 +0300 (EEST)

Sorry for the delay in responding.. inline...

(I've removed some comments which we seemed to agree or be clear 
about.)

> unless it is the only alternative currently available due to limitations of 

OK, though I'm not sure how certain types of tunneling solutions could
not be considered "production" (or sufficiently near that) to be
useful on a larger scale.  The justification for that is that there
may be lots of equipment that is not IPv6-capable, and having to wait
for it to be replaced to be able to offer (or get) IPv6 connectivity
may be a big assumption for deployment.

> suggest? We would like to make this work as useful as possible.

This is partially clarified later in this message, esp. point 1) 
below.

The question I was asking was whether you intended to analyze the
applicability of different methods for getting IPv6 connectivity (in
case there would be multiple: for example, where you cite 6to4, there
could very likely be others as well, possibly even more suitable than
that), or just pick one (or none) and describe how that would work.  
In other words, I was interested whether you were considering
"generic" deployment (with as few assumptions as reasonable, about,
e.g., equipment at the customer's premises), or "specific" deployment
(where you could or could not assume some things, like being able to
upgrade a certain box or having public IPv4 addresses).

The document would certainly seem to be most useful if it was
sufficiently "generic", but a "specific" document is also better than
nothing ;-), provided that the assumptions are very clearly spelled
out.

> identify such limitations and possibly open the door for further work. Is this

Yes -- I don't see it as a problem that a document idenitifies gaps or 
room for further work.  That's good, because at least some folks 
already have their own view on what's needed, and by writing it down 
we can discuss and get (hopefully!) agreement on what's needed.

Note that there has already been work in progress in some of these 
areas (see, for example, 
http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt).

> Again, it is a case very specific to the current state of Cable

Do you mean that cable operators are widely offering a public IP 
address per customer?  However, I'd venture to guess there are a 
significant number of operators which only give private addresses to 
begin with.

> Nevertheless we could probably offer more detail for this
> case. For example, one solution would be to have the box that is
> doing the NAT for the user also terminate the tunnel.
> 
> This is another point that we need to clarify however, the Gateway
> Router (GWR) can be SP owned but also it can be customer owned and
> in that case it would reflect a customer deployed equipment like a
> box that does NAT for v4.
> @@@

Exactly, this cuts both ways: one approach could be to assume that the
NAT box (which may be beyond the control of the SP) is upgraded --
this could take quite a long time to achieve.  Another approach could
be to provide mechanisms which work irrespective of NATs -- there are
already a plenty of those, for example Teredo, and some others
probably to come (think of "configured tunneling over UDP with
keepalives"), in one form or the other.

I think what you were assuming that you only need to care about the
case of upgrading the NAT box.  That may be acceptable with certain
assumptions about the deployment (if that's the case, they must be
very clearly spelled out), but it may not be sufficient in more
general -- so if you agree that one would want to provide v6 access
also when there are NATs or other obstacles in the way, one such
approach is to specify v6 connectivity mechanissm which work through a
NAT.

> ourselves. Our thought is that some items might seem similar between
> sections but they might not be in all their details. Moreover, we
> did want to provide each Access Technology section a certain
> completeness and independence in order to make the sections more
> readable, without having to send the reader very far through
> referencing. Even if we were to compress the repeated subsections we
> doubt that the document will shrink to only 30 pages. We received
> pro and con arguments on this topic so for now we would like to keep
> it in this format as it might even be easier to further flesh out
> some sections based on the feedback received. As the document
> evolves we can revisit the formatting if it proves advantageous.
> @@@

Would there be some kind of middle-path, e.g., a section describing 
more generic considerations which are actually common to all the 
access networks (or close enough)?  I'm a bit afraid of the scenario 
where we'd have to include identical text in 5 different sections if 
we figured out we needed to add some common text :)

But if you believe this is sufficient at this point, I can live with
it.  I've just seen (in the past) a lot of work getting spent in
keeping the text in sync, and I wanted to avoid that if possible.

> SPs that might assign prefixes between /48 and /64 with the intent of charging

Yes, seems inevitable -- but let's just hope they'd still give at
least /64 or something like that, instead of /128's.

> the provider will have to provide a new device to the subscriber. We will 

This is one approach, as noted at the start of the message; another is 
providing tunneling support.  Both could be feasible, depending on 
deployment, but the latter is more generic at least.

> be left to the person planning the deployment.

OK --  Analyzing the different mechanisms is fine.  However, if it 
requires IETF specification, there must be some document that makes 
the decision what needs to be specified (if not everything).  It 
doesn't need to be in this doc, though.  (This was my point zero at 
the start of the message -- whether this doc was intended to 
include analysis, and if so, how much of it...)

> between the CM/GWR and the CMTS. Those customer routes are redistributed in 

OK -- I'm just having trouble visualizing any ISP doing so, because 
that might directly jeopardize their IGP to the customers.. and I'd be 
interested in hearing why they would be doing something like this (is 
this some kind of backup routing plan for some SOHO customers or the 
like or what).

> plane traffic (like ND, DHCP-PD etc).

I'd hope that folks wouldn't filter ICMPv6 at all, but that's probably 
too much to hope for.. remember, you cannot use e.g., 'ping' for host 
scanning purposes as you have about  2^64 potential hosts in a 
subnet...

> Do you see the ASM discussion important beyond referencing the draft you 

Well, ASM is what's used (or actually, not being widely used :) today, 
so it's a bit surprising to see it waved off just like that.. I guess 
it would be OK to mention ASM more briefly, and refer to possible 
solutions, but concentrate on SSM (and state the reasons for doing so, 
i.e., the easier business model for content delivery).

> Could you please clarify this comment?

I meant that wouldn't it be possible to use e.g., Ethernet (instead of 
ATM) as the point-to-point uplink?  I haven't seen this myself, but 
I've heard reports of such deployments..

> all options for completeness purposes.

Well, if you have a router, I'd generally expect it to act as a router
on all of its interfaces.  There has been some debate of this mixed
"host/router" behaviour on IPv6 WG list before, but I think the
conclusion has been that mixed host/router is acceptable by the specs
at least.  I'd however personally rather see that the routers in these
situations would have other means to configure an address (if they
need one).

> We believe that such a feature is important to all SPs that deploy
> mcast services for video and audio streaming. Maybe this is not
> critical at the start of the service but would be when the service
> offering solidifies. Such a feature offers more granularity in
> controlling and charging a customer then the key proposal.  With the
> key proposal the user would have access to possibly a predefined
> package of channels while with proper MLD AAA the user can select
> any channel, any time and be charged only for that use.
> @@@

These arguments should maybe go in the draft, but still keep in mind
that MLD/IGMP have not been meant to authenticate the users.

I'd expect that the same features can be obtained with encrypted data.  
You would get the key which would be valid only for some time from a 
web server, and that key would be only valid for a certain stream.  
That way you could get the keys etc. only only those parts of the 
transmission you'd want.  There are possibly other approaches.  MSEC 
(http://www.ietf.org/html.charters/msec-charter.html) WG has been 
looking at this problem.

---

From: Adeel Ahmed <[email-masked]>
Date: Fri, 10 Sep 2004 18:00:17 -0500

Hello Pekka,

Please see my responses inline with +++++++++++++++:

>may be a big assumption for deployment.

+++++++++++++++
Our goal in this draft is to get SPs to move towards deployment of native 
IPv6. So
leading to such deployments tunneling would be a stepping stone for the SPs.
However, considering that there are native deployments today, we wanted to 
focus more
on them rather then on the transitional phase in which it might be rather 
difficult for an SP
to generate revenue from a tunnel based service till they move towards 
native IPv6 deployments.

In the case of Cable (section 5) we had to talk about tunnels due to the 
current limitations in
DOCSIS but all the other access technologies discussed in the draft are 
ready for native IPv6
deployment today.
+++++++++++++++

>nothing ;-), provided that the assumptions are very clearly spelled

+++++++++++++++
We've actually tried to be specific in sections 6,7 & 8. We've used kind of 
a generic
approach in section 5 due to the current state of cable networks and the 
limitations in
DOCSIS. We will try to spell out some of the assumptions more clearly in 
our next revision
of the draft.
+++++++++++++++

>significant number of operators which only give private addresses to

+++++++++++++++
Actually that is a common practice with most Cable Operators. We've worked 
with major
Cable providers in the America, EMEA and APAC regions and they all offer public
IP addresses to their customers.
+++++++++++++++

>approach is to specify v6 connectivity mechanissm which work through a

+++++++++++++++
That's a good point, we will make a note of that in section 5 where we 
discuss initiating a tunnel from
the host. Since our goal is to provide IPv6 access natively this should not 
be an issue for other technologies.
+++++++++++++++

>keeping the text in sync, and I wanted to avoid that if possible.

+++++++++++++++
Your point is well taken. For now we would like to keep the format as it is 
to maintain consistency among
different sections. We can revisit this issue in the future.
+++++++++++++++

>deployment, but the latter is more generic at least.

+++++++++++++++
Right, so cable operators currently do provide a GWR which is managed by 
them. In order
to deploy IPv6 the operator can upgrade or replace this GWR with a v6 
capable device.
+++++++++++++++

>include analysis, and if so, how much of it...)

+++++++++++++++
We do understand your point. We will try to address this in our next 
revision of the draft.
+++++++++++++++

>this some kind of backup routing plan for some SOHO customers or the

+++++++++++++++
This is currently a normal practice for Cable Operator's business customers.
There are only a handful of these customer routes which are summarized and
redistributed into the Cable Operator's IGP. This is not really meant for 
residential
customers which account for majority of the customer base.
+++++++++++++++

>i.e., the easier business model for content delivery).

+++++++++++++++
Sure, we can do that in the next revision of the draft.
+++++++++++++++

>I've heard reports of such deployments..

+++++++++++++++
We've discussed this in the FTTH section 7.2.1. So we did not really assume 
that only
ATM will be used as a point-to-point uplink.
+++++++++++++++

>situations would have other means to configure an address (if they

+++++++++++++++
We've seen customer interest in using this approach for IPv6 therefore we 
discuss it in the draft.
Similar approach is also available in IPv4.
+++++++++++++++

>(http://www.ietf.org/html.charters/msec-charter.html) WG has been

+++++++++++++++
We do realize that there are multiple ways of doing this but we went with
MLD authentication approach because we have seen requirements for this
from customers and it's a rather simple approach.

But we will try to add more explanation in the next revision of the draft.
+++++++++++++++

Kind Regards,
Adeel Ahmed.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Sep 2004 09:58:49 +0300 (EEST)

Hi,

Sorry for not getting back to this earlier :-(.. inline..

On Fri, 10 Sep 2004, Adeel Ahmed wrote:
> Our goal in this draft is to get SPs to move towards deployment of
> native IPv6. So leading to such deployments tunneling would be a
> stepping stone for the SPs. However, considering that there are
> native deployments today, we wanted to focus more on them rather
> then on the transitional phase in which it might be rather difficult
> for an SP to generate revenue from a tunnel based service till they
> move towards native IPv6 deployments.

There are native deployments today, but AFAIK they have been 
relatively small scale (thousands of users).

The crux is whether the ISP wants to (try to) offer service to *all*
of its customers, requiring no hardware upgrades or purchases, with no
assumptions about what the user has deployed -- or just those which
are OK the assumptions, upgrades/purchases, etc.

I'm concerned that if we focus too much on "native only", only
(relatively) few users will likely be able to get the service.

It's true that it may be difficult for an ISP to generate revenue out 
of e.g., tunneling based service, offered to anyone, but if some ISP's 
are still interested in this kind of approach, would it be worth 
considering?
 
> In the case of Cable (section 5) we had to talk about tunnels due to
> the current limitations in DOCSIS but all the other access
> technologies discussed in the draft are ready for native IPv6
> deployment today. 
> +++++++++++++++

The approach depends on the ISP's strategy.  If it wants to offer 
services to just those which have the right kind of set-up, no 
interfering NAT boxes, their own wireless routers, or whatever, that's 
fine.  But I'm quite concerned about making such assumptions, because 
in practice that implies that the deployment gets much more difficult 
and demanding (also due to need for financial justifications) for the 
users.

> We've actually tried to be specific in sections 6,7 & 8. We've used
> kind of a generic approach in section 5 due to the current state of
> cable networks and the limitations in DOCSIS. We will try to spell
> out some of the assumptions more clearly in our next revision of the
> draft. 
> +++++++++++++++

OK.  Please also state clearly the caveats of "native only, if 
technologically possible" approach (discussed above, for example).

> Actually that is a common practice with most Cable
> Operators. We've worked with major Cable providers in the America,
> EMEA and APAC regions and they all offer public IP addresses to
> their customers. 
> +++++++++++++++

OK, please make this assumption and justification explicit in the 
document.

> >approach is to specify v6 connectivity mechanissm which work through a

OK.
 
> >deployment, but the latter is more generic at least.

Right.  But my practical concern is that if it costs the ISP XXX XXX $ 
to replace the GWR's with ipv6-supporting versions, but XXXX $ (XXX 
XXX >> XXXX) to provide tunneling support, I'd guess most ISPs would 
be interested in going for tunneling first, and just looking at 
replacing GWR's based on their natural EOL schedule.

> >this some kind of backup routing plan for some SOHO customers or the

But what I don't understand is why the business customers would 1)  
need dynamic routing in the first place (what is the actual reason for
using a routing protocol?), and 2) would want to use something as
"unreliable" (with some definition of unreliable) as Cable, instead of
DSL, Serial, Ethernet.
 
> that only ATM will be used as a point-to-point uplink.
> +++++++++++++++

But couldn't you provide ADSL (instead of FTTH or Ethernet to the 
home) using Ethernet or something like HomePNA on the uplink instead 
of ATM?

I don't know enough of the deployments to be able to say whether "ADSL
with Ethernet-like uplink" and "FTTH" are synonymous, but if I had to
venture a guess, I'd say there's probably some difference there.

> >situations would have other means to configure an address (if they

Please state explicitly that this is takes a mixed host/router 
approach to ND.

> >(http://www.ietf.org/html.charters/msec-charter.html) WG has been

Thanks.  Justification and listing the caveats is good.

---

From: Salman Asadullah <[email-masked]>
Date: Thu, 23 Sep 2004 14:56:15 -0700

Hello Pekka,

Please see our response below between &&&.

>are still interested in this kind of approach, would it be worth

&&&
This is true but we have observed many of the BB ISPs are interested in 
deploying native IPv6, driven by new services such as VoD using Multicast 
and etc.  Some of the examples for these BB ISPs, who are deploying IPv6 
are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in 
France, XS4ALL in The Netherlands and etc.

Our intent in this draft is to the make the worldwide BB ISP community 
aware of possible options available to deploy IPv6 natively today.

We agree that for some ISPs the native IPv6 solution would not be feasible 
due to several reasons as you mentioned previously, with the information 
provided in our draft, some ISPs might realize that the extra investment 
for a native deployment might make sense for their long term 
goals.  Besides, for some countries this might be a viable option, think of 
Japan, Korea and some other countries where the ISPs are getting tax cuts 
from the government, if they deploy IPv6.
&&&

>technologically possible" approach (discussed above, for example).

&&&
Sure. Will do.
&&&

>OK, please make this assumption and justification explicit in the

&&&
Sure. Will do.
&&&

>replacing GWR's based on their natural EOL schedule.

&&&
You are correct, the first step in some cases will be tunneling (for 
example cable).

But in other cases BB ISPs are taking the next step and inclined more 
towards the native deployments

Also the extra cost might be justified by the:

- Services provided and charges ($$ earned) over IPv6 like VoD, video 
streaming, IPT and etc.
- Tax cuts received by the governments for IPv6 deployments
- and etc.
&&&

>using a routing protocol?),

&&&
The cable business customers in todays world get a /27 or something 
similar.  The issue is how does the CMTS keep track of which business 
customer owns that particular /27 and how does it get advertised to the 
rest of the world.  One way to do this is to use static routing but the 
problem is that if the cable modem goes down, the CMTS will end up black 
holing that traffic and vise versa, thus requiring an IGP. There are 
several reasons of using RIPv2, out of which a simple one is that there are 
hardly any CM/GWR which support OSPF.

Today's cable deployments uses this, so we had to discuss it in the draft 
to make it close to reality.  The BB ISP will use RIPng as they were using 
RIPv2. We felt this explanation is out of the scope of this document so we 
did not include.
&&&

>and 2) would want to use something as

&&&
Sure, there are pros and cons with every technology.  If you ask me 
personally, I prefer Cable over DSL :-)
&&&

>venture a guess, I'd say there's probably some difference there.

&&&
Sure. We'll investigate some of the differences.
&&&

>Please state explicitly that this is takes a mixed host/router

&&&
Sure. Will do.
&&&

>Thanks. Justification and listing the caveats is good.

&&&
And thanks for your time and continuos valuable feedback :-)
&&&

Regards,
Salman Asadullah
Technical Leader
Cisco Systems, Inc.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 24 Sep 2004 10:32:22 +0300 (EEST)

Inline...

> France, XS4ALL in The Netherlands and etc.

Sure.  But do these ISPs use a link-layer which supports multicast,
e.g., bridged-mode DSL (I think it does..)?

That is, if you do something like L2TPoE (which I think many are 
doing), doesn't that require that multicast transmission be 
duplicated (on a lower layer) in any case, causing equal amount of 
traffic as a tunneling based distribution?
 
> from the government, if they deploy IPv6.

Extra investment is always possible, and many will certainly do it.  
The question is just how the ISPs would transition from "v4-only" to 
"v4+v6 natively".  My argument is that it would be easier for the ISPs 
to start with tunneling and native v6 where possible, than to require 
through-out upgrade to native v6.

That would reduce the number of up-front investment requirement, but 
would not prevent from making the investment when it's clear that 
there will be demand for the service.

That would also make it more lucrative to the customers whcih have 
boxes that don't support v6.  They wouldn't have to upgrade 
immediately to get that service..

> - Tax cuts received by the governments for IPv6 deployments

See above.  I think all services which are available over native v6 
can be offered, at least initially, through tunneled v6.  If it's 
still possible to get the service profits, and reduce the amount of 
initial investment, why wouldn't the ISPs do it?

> hardly any CM/GWR which support OSPF.

But the point is, unless those business customers have backup
connectivity, over which they also use the same IGP, the packets will
be discarded in any case, so it doesn't seem to matter whether static
routing does it whether they are discarded due to lack of a route.

The only difference (unless the business is multihomed, and I think
you said only few were) is whether the CMTS sends back an ICMP
unreachable message to the hosts trying to connect to the business,
before it discards the actual packet. That doesn't seem worth the
cost & complexity.

Further, putting an IGP there will allow business customers to hijack
any addresses w/ appropriate prefix advertisements, practically
requiring duplicating the ACLs at the CMTS side to allow only the
valid prefix.  But with the same trouble you could do a static route.
 
> RIPv2. We felt this explanation is out of the scope of this document so we 

It's OK to say they use RIPv2 and thus RIPng seems applicable, but it
seems also justified to point the discussion above, that routing
protocol is not needed unless you're multihomed or you care a lot
about sending ICMP unreachables when the link goes down.  It's also
worth noting the filtering requirement for the routing protocol, to
prevent hijacking.

---

From: Salman Asadullah <[email-masked]>
Date: Fri, 24 Sep 2004 17:09:17 -0700

Hello Pekka,

Please see my response between &&&.

>traffic as a tunneling based distribution?

&&&
Well, some might go for L2TPoE but not necessarily. We discussed that 
option for the sake of completeness and in case some SPs really, really 
like that model but .... if they do go for L2TPoE then yes, they will not 
gain much new. On the other hand we talked about the alternatives where the 
IPv6 traffic is routed while the IPv4 is still L2TPoE. That is for example 
the case of one of the biggest BB ISP who are providing IPv6 commercial 
services, where IPv4 is L2TP but IPv6 is routed. They did that for the very 
reason as they wanted to deploy mcast over it (what you referring to).
&&&

>immediately to get that service..

&&&
Ahh ....

We totally agree on this and finally understand where you are coming from :-)

In order to achieve the above and make this document complete and 
beneficial for all, we should include the tunneling options as well for 
remaining environment, FTTH, DSL and Wireless.  Tunnelling options for 
Cable is already discussed (off course we have noted all the comments and 
feedback which we will address in the next revision of the document).

So, we think we would need couple of more things:

1. A general summary section up front stating the intent of the document 
and available deployment options (tunneling and native).
2. Add a general tunneling section for FTTH, DSL and Wireless sections as 
another option. We believe this section would be general since we can 
simply talk about the different tunnelling solutions available and reasons 
of choosing one or the other and point the reader to the respective tunnel 
draft/rfc for details.

This will make the document complete with both options available in one 
place for all the BB ISPs.  Depending on what stage the BB ISPs are, they 
can chose whatever they want.

Does this sounds like a good plan ?
&&&

>initial investment, why wouldn't the ISPs do it?

&&&
Sure. Agreed upon.
&&&

>worth noting the filtering requirement for the routing protocol, to

&&&
Sure. We will incorporate both options in the next revision.

Another point to note that in last mile BB environment dual/multi-homed 
scenarios are hard to find.  Cable ISPs use dynamic routing since they find 
it much more convenient.  If they have to configure couple of hundred 
static routes at each CMTS, in large deployments, it adds up and becomes 
hard to manage.  Again, this is how it is done out there.
&&&

This has been a great discussion which clarified lot of points and 
hopefully will make this document to be very beneficial in years to come.

We would like to thank you and all the individuals on the list for their 
interest and valuable feedback (we have received several unicast replies 
with good points and valuable feedback).

We will integrate all the feedback in the next revision.

Regards,
Salman Asadullah
Technical Leader
Cisco Systems, Inc.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 27 Sep 2004 12:17:52 +0300 (EEST)

> reason as they wanted to deploy mcast over it (what you referring to).

Right.  This consideration wrt. multicast might be worth spelling out 
somewhere.

> We totally agree on this and finally understand where you are coming

Great :)
 
> Does this sounds like a good plan ?

Sounds like a good approach.  Note that the choice probably also
depends a lot on what the BB ISP thinks their customers' status (and
willingness) wrt.  IPv6 support is.  If the customers employ a lot of
NAT boxes or similar, they might have to take these scenarios into
account as well, and provide a tunnel service to those people.

> We will integrate all the feedback in the next revision.

Thanks!