This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Re: Re: IPv6 allocations for 6RD
- Previous message (by thread): [address-policy-wg] Re: IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Daniel Roesen
dr at cluenet.de
Tue Mar 1 09:42:35 CET 2011
On Tue, Mar 01, 2011 at 10:24:46AM +0200, Ahmed Abu-Abed wrote: > According to RFC 5969 for 6rd: > > " Embedding less than the full 32 bits of a CE IPv4 address is possible > only when an aggregated block of IPv4 addresses is available for a > given 6rd domain. This may not be practical with global IPv4 > addresses, but is quite likely in a deployment where private > addresses are being assigned to CEs. " > > So the /64 limitation for 6rd applies when an aggregated block of IPv4 > addresses is not being used. I cannot read that in there. Above paragraphs talks about sub-32bit mapping of IPv4 endpoint addresses. This is orthogonal to what the prefix size for your customer delegation is. Example: your 6RD domain is a /27 IPv4 block. You can serve that with an IPv6 /51 block, giving each 6RD customer a /56. IPv4 /27 == 5 relevant bits (host addressing), 51+5=56. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0
- Previous message (by thread): [address-policy-wg] Re: IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]