[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access
Hello Pekka,
Please see in line ...
Date: Fri, 5 Nov
2004 08:42:14 +0200 (EET)
From: pekka savola <pekkas@netcore.fi>
To: Ciprian Popoviciu <cpopovic@cisco.com>
cc: v6ops@ops.ietf.org, Salman Asadullah <sasad@cisco.com>,
adeel Ahmed
<adahmed@cisco.com>
Subject: Re: ISP IPv6 Deployment Scenarios in Broadband Access
X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com
X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00
autolearn=ham
version=2.64
Sender: owner-v6ops@ops.ietf.org
X-PMX-Version: 4.7.0.111621
X-from-outside-Cisco: 128.107.234.206
Hi,
There's one thing that came across when doing the operator poll on v6
deployment which might warrant more discussion in the document...
On Thu, 21 Oct 2004, Ciprian Popoviciu wrote:
We integrated the feedback received on the
first version of the "ISP IPv6 Deployment Scenarios in Broadband
Access" draft and posted the updated document. You can also find it
at:
[...]draft-asadullah-v6ops-bb-deployment-scenarios-01.txt
We would like to thank Brian Carpenter, Patrick Grossetete, Benoit
Lourdelet, Tschofenig Hannes, Gert Doering, Alexander Koch for their
feedback and particularly Pekka for all his help along with his
feedback.
An operator which has deployed bridged-mode DSL ('RBE') said that the
only solution for providing bulk v6 access at the moment is requiring the
use of DHCPv6 for address assignment (i.e.: because DHCPv4 is snooped for
v4, the vendors seem to have implemented the same kind of snooping for v6
w/ DHCPv6).
Needless to say that that sounds like a very big problem. Requiring
DHCPv6 for address assignment for something like this seems ludicrous at
least :-).
Why do you see DHCPv6 as a problem ?
Alternatives
seem to be:
1) defining each /64 prefix to advertise for each customer
manually, not using bulk methods: this does not scale, so it's not an
option.
2) checking whether providing a single, shared /64 for all the
customers would work (what if there are address conflicts? what about
communication inside the prefix? does this work?)
3) implementing a mechanism which would allow for direct mapping of
VLAN or VC information to the advertised v6 prefix. For example, so that
for VLAN=100 you could just configure a bulk command
'map-vlan-to-v6-prefix 2001:db8:1::/48', and it would hand out e.g.
'2001:db8:1:64::/64' to the customer -- or something like that, allowing
bulk configuration
4) putting all the customers' v6 prefix information in a RADIUS or
similar database, so that the advertisement information could be digged
up from there. A lot of work, and does not work automatically. This
would also need some glue between bulk config and RADIUS.
All of this except 2) seems to be in the realm of implementations, not
requiring IETF protocol modifications, but to get these features
discussed and on the table, maybe such requirements and possible
solutions should be described in the document.
Could someone check whether 2) is possible or not, and if yes, which kind
of support it requires in the equipment ?
Option 2 works well and we have also explained it in the PPP
section of our draft.
You might have see Gert Doering's email on this that option 2 works
well.
Regards,
Salman
--
Pekka
Savola
"You each name yourselves king, yet the
Netcore
Oy
kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of
Kings