Re: Fwd: Re: ISP IPv6 Deployment Scenarios in Broadband Access

[Salman Asadullah <sasad@cisco.com>]

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