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

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Wed, 31 Mar 2004 10:16:13 +0200

Fred,

I think that the problem is very real, both implementation and
external behavior wise, every time you
want to implement more than one tunneling mechs.

Leaving it up to the implementation to resolve 
ambiguities is for me the same as to say 
coexistence not in scope of specification (which is fine). 

Specification of such coexistence may then of course 
appear at a later stage.

However if we actually wish at this stage to enable coexistence of
certain specific combinations of tunneling mechs
then IMO we should say MAY coexist under the following
unambiguous guidelines/rules.

Jordi et al.'s list may of course solve this once and for all.

Karen.

> 
> Karen,
> 
> Thanks for the additional thoughts. On the non-use of 6to4 prefixes as
> on-link prefixes for ISATAP interfaces, I'd like to 
> back-track on this yet
> again. I don't see a problem with an ISATAP interface and a 6to4
> interface anchored to the same (global unicast) IPv4 address and
> having the same 6to4 prefix as an on-link prefix - just as IP 
> addresses
> and prefixes may be assigned to multiple ordinary interfaces.
> 
> There is a slight difference in that ISATAP and 6to4 use slightly
> different checks on decapsulation, but it seems sufficient to leave
> as implementor's choice how to resolve the ambiguity, e.g., some
> might choose to always use the 6to4 decapsulation rules (and
> receive interface) in this case.
> 
> Fred
> [email-masked]
> 
> Karen E. Nielsen (AH/TED) wrote:
> 
> >Hi Fred,
> >
> >Please accept my apologies for sending 
> >half baked thoughts (previous mail) out on the list.
> >
> >A few comment inline.
> >
> >BR, Karen
> >
> >[snip]
> >
> >  
> >
> >>Agree that an implementation must be able to prioritize the
> >>tunnel interfaces. Not quite as clear on what should be included
> >>in "the spec", and not entirely sure exactly which document you
> >>are referring to when you say: "the spec", but see more below:
> >>
> >>    
> >>
> >
> >I simply mean that the prioritization in
> >between different tunnels in the inbound processing path
> >(i.e. exact algorithm behind the location of appropriate 
> inbound tunnel interface) can have implications for
> >the external behavior, wherefore it should be written down in
> >an IETF document. For what concerns Isatap, e.g., in the 
> Isatap "spec".
> >(In regard to the latest Isatap draft, e.g. in Section 
> 7.2.3, but this is of course not for me to say :-)).
> >
> >  
> >
> >>>For outbound traffic there isn't a problem, 
> >>>the appropriate tunnel interface should
> >>>be selected from the forwarding table/destination cache.
> >>>
> >>>      
> >>>
> >>Agreed; longest-prefix match will select the appropriate tunnel
> >>interface for outbound traffic.
> >>
> >>    
> >>
> >>>For inbound traffic there is an issue if the tunnel interfaces, 
> >>>lets say an Isatap pseudo tunnel interface and a configured 
> >>>v6inv4 tunnel interface, are anchored on the same
> >>>(source) address of an Ipv4 interface. 
> >>>The implementation must here be able to determine which 
> >>>      
> >>>
> >>protocol processing module
> >>    
> >>
> >>>(Isatap or configured tunnel respectively) that an incoming
> >>>packet should be subject to.
> >>>
> >>>      
> >>>
> >>Agree with the above assertions regarding inbound traffic.
> >>
> >>    
> >>
> >>>One possibility here (which we have used in one implementation)
> >>>it to apply the following inbound processing rules in 
> >>>      
> >>>
> >>prioritized order:
> >>    
> >>
> >>>R1.	If the outer IPv4 header of the encapsulated packet 
> >>>      
> >>>
> >>matches a configured v6inv4 tunnel (if any) the packet is 
> >>processed by this tunnel interface.
> >>    
> >>
> >>IP-proto-41 packets are first checked to determine whether 
> they belong
> >>to a configured tunnel by checking the (source/destination 
> >>addresses) in
> >>the IPv4 header, yes. This much seems consistent with the current
> >>ISATAP draft version, but thanks for reminding of this.
> >>    
> >>
> >
> >I am sorry if that's already spelled out in the current draft.
> >
> >  
> >
> >>>R2.	If the prefix of the source address in the inner IPv6 
> >>>      
> >>>
> >>header of the encapsulated packet matches a prefix of the (if 
> >>any) ISATAP interface, the packet is processed by this tunnel 
> >>interface.
> >>    
> >>
> >>>R3.	If the prefix of either the source or destination 
> >>>      
> >>>
> >>address in the inner IPv6 header is a 6to4 prefix, the packet 
> >>is processed by the (if any) 6to4 tunnel interface.
> >>    
> >>
> >>>I do consider it unlikely to have both 6to4 and Isatap used 
> >>>      
> >>>
> >>on the same Ipv4 interface  so a more strict version of the 
> >>above could be:
> >>    
> >>
> >>>An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on 
> >>>      
> >>>
> >>the same IPv4 interface 
> >>    
> >>
> >>>(address of an IPv4 interface, strictly speaking, the 
> >>>      
> >>>
> >>problems only arise if the tunnels are anchored on the same 
> >>addresses).
> >>    
> >>
> >>(Retracting a bit from some comments in an earlier message on 
> >>this subject.)
> >>According to RFC 3056, 6to4 can only occur over global unicast IPv4 
> >>addresses.
> >>ISATAP interfaces can also occur over global unicast IPv4 
> >>addresses, in 
> >>which
> >>case the ISATAP link would span the entire global IPv4 Internet.
> >>
> >>If we allowed both a 6to4 interface and an ISATAP interface 
> >>to be anchored
> >>to the *same* global unicast IPv4 address (e.g., "V4ADDR"), 
> >>it should be
> >>OK as long as no prefixes derived from "2002:V4ADDR::/48" 
> >>(i.e., the /48
> >>prefix itself, or any finer-grained derivative prefix) are 
> >>configured as 
> >>on-link
> >>prefixes on the ISATAP interface. This would keep the 
> >>"6to4-prefixed IPv6
> >>Internet" from overlapping with the "everything-else-prefixed IPv6 
> >>Internet",
> >>where "everything-else" is a candidate prefix for ISATAP.
> >>
> >>I think there may be several possible ways of expressing 
> >>this, ranging from
> >>"least restrictive" to: "most restrictive"; below are two 
> >>possible examples
> >>that lie at the extremities of the range of alternatives:
> >>
> >>Least restrictive:
> >>**************
> >>  "An ISATAP and a 6to4 tunnel interface MAY coexist on the 
> >>same global
> >>    unicast IPv4 address ("V4ADDR"), but in this case the 
> >>ISATAP interface
> >>    MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as
> >>    an on-link prefix."
> >>
> >>Most restrictive:
> >>**************
> >>  "An ISATAP interface configured over a global  unicast 
> IPv4 address
> >>    MUST NOT configure a prefix derived from "2002::/16" as an
> >>    on-link prefix." 
> >>
> >>(Note that both of these examples still allow for ISATAP interfaces
> >>configured over private IPv4 addresses to configure 6to4 prefixes,
> >>but the ISATAP tunneling would be strictly intra-site in that case.)
> >>
> >>Any comments on this?
> >>    
> >>
> >
> >First I must say, that the rules above were used by us 
> >in a Router implementation (not host) in which Isatap 
> communication only
> >was supported to and from the Isatap hosts of the router.
> >(i.e. no support for Isatap router-to-router).
> >
> >I apologies for not making that clear !!!!!
> >
> >Secondly:
> >
> >I assume that the above rules means to imply that a packet should be:
> >processed by the Isatap interface when inner packet is 
> destined to and/or sourced from an address with a prefix of 
> the Isatap interface.
> >
> >I guess that the above rules are sound and lead to 
> unambiguous behavior  
> >both in the host and in the Isatap+6to4 border router case 
> (that is, a router with both 6to4 pseudo (border router) and 
> router-to-host Isatap interfaces, the reason for not 
> including router-to-router isatap interfaces is simply that I 
> haven't thought very deeply about those)
> >
> >There may be a problem in the following, very very sick 
> could be discarded ?, situation:
> >Given that a router has a non-6to4 prefixed Isatap interface 
> >as well as a 6to4 relay router interface
> >anchored on the same address of an IPv4 interface (not using 
> 6to4 anycast address) then v6inv4 encapsulated packets may 
> arrive on the IPv4 interface in which the inner v6packet is 
> destined for an Isatap address with
> >the mentioned non-6to4 Isatap prefix of the isatap interface 
> but where
> >the encapsulated packet is sourced from a 6to4 border router 
> using 6to4. 
> >
> >This packet should be processed by the 6to4 interface and 
> not the Isatap interface.
> >
> >(And yes the hosts should speak Ipv4 instead of Ipv6 given, 
> as it is, that they
> >both have global Ipv4 addresses).
> >
> >On the other hand if the above prefix limitations are 
> combined with a split
> > in a host and a router part, such as:
> >* ROUTER interfaces: If the prefix of the source address in 
> the inner IPv6 
> >header of the encapsulated packet matches a prefix of the 
> (if any) ISATAP   interface, the packet is processed by this tunnel 
> >interface.
> >* HOST interfaces: If the prefix of the source address in 
> the inner IPv6 
> >header of the encapsulated packet matches a prefix of the 
> (if any) ISATAP   interface, the packet is processed by this tunnel 
> >interface,
> >then no ambiguity would arise wrt inbound 6to4 and isatap processing.
> >
> >
> >  
> >
> >>>An Isatap tunnel interface and a configured v6inv4 tunnel 
> >>>      
> >>>
> >>interface may be anchored on
> >>    
> >>
> >>>the same Ipv4 interface (address of Ipv4 interface). In this 
> >>>      
> >>>
> >>case the implementation must comply with the following 
> >>inbound processing rules in prioritized order:
> >>    
> >>
> >>>R1. If the outer IPv4 header of the encapsulated packet 
> >>>      
> >>>
> >>matches a configured v6inv4 tunnel (if any) the packet is 
> >>processed by this tunnel interface.
> >>    
> >>
> >>Agreed, as above.
> >>
> >>    
> >>
> >>>R2.	If the prefix of the source address in the inner IPv6 
> >>>      
> >>>
> >>header of the encapsulated packet matches a prefix of the (if 
> >>any) ISATAP interface, the packet is processed by this tunnel 
> >>interface.
> >>    
> >>
> >>I have to say that I have thought hard about this rule and am not
> >>entirely sure what to make of it, since it seems to simplistic.
> >>But, I will try:
> >>    
> >>
> >
> >Again, I apologize wildly for not making it clear that this was 
> >thought only to cover the
> >router case and only in the router-host situation.
> >
> >  
> >
> >>  1) What we have considered for this space to-date is that 
> an ISATAP
> >>    interface would match a specific IPv4 destination address and a
> >>    wild-card source address in the IPv4 header of an 
> >>ip-proto-41 packet.
> >>  2) Multiple ISATAP interfaces might be matched by this criteria,
> >>    and so we require a means for identifying the correct one.
> >>  3) An ISATAP interface that configures a prefix that 
> >>matches the IPv6
> >>    source of the packet (if found) is clearly the best 
> >>first-choice to 
> >>receive
> >>    the packet.
> >>  4) If no ISATAP interface with a matching prefix is found, 
> >>this could
> >>    be a packet from an off-link source that is being 
> >>forwarded to (or,
> >>    through this decapsulator by a member of the Potential 
> >>Router List.
> >>
> >>But, stopping now for a closer look at item 4), there seems to be no
> >>way to determine which ISATAP interface (among possibly many)
> >>might be the correct one to receive and decapsulate the packet - if
> >>any. It could be that the IPv6 destination address is a 
> >>foreign address
> >>also, making for a router<->router transaction which is a non-goal
> >>for ISATAP.
> >>
> >>This says that, in order to disambiguate the search, we 
> really need to
> >>treat all possible IPv6 source addresses as on-link for the 
> purpose of
> >>receiving packets, but off-link for the purpose of sending return
> >>packets. In other words, we would need an ISATAP interface
> >>with a distinct /128 prefix for each destination we are actively
> >>communicating with that uses the same IPv6 next-hop address
> >>for return addresses. In other words, from a host's viewpoint the
> >>sources of IPv6 packets for which a matching ISATAP interface
> >>exists would all appear to be on-link, but the destinations would
> >>all appear to be off-link and reachable through a particular IPv6
> >>next-hop address. There is a (somewhat) subtle implication here
> >>for decapsulation validity checks of the IPv4 source address,
> >>but should be very simple to express.
> >>
> >>If what I am saying makes sense, and if we can agree that ISATAP
> >>support for router<->router tunneling is a non-goal, then I believe
> >>your R2 above could provide a useful simplification for the spec.
> >>    
> >>
> >
> >Wouldn't you need
> >a different R2 for host and for router interfaces 
> >(founded on destination address and source address respectively) ?
> >
> >In addition, the source address check could potentially be 
> performed by the isatap host interface implementation - e.g. 
> to rule out direct packets from 
> >"non-link" hosts - thus limiting the direct tunnelling 
> function to hosts 
> >using the same prefixes - and/or to rule out packets coming 
> form anything else
> >than default router in some scenarios.
> >
> >With the 6to4 prefix limitation on Isatap interfaces this would
> >eliminate conflicts wrt inbound 6to4 and Isatap interfaces 
> processing.
> >
> >In addition you would need to prioritize configured tunnel and Isatap
> >interfaces, but I guess that this is implicitly covered by 
> 1) (in that
> >specific Ipv4 addresses would take precedence over wildcard 
> in Ipv4 source).
> >
> >I hope this at least help to clarify my previous mail.
> >Whether it adds anything useful to the picture, will be for you and 
> >others to decide.
> >
> >BR, Karen
> >  
> >
> >
> >This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> >
> >E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
> >
> >  
> >
> 
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Fred Templin <[email-masked]>
Date: Wed, 31 Mar 2004 06:47:59 -0800 (PST)

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.
 
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
[email-masked]

"Karen E. Nielsen (AH/TED)" <[email-masked]> wrote:
Fred,

Karen.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 Mar 2004 18:57:05 +0300 (EEST)

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

> 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.  Decapsulation is the
tricky part.

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

Uh, no.  6to4 relay routers are also reachable through the 6to4 
interface, right?
 
-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Wed, 31 Mar 2004 09:24:26 -0800

Hi Pekka,

Thanks for the comments - see my responses below:

Fred
[email-masked]

Pekka Savola wrote:

>only a problem of the implementation/operator.
>

Agreed.

>Decapsulation is the tricky part.
>
>  
>

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?

>Uh, no.  6to4 relay routers are also reachable through the 6to4 

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
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 Mar 2004 21:04:09 +0300 (EEST)

On Wed, 31 Mar 2004, Fred Templin wrote:
> 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?

I'm not sure what you're saying:

1) modifying the reception from members of PRL list (in some fashion)

2) modifying the acceptance of link-local messages in general
 2.a) for all members of PRL
 2.b) for PRL members and ISATAP nodes both

I think you were proposing 2.a), but not sure? (Or 2.b?)

Disallowing link-locals could have a number of effects depending on
which of these methods it's used.  E.g., it could prevent running a
routing protocol on top of the links (not sure if you'd want that).  
It might also be confusing to disallow it as you're typically
configuring an ISATAP link-local address as your next-hop (and you
couldn't ping the next-hop).  

I.e., if the link-local address would only work as a "pseudo-address",
it would be used only as a means to specify "send to node 192.1.2.3
through isatap interface".

How would the ISATAP nodes send RS to the router, and the router send
RA to the nodes to configure the on-link prefix, btw, if this was
disallowed?

> functions over a single interface, however.

(I haven't gone through the thought exercise of looking through the
details, but the prospect leaves me with a fuzzy bad feeling..)

---

From: Fred Templin <[email-masked]>
Date: Wed, 31 Mar 2004 10:36:53 -0800

Pekka,

>RA to the nodes to configure the on-link prefix, btw, if this was

No; not disallow link-locals, since they are fundamental to ND over ISATAP.
The intent of the proposal was only to stop link-locals from coming from
incorrect nodes. In the current document (section 8.6), we have the 
following
checks for IPv4 source address verification:

       For packets received on an ISATAP interface, the IPv4 source
       address is correct if:

       -  the IPv6 source address is an ISATAP address that embeds the
          IPv4 source address in its interface identifier, or:

       -  the IPv6 source address is the address of an IPv6 neighbor on
          an ISATAP interface associated with the locator that matched
          the packet (see: section 7.2.3), or:

       -  the IPv4 source address is a member of the Potential Router
          List (see: section 9.1).

Neglecting for the moment the middlemost of the three checks, we see that
the first check accepts link local IPv6 source addresses that embed the IPv4
source address in the interface identifier. However, the third check also
accepts link local IPv6 source addresses that *do not* embed the IPv4
source address - so long as the IPv4 source address is in the Potential
Router List - and this is the part that could cause trouble.

The fix suggestion is to modify the third check in the list to exclude
packets with IPv6 link-local source addresses from the check, forcing
IPv6 link-locals to be either verified or rejected via the first check only.
Comments?

>details, but the prospect leaves me with a fuzzy bad feeling..)

Well, the good news is that this would fall under implementation details,
and not anything necessary for protocol specification - right?

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 31 Mar 2004 23:42:08 +0300 (EEST)

> IPv6 link-locals to be either verified or rejected via the first check only.

I see no harm in that.

But it should be obvious that this doesn't really provide much of 
practical mitigation, as v4 addresses can be spoofed, or you could 
just use a real v4 address.  This check is most attractive inside a 
site, where it's reasonable to assume that ingress filtering is in 
place .. and the "everyone in PRL list" is definitely not that case.

(The only difference, still, with 6to4 is that the similar abuse of 
6to4 is limited to global addresses -- not link-locals, even if the 
v4addr matched.)

> and not anything necessary for protocol specification - right?

I fear I have to disagree.. leaving these unspecified seems like an
indication that we never managed to figure them out properly, and
leaving them as an "exercise for the reader".  This would tempt the
implementer to either 1) do them improperly, or 2) not do checks at
all.  We have already seen examples of both...

I.e., I think it would be very useful to try to figure out a way to
perform decapsulation processing in a sane fashion.  We don't need to
normatively *require* the specific processing rules, of course -- but
just provide them as an example (or two) for the implementers.

---

From: Fred Templin <[email-masked]>
Date: Wed, 31 Mar 2004 13:41:09 -0800

>>IPv6 link-locals to be either verified or rejected via the first check only.

OK, but I am still checking my thinking on this. I'm now thinking that
my suggestion might foul things up for protocols that require a means
for detecting L2 address changes due to, e.g., a NAT in the path.

>place .. and the "everyone in PRL list" is definitely not that case.

I didn't quite catch what you meant by "a real v4 address"?

>6to4 is limited to global addresses -- not link-locals, even if the 

In terms of link-locals, the first-pass filtering by the ISATAP decapsulator
is only for the purpose of determining whether the IPv4 source address in
the encapsulating header is acceptable for the IPv6 source address in the
encapsualted packet. Higher layers up the stack will also likely use other
mitigations in determining whether/not to accept link-local packets, but
this is beyond the scope of our discussion on decapsulation.

>just provide them as an example (or two) for the implementers.

I can potentially see your point, depending on exactly which document
you think such non-normative text should appear in.

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Wed, 31 Mar 2004 14:07:49 -0800

> for detecting L2 address changes due to, e.g., a NAT in the path.

Umm - sorry. That would be a Teredo concern (not ISATAP) and
outside the scope of 'ip-proto-41' tunneling.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Thu, 1 Apr 2004 07:54:57 +0300 (EEST)

> I didn't quite catch what you meant by "a real v4 address"?

The check only protects from someone spoofing their v4 address.  If 
the use of link-locals by strangers (remember that these have TTL=255 
and are allowed to do anything Neighbor Discovery -wise) is 
categorically thought to be harmful (I certainly think so), this 
doesn't really help.

> this is beyond the scope of our discussion on decapsulation.

Of course, but as LL's are treated specially e.g. by ND code, this 
makes the ISATAP decapsulation non-equivalent to 6to4 decapsulation.