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

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] ]

Hi Pekka,

Thanks for the comments - see my responses below:

Fred
ftemplin@iprg.nokia.com

Pekka Savola wrote:

I haven't been following the discussion, so I may be missing something -- but a few comments..

On Wed, 31 Mar 2004, Fred Templin wrote:


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.



The encapsulation part should be trivial, as it can be set by the
longest-prefix match by the system.  If it is set improperly, it's
only a problem of the implementation/operator.


Agreed.

Decapsulation is the tricky part.



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.



I don't think that's accurate.  For example, you don't use link-locals
on top of 6to4.  With ISATAP, you'd be accepting link-local traffic
from everyone.


I see your point. In the ISATAP decapsulation checks, we currently say
that we accept packets coming from any member of the Potential Router
List and (thorough error of omission, perhaps) that could include link-locals.
Seems like this should be pretty straightforward to fix - or do you still think
there is some tricky aspect of it that I'm not seeing?


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.


Yep, though in 6to4 the relay router is typically reached through the 6to4 pseudo-interface.

[...]


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.



Uh, no. 6to4 relay routers are also reachable through the 6to4 interface, right?


Well, yes - I agree with your point, and the ISATAP interface is not
the only choice. I don't believe this changes the fact that one possible
implementation alternative is to combine both the ISATAP and 6to4
functions over a single interface, however.

Fred
ftemplin@iprg.nokia.com