On Fri, 21 Jan 2005, Pekka Savola wrote:
"ISP IPv6 Deployment Scenarios in Broadband Access Networks"
http://www.ietf.org/internet-drafts/draft-asadullah-v6ops-bb-deployment-scenarios-02.txt
Please say what you think. Silence DOES NOT indicate consent. If new
work items are to be adopted, there must be active support for doing it,
and there must be people willing to review and work on the draft.
The deadline for comments is in 2 weeks, on February 4th.
(personal comments, without any hats, of course)
First, I'd like to thank the authors for this important work. I support
this being taken as WG item and moved forward.
I'll note that I've personally felt that the document would be better split
to separate documents, but WG participants felt otherwise, so it's OK
because this was not a big issue for me as long as the document is kept
consistent.
I also thought that it would be useful to merge some text in a "generic"
section, which the other sections could then refer and add to if
necessary. There was also some pushback for this, but because I feel this
is important, let me try to state this again:
a) subsctions "Multicast, QoS, Security Considerations and Network
Management" are 95% common across all the scenarios and could be better put
in one "Generic" section, and referred to and expanded in the
scenario-specific sections.
b) Some parts of different deployment models could possibly be put in such a
generic section. This is a much trickier to get right, of course.. but in
"Addressing" and "Routing" subsubsections there is a lot of common text.
Maybe a) at least is worth considering?
substantial
-----------
0) I've sent some comments off-list; the most important of them was that
there is some work needed especially with DSL RBE-like approach to provide
means for sane bulk DSL usage. Currently you have to configure each
interface for each customer separately, instead of using a template. This
will require an implementation modification to generate a RA prefix based
on the VLAN or PVC id. This should be discussed in the memo.
1) Many different scenarios talk about dual-stacking (or not) of the edge
router. Is it sufficiently clear in the text that if the SP so desires, it
can use separate edge routers for v4 and v6?
2) One thing that struct me that is missing as an access network is HomePNA
(sigh). I don't think this is a major deployment model though, so it's OK
to leave it out as well. I think it is basically the same as Ethernet,
except Instead of access swithch, you have a HomePNA switch. I don't know
to which degree those would need to be IPv6-aware; probably not at all
unless one would want it to snoop multicast.
3) The draft refers extensively to draft-mickles-v6ops-isp-cases-05.txt
(probably at my badly worded suggestion), which is not going to be
published. So, you should not depend on text in that document -- everything
that should be known by the reader should be available here. However, it is
still a good idea to keep the reference still in the Acknowledgements
section.
4) In WLAN scenario, the document should probably talk a bit about host
authentication at hotspots. If done with 802.11x, then this probably needs
little with Ipv6. If done with web redirection, those services obviously
would need to support IPv6 hijacking as well...
semi-editorial
--------------
B. Native IPv6 Deployment: The Access Provider routers are upgraded
to support IPv6 and can become dual-stack. In a dual-stack network
an IPv6 IGP such as OSPFv3 or IS-IS is enabled, usually mapping the
IGP deployed for IPv4. The most important thing to remember in this
case is that the device resources are now shared between IPv4 and
IPv6 processes. This problem could be elimnated with the use of
ISIS-MT (multi-topology) where a single database and SPF is used for
IPv4 and IPv6.
==> the last part of the sentence is slightly inaccurate, and potentially
confusing. As this has been discussed extensively in the soon-to-be-RFC,
maybe th ewhole discussion of which IGP to select and what thay might imply
should be just referred to the other document?
The native approach has the advantage of supporting IPv6
multicast traffic but it implies a significant impact on the IPv4
operational network from software, configuration and possibly
hardware upgrade perspective.
==> s/implies/may imply/ -- whether this is the case depends a lot on your
hardware, your current status of software, etc.!
multicast or not), routing protocols used (GRE is the only tunnel
type which can transport layer 2 messages as well), manage-ability
and scalability (dynamic versus static tunnels).
==> well, I guess in principle you could do L2TP as well, so being 100%
accurate, the statement about GRE is not entirely true. Minor tweaking?
Some of the factors that hinder deployment of native IPv6 in current
cable networks include:
==> it is not 100% clear which of these apply in the bridged cmts model, and
which in the routed cmts model. Clarify.
A. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. These
devices rely on IGMP join messages to track membership of hosts that
are part of a particular IP Multicast group. In order to support ND
the CM and CMTS will need to support IGMPv3/MLDv2 snooping.
==> the last sentence is not entirely true. For ND, you just need MLDv1
snooping, though MLDv2 would be preferable for SSM support. But as said,
you only need MLDv1 .. and that only in those devices which actually would
otherwise block the v6 multicasts..?
C. Changes need to be made to the DOCSIS specification to include
support for IPv6 on the CM and CMTS. This is imperative for
deploying native IPv6 over cable networks.
==> this is not clear. The only reason I could think of is to be able to
manage CM/CMTS over v6, which seems hardly imperative, so there must be
something else. Clarify?
6.2.1.2.2 IP Addressing for Hosts
If there is no GWR connected to the CM, all the hosts behind the CM
will belong to the same /64 subnet that is assigned using stateless
auto-configuration or DHCPv6.
==> this is slightly confusing, because if DHCPv6 is used, these hosts don't
need to belong ti the same subnet? Actually, I would prefer tailing down
this paragraph, as the next ones more accurately describe the situation.
.2.1.3 Data Forwarding
The CM and CMTS must be able to bridge native IPv6 unicast and
multicast traffic. The CMTS must provide IP connectivity between
hosts attached to CMs and must do so in a way that meets the
expectation of Ethernet attached customer equipment. In order to do
that, the CMTS must either forward Neighbor Discovery (ND) packets
or provide a proxy ND service.
==> the good question to ask here would be, "why wouldn't you then enable
IPv6 on CMTS? instead of proxying?" This requires no changes to _DOCSIS_
part of CMTS -- just that it implements basic v6 router functionality..
(in many places)
Communication between hosts behind different CMs is always forwarded
by the CMTS.
==> as the CMTS is layer 2 (right?) maybe this should be "forwarded
through" or "bridged through" ?
In order to support IPv6 multicast applications across DOCSIS cable
networks, the CM and bridging CMTS need to support IGMPv3/MLDv2
snooping. MLD is identical to IGMP in IPv4, only the name and numbers
are changed.
==> I'd reword the latter sentence to like, "MLD is almost identical to IGMP
in IPv4". (many places)
6.2.1.4 Routing
The hosts install a default route that points to the ER or the GWR.
No routing protocols are needed on these devices which have
limited resources. If there is a GWR present it will also use static
default route to the ER.
==> I suggest removing "on these devices which have limited resources".
That is pretty subjective. The same under all the scenarios.
==> further, in these sections, I'd be a bit more informative about how
exactly the default route is configured. Typically learned from DHCPv4, I'd
guess.
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 site.
==> easy to deploy, but also typically unfeasible to deploy :-/... because
this requires investment and deployment/maintance of/on a new IPv6-capable
GWR. For larger deployments, this would probably be a non-starter, and it
might be better to try to either to tunnel to hosts directly (cheaper ;-),
or just dual-stack the existing box.
6.2.2.1.2 Addressing
The only device that needs to be assigned an IPv6 address at customer
site is the host. Host address assignment can be done statically as
there is no mechanism to transport ND messages or DHCPv6 messages
over the IPv4 cable network.
==> As you're suggesting using tunneling here, I'd suspect getting IPv6
addresses is tunneling mechanism specific; depending on the mechanism, this
might be automatic or it might require manual configuration.
The host will use its IPv4 address to source the tunnel to the
ER. All IPv6 traffic will be forwarded to the ER, encapsulated in
IPv4 packets. The intermediate IPv4 nodes will forward this traffic
as regular IPv4 packets. The ER will need to terminate the tunnel
and/or provide other IPV6 services [for example 6to4 relay, tunnel
broker etc.].
==> see the substantial issue above -- is it clear enough that the tunnel
box need not be the (v4) ER?. s/IPV6/IPv6/, and remove the stuff in []'s.
The GWR will use its global IPv4 address to source the tunnel to
the ER. The tunnel endpoint will be the IPv4 global address of the
ER. All IPv6 traffic will be forwarded to the ER, encapsulated in
IPv4 packets. The intermediate IPv4 nodes will forward this traffic
as regular IPv4 packets. In case of 6to4 tunneling, the ER will need
to support 6to4 relay functionality in order to provide IPV6
Internet connectivity to the GWR and hence the hosts connected to the
GWR.
==> "global address" is assumptive of deployment, and see the comment above
on service support on ER..
If using manual tunneling, the GWR and ER can use static routing or
they can also configure RIPng. The RIPng updates can be transported
over a manual tunnel, which does not work when using 6to4 tunneling.
Customer routes can be carried to the ER using RIPng updates. The ER
can advertise these routes in its IGP. Prefix summarization should be
done at the ER.
==> this is the only section that still mentions RIPng, and it should IMHO
be removed. Really. :-)
6.2.2.3.1 IPv6 Related Infrastructure Changes
Since the CM still acts as a Layer-2 bridge, it does not need to
be dual-stack. The CM will need to support bridging of IPv6 unicast
and multicast traffic and IGMPv3/MLDv2 snooping which requires
changes in the DOCSIS specification.
==> as said before, MLDv2 snooping is not a strict requirement :)
The hosts can receive their IPv6 address via DHCPv6 with the CMTS
acting as a DHCPv6 relay agent. If address assignment on hosts is
done via stateless autoconfiguration,
==> this is phrased in an odd way. I'd say that the assumption is that
statless address autoconfiguration is used almost always, and DHCPv6 is the
exception (except when you delegate a prefix.) This applies to all the
access types, and could use maybe switching the order of sentences and
tuning the text a bit. (In many places..)
If using DHCPv6 the CMTS will need to act as DHCPv6 relay agent. The
host and CM/GWR will receive IPv6 addresses from pools of /64
prefixes configured on the DHCPv6 server. The CMTS will need to glean
pertinent information from the DHCP Offer messages, sent from the
DHCP server to the DHCP clients (host and CM/GWR), much like it does
today in DHCPv4. All CM/GWR connected to the same cable interface on
the CMTS belong to same /64 prefix. The hosts connected to the same
cable interface on the CMTS may belong to different /64 prefixes as
the CMTS will have multiple /64 prefixes configured under its cable
interfaces.
==> I'm not sure what to make of this, due to the different assumption above
about the usage of DHCPv6.
Currently the DHCP-PD functionality cannot be
implemented if the DHCP-PD server is not the Edge Router. If the
DHCP-PD messages are relayed, the Edge Router does not have a
mechanism to learn the assigned prefixes and thus install the proper
routes to make that prefix reachable. Work is being done to address
this issue, one idea being to provide the Edge Router with a snooping
mechanism.
==> it is worth considering, however, whether a solution is *really* needed
here (maybe this problem could be shorter in the sections, and longer in the
gap analysis). I mean, why would one even want to have DHCPv6 server
somewhere else? It's nicely fate-sharing with the service if it's at ER,
and using Radius you can separate the user policy from the server. The only
point is that if the ER does not offer DHCPv6 functionality, but in that
case, I'd be doubtful if it offered this snooping hack either...
6.2.2.5.4 Routing
The CM/GWR can use a static default route pointing to the CMTS/ER or
it can run a routing protocol 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.
If DHCP-PD is used for address assignment a static route is
automatically installed on the CMTS/ER for each delegated /48 prefix.
The static routes need to be redistributed into the IGP at the
CMTS/ER so there is no need for a routing protocol between the
CMTS/ER and the GWR.
==> the end of 1st para is RIPng fragment and should be removed IMHO. In any
case, this seems to be conflicting with the end of the 2nd paragraph :)
ASM is however an option that is
discussed in section 7.3.1. The "SSM safe reporting" problem for IPv4
does not exist in IPv6 multicast because the use of SSM in IPv6 is
well defined and uses un-contentious address ranges.
==> I'm not sure what you mean by "SSM safe reporting", so it would be good
if you could add a reference here.
The CM, GWR and
CMTS/ER will need to be enabled with PIM-SSM, which requires the
definition and support for IGMPv3/MLDv2 snooping, in order to track
join/leave messages from the hosts. The Layer 3 next hop for the
hosts support MLD.
==> this appears to be slightly mixed up. If CM acts as a bridge, it won't
need any support for PIM-SSM. Likely CM does not even need MLD snooping
because it should probably just pass everything through (depending on
whether non-joined flooded multicast traffic in the ethernet segment is
considered a problem or not).
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).
==> spell out and refer to uRPF (e.g., RFC3704).
==> spell out what exactly you mean with the latter. It seems you are
vaguely saying "you should figure out which kind of ACLs are OK, in
particular, which ICMPv6 types are really needed and should not be
filtered". This is rather vague, though I'm not sure whether this is the
right place to specify what to filter or not...
DSL Modem: It can be a stand alone device, it can be incorporated
in the host, and it can incorporate router functionalities.
Customer Premises Router: It is used to provide layer 3 services
for customer premises networks. It is usually use to provide
firewalling functions and segment broadcast domains for a Small
business.
==> maybe it would be worth saying that VERY often, DSL modem includes the
capbility to act as CPE router (whether it does or not is a matter of
configuration, i.e., whether it runs in bridged or routed mode).
C. Terminate the PVC at layer 3, each PVC has its own prefix. This is
the approach that seems more suitable for IPv6 and presented in 7.2.1
In none of these cases the CPE (DSL Modem) has to be upgraded.
==> you're assumingi that the CPE would not have router functionalities, but
would be just a bridge, yes?
B. It dynamically acquires through stateless 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.
==> the first sentence is interesting, and there were already comments about
this. Maybe this should be put last in this paragraph with a bit of
rewording. Actually, there is nothing requiring the router to do this
stuff.. it can run DHCPv6 very well without a global address in its upstream
interface! So, AFAIK, the whole suggestion could be removed, but if it
isn't, it should be put in proper perspective. (In very many places..)
The Edge Router has a /64 prefix configured for each subscriber VLAN.
==> in a couple of places, you talked about PVCs, and some others, VLANs.
Maybe synch the terminology a bit?
7.2.3.1 IPv6 Related Infrastructure Changes
In this scenario the BRAS is layer-3 aware and it has to be upgraded
to support IPv6.
==> it was not clear to me why in this case it is required to update BRAS.
You know, at least based on the figures, the PPP sessions go straight
through it, and it shouldn't be knowing anything about v6.. or...?
This allows the ERs
(LNSs) to aggregate the addresses handed out to the customers. In the
case of IPv6, an important constraint that likely will be enforced is
that the customer should keep its own address regardless of the ER
(LNS) it connects to. This could significantly reduce the prefix
aggregation capabilities of the ER (LNS).
==> this seems to have the hidden assumption that v6 addresses/prefixes will
be stable, while v4 addresses are currently dynamic. I welcome that
situation personally, but if you describe this as an issue, you probably
should spell out this assumption about different deployment models.
In some cases service providers manage equipment located on
customers LANs.
==> this appears to be mentioned a couple of times, and is IMHO redundant
and out of scope for this draft. If you really really want to say
something, maybe at most "The management of equipment at customers' LANs is
out of scope of this memo."
WLAN enables subscribers to connect to the Internet from various
locations without the restriction of staying indoors. WLAN is
standardized by IEEE 802.11x.
==> the last sentence is wrong, maybe the wrong letter? 11x is just the
authentication part of it..
offers maximum transmission speed from 1 or 2 Mbps, IEEE 802.11b
offers 11 Mbps and IEEE 802.11a offers up to 54 Mbps.
==> maybe mention 11g as well, because that's getting pretty popular at the
expense of 11a..
C. Section 7 stated that current RBE based IPv4 deployment might not
be the best approach for IPv6. The addressing space available gives
the SP the opportunity to separate the users on different subnets.
If however, support is found for a deployment similar to IPv4,
and if the SP chooses to let subscribers talk amongst themselves
directly, then special consideration should be give to the ND
operation at the Edge Router.
==> this should probably be a bit clearer what is the gap here, and what
would need more work.
editorial
---------
As the number of devices per BB users increase exponentially
==> s/users/user/ ?
range [RFC 3513] of IPv6. Other benefits of IPV6 include the
==> s/IPV6/IPv6/
IPv6 where possible. Deployment of tunneling solutions are simpler,
easier and more economical to start the IPv6 services, as they
==> s/are/is/ ?
At this point IPv6 based services are seen as a differentiator that
...
this year for its ADSL and FTTH subscribers, under the name of ...
network and at this point does not provide connectivity to the
==> when this doc ages, 'this' may no longer be accurate.
The Access Provider can deploy a Layer2 network and perform no
==> s/Layer2/Layer 2/ ?
core can involve various technologies such as Ethernet, ATM and etc.
==> remove "and" ?
C. MPLS 6PE Deployment [6PE]: If the Access Provider is running MPLS
in its IPv4 core it could use 6PE to forward IPv6 traffic over its.
In this case only a subset of routers close to the edge of the
network needs to be IPv6 aware. With this approach BGP becomes
important in order to support 6PE. Its deployment will most likely
leverage the Route Reflector structure used with the IPv4 deployment.
==> the last sentence seems to be out of scope for this draft, and maybe
should be removed?
is planed. As an example, 6to4 tunnels do not support IPv6 multicast
==> s/planed/planned/
1. Bridged CMTS Network
In this scenario, both the CM and CMTS bridge all data traffic.
Traffic to/from host devices is forwarded through the cable network
to the ER. The ER then routes traffic through the ISP network to the
Internet. The CM and CMTS support some Layer-3 functionality for
management purposes.
==> would it be easy to indent paragraphs like this by a couple of spaces
(would increase the readability a lot)
==> s/some/a certain degree of/ ?
Layer-3 next hop. If there is a GWR behind the CM it can acts as a
==> s/can acts/can act/ (in many places)
connected to the MSO network for management functions. During the
==> spell out MSO ?
Implementation work on CM/CMTS should be minimal because the only
significant difference between IPv4 IGMPv3 and IPv6 MLDv2 are the
longer addresses in the protocol.
==> "difference" in singular, so s/are/is/ ?
In today cable networks the CM receives a private IPv4 address
==> s/today/today's/ (a couple of times)
Security in a DOCSIS cable network is provided using Baseline Privacy
Plus (BPI+). The only part that is dependent on IP addresses is
encrypted multicast. Semantically, multicast encryption would work
the same way in an IPv6 environment as in the IPv4 network. However,
appropriate enhancements will be needed in the DOCSIS specification
to support encrypted IPv6 multicast. The other aspect of security
enhancement is mandated IPSec support in IPv6. The IPv6
==> split to next paragraph at "The other aspect".
through statefull DHCPv6 [RFC 3315] and stateless DHCPv6 [RFC 3736].
==> s/statefull/stateful/ (in very many places)
and PPPoE [RFC 2516]). The PPP sessions are initiated by Customer
Premise Equipment and it is terminated at the BRAS. The BRAS
==> sessions ... it is -- singular/plural?
The operation of PPPoE is similar to PPPoA with the exception that
with PPPoE multiple session can be supported over the same PVC thus
==> s/session/sessions/
The PPP session can be initiated by a host or by a Customer Router.
In the later case, once the session is established with the Edge
==> s/later/latter/
It is important to note here a signifcant difference between this
==> s/signif/signifi/
7.2.4.1 IPv4 in LAA Model and IPv6 in PTA Model
The coexistence of the two PPP based models, PTA and LAA, is
relatively straight forward. It is a straight forward overlap of the
two deployment models. The PPP sessions are terminated on
different network devices for the IPv4 and IPv6 services.
==> the middle sentence appears to be mostly redundant.. the only novel word
there is "overlap" :)
Subscribers might use a set-top box that is responsible for the
control piece of the multicast service (does group joins/leaves).
The subscriber hosts can also join desired multicast groups as long
as they are enabled to support MLDv1 or MLDv2. If a customer premise
router is used then it has to be enabled to support MLDv1 and MLDv2
in order to process the requests of the hosts. It has to be enabled
to support PIM-SSM in order to send PIM joins/leaves up to its
Layer-3 next hop whether it is the BRAS or the Edge router. When
enabling this functionality on a customer premises router, its
limited resources should be taken into consideration.
The router that is the Layer-3 next hop for the subscriber (BRAS in
the PTA model or the Edge router in the LAA and Point-to-Point
model) has to be enabled to support MLDv1 and MLDv2 in order to
process the requests coming from subscribers without customer
premises routers. It has to be enabled for PIM-SSM in order to
receive joins/leaves from customer routers and send joins/leaves
to the next hop towards the multicast source (Edge router or the
NSP core).
==> remove the extra empty line (this happened in a couple of places AFAIR).
==> there appears to be a fair amount of duplication in these paragraphs?
On the BRAS or the Edge Router the subscriber facing interfaces have
to be configure to police the inbound customer traffic and shape the
==> s/configure/configured/
network management tools that could provide trace-ability of the
==> s/trace-/trace/
+--------+ | +------+ |
+--+Agg E | |
+--------+ |Switch+-+
+-----+ |Access| +--+ |
|Hosts|--+Switch +-+ +------+
==> figure 8.1 is a bit screwed up..
In order to maintain the deployment concepts and business models
proven and used with existent revenue generating IPv4 services,
==> it is questionable how much revenue these BB services generated in
highly competed markets, and it's irrelevant to this draft in any case, so
suggest rewording /existent revenue generating/existing/
This deployment
types do not fit in the typical Hot Spot concept but they rather
address fixed customers.
==> in this kind of document, "address" in this context may be slightly
confusing, so rewording it might be useful.
The IETF draft [IPv6 over 802.11] mentions some of the concerns
related to running IPv6 multicast over WLAN links. Potentially
these are same kind of issues when running any Layer3 protocol
over a WLAN link that has a high loss-to-signal ratio, certain
frames that are multicast based are dropped when settings are not
adjusted properly.
==> s/The/An/
==> s/certain/where certain/ ?
[RFC 3041]
T. Narten and R. Draves, "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6," RFC 3041, April 2001.
==> s/[RFC 3041]/[RFC3041]/ (for consistency)
[6PE] De Clercq J., et al., "Connecting IPv6 Islands across IPv4
Clouds with BGP:, draft-ietf-ngtrans-bgp-tunnel-04.txt, July 2002
==> the latest version is draft-ooms-v6ops-bgp-tunnel (AFAIR)
Savola, P. "IPv6 Multicast Deployment Issues",
draft-savola-v6ops-multicast-issues-03.txt, February 2004
==> draft-mboned-ipv6-multicast-issues now
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings