This customer ID doesn't need to be local to the GW, as when using GI
6rd, IPV6 prefixed of different users are different. GW does the
addressing based on the IPv6 prefix of the IPv6 addresses.
B. R.
Tina
http://tinatsou.weebly.com
On Nov 9, 2010, at 5:32 AM, Lee, Yiu wrote:
I see the "customer id" is local to the gw. This is why I don't see
a new
draft is needed. However, the major challenge is even fewer bits are
available for the CPE.
On 11/8/10 9:33 AM, "Ole Troan" <[email protected]> wrote:
The obvious answer is to use multiple 6rd domains and set
IPv4MaskLen >
0
to save bits. Then, run the dhcp server on the GW (i.e. 6rd-CE) to
delegate prefixes to the hosts. However, what is new in this draft
rfc5969
can't do?
nothing as such.
the difference with gi-6rd is that you also need to encode the
'customer
id' in the address.
cheers,
Ole
Tina,
Consider an operator facing a high subscriber growth rate. As a
result of this growth rate, the operator faces pressure on its
stock
of available public IPv4 addresses. For this reason, the
operator
is
motivated to offer IPv6 access as quickly as possible.
The backbone network will be the first part of the operator's
network
to support IPv6. The metro network is not so easily upgraded to
support IPv6 since many devices need to be modified and there
may
be
some impact to existing services. Thus any means of providing
IPv6
access has to minimize the changes required to devices in the
metro
network.
what is it that makes existing softwires mesh solutions
unsuitable
for
crossing the IPv4 only metro network? I'm thinking specifically
on
6PE
or BGP tunnels.
Ole, thank you for asking. I didn't say that. IMHO, 6PE or BGP are
more
appropriately used in core network. There are fewer uses of MPLS
in
metro network. BGP tunnels are also more appropriate for core
network.
Essentially the authors are talking about a situation where 6rd
is an
applicable technology, but needs modification to meet the
constraints
of
maximized savings of IPv4 addresses and no provider access to
customer
site equipment. The IPv4 address savings occur only if the
customer
site
is IPv6-only, but the proposal still works for dual-stack customer
sites. The technical solution is to move the IPv6 in IPv4 tunnel
endpoint to the provider edge rather than have it in equipment
on the
customer site, and use the provider gateway IPv4 address in the
IPv6
prefix given to the customer site. As Ralph pointed out, the
protocol
in
RFC 5969 should be able to be applied without change.
The authors will restructure the draft to illustrate this latter
point.
As Ralph suggested, it will be submitted with the intention of
becoming
an Informational describing an alternative deployment of 6rd to
meet
the
constraints we described above. I hope this plan meets with the
chairs'
approval.
1) is BGP tunneling not applicable because these devices don't
support
BGP? or not support MPLS?
2) my concern with using 6rd for this purpose is that while
automatic
tunneling by encoding the tunnel end point in the payload address
is
convenient. offering a 'sensible' sized IPv6 prefix to end users is
going
to be problematic. note this is purely a concern from a deployment
perspective. I have no doubt that you can _use_ 6rd this way. just
because we _can_, _should_ we?
can you give some examples of how you deliver e.g. /56 or /64 to
end
users, using gi-6rd? (without expecting the SP to have a /16 of v6
space
obviously).
cheers,
Ole
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
