[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: I-D Action:draft--remi-despres--ipv6-rapid-deployment--00.txt

The point being discussed is IMU simplicity vs functional richness.
IMO, the "normal" 6rd is with a /24 ISP prefix, allowing for /58s site prefixes. Yet, to start quickly, as Free did it, /64s are nice to have instead of nothing.
Note that if a site has a shorter than /32 IPv4 prefix, say a /28, then it has with 6rd the desired multi-subnet capability with 6rd. (Free happens to only assign /32s in IPv4).
Note also that ISPs typically have their IPv4 prefixes coming one by one, with different lengths. Free's IPv4 prefixes, for example, are of lengths /16, /15, /14, two /11s, /10. 
he simple solution of your example couldn't apply.
The code to deal with this, instead of being trivial, and with fixed length parameters, would bacome significantly more complex. 
The DHCP option also would be substantially lesss simple

RD

Gert Doering a écrit :

Hi,

On Fri, Feb 08, 2008 at 05:29:45PM +0100, Rémi Després wrote:
/64 is clearly not ideal, but is guaranteed to be possible for ISPs that get only /32 from their RIR's. 

Using a more intelligent mapping function than "always use full 32 bit"
for the mapping IPv4-Address <-> IPv6-Prefix would solve this.

For example, if an ISP only has a /16 IPv4 address space, they could
map this to a /48 IPv6 per end user, inside their IPv6 space:

  </32 prefix from RIPE><lower 16 bits of CPE IPv4 address>::/48

- as the upper 16 bits are the same for all subscribers anyway.


Tony Hain has brought up some approaches how to get the mapping table
to the CPEs.
Another thing could be to just statically provision the mapping tables ("<this> range is 6rd, use point-to-point 6to4 tunnels - and all the rest is native, send to PE") in the CPEs at roll-out - as most ISPs do not get new IPv4 blocks *that* often. 

Or provision them at "automated centrally managed software update" time.

Gert Doering
        -- NetMaster