RE: 6rd - Rapid Deployment on existing IPv4 infrastructures - a new approach

["Tony Hain" <alh-ietf@tndh.net>]

Disclaimer: for several days others have been telling me I am mis-reading
this draft.

That said, my interpretation is that this is broken, despite a quick hack
deployment. In any case, I don't believe the proposed fixes would be
difficult changes for the existing deployment and will result in a cleaner
solution.

Despite the elaborate Intro & Principles discussion, to clarify what I think
the goals are:

1) automate ISP controlled tunnels over IPv4-only aggregation equipment.

2) assign customer prefixes within ISP's delegated RIR prefix to contain the
size of the IPv6 DFZ

Discussion:

This general approach actually works well in the downstream direction as a
tool to automate PE to CPE tunneling. The PE already has to be provisioned
with the aggregating prefix for its downstream customers, so this is really
just an automated neighbor resolution process on the back end across the
IPv4-only aggregation equipment. A BCP describing how to align an IPv6
aggregating prefix for automated PE tunneling would be a good thing,
independent of this draft. The upstream direction is another story though.

Problems:

1) 'pure' tag makes a questionable assumption in light of unresolved and
continuing RIR discussions about changing the status of 240/4.

2) causes ISPs to allocate unnaturally large prefixes to pops to accommodate
a mostly unused 32-bit field

3) the 3.5 discussion about accepting prefixes from other ISPs that might
contain a 6rd anycast is just wrong. First there is no way for an ISP to
know which prefix its peer is using for a 6rd relay. Second, there is no
reason to preclude it since the IPv6 6rd prefix would not match for their
sites, and the local CPE would not be configured for the other ISP's
anycast, so the local CPE would never be attempting to send to the other
ISP's 6rd anycast relays even if there is a route. 

Fixes:

Option 1) provide the IPv4 prefix & length:4 (really only need length:4
since CPE already has addr), as well as IPv6 prefix & length:6. Extract bits
(32-length:4) following IPv6 prefix/length:6, then append to IPv4 prefix to
create IPv4 next-hop.
Pro: PE allocation size is the same for both versions  
Con: CPE can only directly see its containing IPv4 aggregate 
Resolution: DHCP option includes list of IPv4 prefixes & lengths that are
directly reachable
Alternate Resolution: PE sends redirect for any other prefix in the IPv4 IGP
Con: CPE can't tell if a neighbor is tunneled or native
Resolution: all CPE attached to a PE must move at the same time to a prefix
shorter than the ISP-wide 6rd one, or PE must host its portion of the
shorter native prefix as well as the 6rd one.
	(much cleaner than assuming 224/3 is never a valid IPv4 dst)

Option 2) CPE always initially sends to PE, PE sends redirect for anything
the CPE should be able to reach as indicated by the IPv4 IGP
Pro: CPE defers routing decision to PE
Pro: CPE configuration is just a 4213 manual tunnel
Con: CPE router may ignore redirect
Resolution: Requires spec so CPE will accept redirect from the upstream
router
Con: increases load on PE to generate redirects
Resolution: CPE caches redirects for the lifetime of its DHCP lease
	(if redirect included length:4, the CPE could figure out the rest of
that aggregate)

Tony



> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Rémi Després
> Sent: Tuesday, February 12, 2008 2:29 AM
> To: v6ops@ops.ietf.org
> Subject: 6rd - Rapid Deployment on existing IPv4 infrastructures - a
> new approach
> 
> The I-D is available at:
> http://www.ietf.org/internet-drafts/draft-despres-v6ops-6rd-ipv6-rapid-
> deployment-00.txt
> 
> (A previous file name had to be replaced by this one, more compatible
> with recommended practices, and including the now selected WG
> reference)
> 
> Rémi