Subject: FYI Isatap implementations info

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Wed, 14 Apr 2004 10:03:24 +0200

Hi Fred,

In relation to the process of updating the Isatap draft
to comply with existing implementations (provided
that's still the idea -(?)) you 
may find the following information useful.

We have made and are continuing using 
implementations of Isatap
on host as well as on router stacks.
The implementations have been deployed in various
scenarios, though primarily using GPRS and UMTS
IPv4-only access networks.

The implementations are used in configurations which
are largely in compliance with (e.g.) draft-v12 with
the following derivations and/or clarifications:

General:
If not otherwise specified, [mechv02] requirements 
wrt ND, ICMP etc. over tunnels are fulfilled.

No multicast emulation.
DAD not performed on Isatap interfaces.
Link-layer Address Options not set and always 
ignored in ND messages received 
on Isatap interfaces.

MTU scheme based on configurable static MTU.

Host implementation particularities:

Direct tunneling to/from on-link addresses is allowed
(on-link equal to prefixes received in RAs).
The following security checks are applied
on incoming packets:

Either the v6 src must be on-link 
and match the v4 src - or the v4 src is from a router in PRL.
In addition RA's are always checked to ensure that
v6 src matches v4 src and that the v4 src must be in PRL.

Router Implementation particularities:

Only Router-to-host communication is supported, that is, 
PRL list not maintained on Router interfaces. 
The following security checks are applied
on incoming packets:

The inner IPv6 source address has a prefix configured (i.e. advertised)
on the ISATAP interface and an ISATAP-format interface identifier that 
embeds the IPv4 source address of the outer header.

v6inv4 Configured tunnels anchored on an Ipv4
 address also used by the Isatap interface
will have precedence over the Isatap interface, i.e.,
incoming packets will be processed by the configured tunnel interface 
implementation and not the Isatap interface implementation.
(Further, Isatap interfaces take precedence over 6to4 interfaces.)

For scalability reasons NUD is not performed on Isatap router interfaces.
Further on these interfaces, address resolution 
is based on static address computation only.

Security threat model:

The above security checks have been modeled
according to environments where the site perimeter
is guarded and where either:
* intra-site IPv4 address spoofing isn't possible (e.g. 3G telecom)
* intra-site nodes are trustworthy 

BR, Karen

-----------------------------------------------------------
Karen Egede Nielsen, System Manager, Ericsson Telebit A/S
Phone:  + 45 89385100, Fax:  + 45 89385101
Phone Direct: + 45 89385313, Mobile:+ 45 25134336
[email-masked]
-----------------------------------------------------------

---

From: Fred Templin <[email-masked]>
Date: Wed, 14 Apr 2004 10:58:27 -0700

Hello Karen,

Karen E. Nielsen (AH/TED) wrote:

>that's still the idea -(?))
>

W/o meaning to speak for the co-authors,  it seems safe enough
to say that the requirement for documenting the widely-deployed
implementations has been clearly communicated by the working
group and understood as first-priority.

>you may find the following information useful.
>

Yes, it was useful; thanks. See below for a few follow-up

>(on-link equal to prefixes received in RAs).

To my understanding, "on-link" should also include link-local - correct?

>The inner IPv6 source address has a prefix configured (i.e. advertised)

Again, to my understanding link-locals should also be included,
whereas "(i.e. advertised)" would seem to exclude them.

>embeds the IPv4 source address of the outer header.

Conspicuous by its absence here is the secondary check for
"v4 src is from a router in the PRL", but I note that you have
already stated that the PRL is not maintained on Router interfaces
in your implementation.

>implementation and not the Isatap interface implementation.

Agreed.

>(Further, Isatap interfaces take precedence over 6to4 interfaces.)

By "take precedence" here, I assume you mean that the received packets
 should be decapsulated/filtered as per the specification of precedence
(6to4 or ISATAP) - correct?  This is a (somewhat) unresolved aspect
of the "Re: ISATAP, v6inv4 and 6to4 ..." discussion thread. In further
thinking on this, I believe the correct answer is not quite as simple as
you are stating it here - but almost:

If a 6to4 interface and ISATAP interface are configured over the same
IPv4 address, it would have to be a global IPv4 address assigned to an
interface connected to the global Internet due to 6to4 requirements. In
that case, I believe the correct behavior should be for the 6to4 interface
to take precedence for packets received with an on-link 6to4 prefix in
the IPv6 destination, and for the ISATAP interface to take precedence
for all others. Comments?

>* intra-site nodes are trustworthy

I'm tempted to add a third bullet to your list:

  * intra-site communications are restricted to router<->host only

but perhaps this is implicitly covered by one of the other two?

Thanks - Fred
[email-masked]