Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]

[Brian E Carpenter <brc@zurich.ibm.com>]

Fred Templin wrote:

> Karen,
>  
> OK, if you must know it then I believe it is possible to run both 6to4 and
> ISATAP from a single interface. Let's say a node wants to send a packet
> to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
> is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
> for the moment that 192.1.2.3 is non-global and used only as example).
> If the node has, e.g., a route in its routing table such as:
>  
>    2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
>  
> then the packet will go out the isatap0 interface using ISATAP encapsulation
> based on the link-local ISATAP address from the routing table as the next-hop
> toward the 6to4 router, and the 6to4 router will be unable to tell whether the
> encapsulator used 6to4 or ISATAP.

Well, I've read this and the followups, and I am still confused.

The intended domain of utilisation of 6to4 is for giving sites that don't
have an IPv6 SP a backdoor into the IPv6 world (and a free /48 to go with it).
[In the degenerate case, the site is a single host connected to an IPv4 SP.]

As I understand it, the intended domain of utilisation of ISATAP is
to provide internal connectivity within a site that has an IPv6 SP but
doesn't have a dual stack internal network.

That being so, I just can't see a useful scenario where what Fred describes
can happen. Can somebody draw me a picture? [Emphasis on the word "useful."]

   Brian

>  
> In other words, if we view each 6to4 router as also an ISATAP router with a
> link-local address on the "site" that includes the global IPv4 Internet, then it
> really makes no difference whether we use a 6to4 interface or an ISATAP
> interface for sending the packet.
>  
> In terms of receiving packets, if we view every global IPv4 address as a
> "Potential Router", then the ISATAP decapsulation checks amount to
> exactly the same (optional) checks suggested for 6to4 and, again, either
> interface could be used to receive the packet with no differences.
>  
> The difference comes when operational deployments will begin to use
> non-6to4 global IPv6 prefixes, in which case sending nodes will need to,
> e.g., add routes such as:
>  
>    3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0)
>  
> Then, the ISATAP router at 192.1.2.3 will appear the same as
> if it were a 6to4 relay router that relays from the 6to4 domain to the
> 3FFE:EXAMPLE::/48 prefix space. Sending nodes will most likely use
> the DNS to discover the IPv6 prefix to global IPv4 address mappings for
> destinations of interest, and so there really would be no need for running
> a BGP-style routing protocol between the ISATAP routers (that are really
> acting as 6to4 relay router equivalents). In this case, however, the only
> choice would be to use an ISATAP interface, since 6to4 interfaces only
> encapsulate packets sent to a 2002:EXAMPLE::48 prefix.
>  
> So, I guess that would make the ISATAP interface as the LCD that
> needs to be there in any case, and configuring a 6to4 interface also
> on the same node (and over the same IPv4 address) could be viewed
> as optional. This is not by way of saying that ISATAP is in any way
> obsoleting 6to4, but rather the 6to4 and non-6to4 prefix space can
> be consolidated into a single automatic tunnel interface footprint
> (instead of two) if desired.
>  
> Fred



-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM