Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 1 Jul 2011 15:54:41 -0700

Hi Joel,

Me again. There have have been others who have also expressed
concerns about DHCPv6 and other "undocumented features" on
ISATAP links, so I decided to split the document into two pieces.

The new piece is now called: "ISATAP Updates" and I guess might
be more appropriate for some other working group. The other piece
retains the original name and is strictly about operational aspects
of widely-deployed implementations:

http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-12.txt
What should we do next - ask the wg for comments?

Thanks - Fred

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To: Joel Jaeggli
Cc: [email-masked]
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

Hi Joel,

Thanks for your comments, and see below for responses:

________________________________
From: Joel Jaeggli [mailto:[email-masked]]
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

On Jun 3, 2011, at 8:13 AM, Templin, Fred L wrote:

Hello,

Significant improvements have been made to this document
(below) based on comments received and new observations.
IMHO, this is an important document for enabling transition
to IPv6 within IPv4 sites; hence, I would like to call for
working group adoption at this time.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

Replying to this message as a way to maintain the threading. these notes are relative to the current version of the draft which I reviewed last week:

http://tools.ietf.org/html/draft-templin-v6ops-isops-10

So I tried for a while to separate the operational advice that could be applied to my 2005 era knowledge of isatap and there's  quite a few things that jive with that (tunnel loops for example).
OK.
In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what implementations are capable of doing that? Are we recommending that they do it? do they already?
I can't speak for current implementations, but the DHCPv6 approach is
based on the fact that address and prefix assignment on IPv6 interfaces
are seperable functions. IPv6 prefixes assigned to ISATAP interfaces can
only be used for autoconfiguration of ISATAP addresses and not ordinary
IPv6 addresses. However, an ordinary IPv6 address can be assigned to
an ISATAP interface the same as for any other IPv6 interface as long as
it is not covered by a prefix assigned to the interface.
Regarding aero (section 4.6) that looks pretty much like new work or an extension to the specification.
AERO is a new but backwards-compatible method of doing redirection
of an on-link neighbor to another on-link neighbor. However, ISATAP
interfaces can still use standards ICMPv6 Redirect messages the same
as for any IPv6 interface. Advertising ISATAP routers should only send
ICMPv6 redirects when they are certain that the redirected ISATAP node
can tunnel packets directly to the target of the redirect, however. Perhaps
a few more words saying explicitly that standards ICMPv6 redirects are
still supported would help?
Are there participants with extant isatap deployements or host implementations or knowledge fresher than mine that would care to comment on this draft.

There are certainly vendors who are shipping ISATAP in their products
today. Perhaps they can comment.
section 9 alternative approaches, there's some consensus that rfc 3056 was never really deployed so the reference to 6to4 should probably be to 3068

OK - I can fix this.

Thanks - Fred
[email-masked]<mailto:[email-masked]>

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 3 Jul 2011 16:37:31 -0700

> What should we do next - ask the wg for comments?

yeah, I think the question of do isatap implementers  or users in v6ops find this line of work interesting and useful is essentially the open question thatwould cause us to consider advancing this as a wg document vs allowing you to pursue it as an indivudal submission. I think that preaking shcpv6 out of it is a wise idea.

>> [email-masked]
>> 
> 
> [email-masked]

---

From: Dmitry Anipko <[email-masked]>
Date: Tue, 5 Jul 2011 19:28:12 -0700

Hi Joel,

>>yeah, I think the question of do isatap implementers  or users in v6ops find this line of work interesting and useful is essentially the open question thatwould cause us to consider advancing this as a wg document

I think having a document with operational guidance for ISATAP would be useful and would support adoption of this document by the WG.

Thank you,
Dmitry

From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel Jaeggli
Sent: Sunday, July 03, 2011 4:38 PM
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

Hi Joel,

Thanks - Fred

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To: Joel Jaeggli
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
Hi Joel,

Cc: [email-masked]<mailto:[email-masked]>

Hello,

Thanks - Fred

OK - I can fix this.

Thanks - Fred

---

From: "John Mann (ITS)" <[email-masked]>
Date: Fri, 8 Jul 2011 13:09:03 +1000

Joel,

On 4 July 2011 09:37, Joel Jaeggli <[email-masked]> wrote:

> ...
> yeah, I think the question of do isatap implementers  or users in v6ops
> find this line of work interesting and useful is essentially the open
> question thatwould cause us to consider advancing this as a wg document vs
> allowing you to pursue it as an indivudal submission. I think that preaking
> shcpv6 out of it is a wise idea.
> ...
>

I am doing an ISATAP deployment, think the document is useful/interesting,
and I support advancing this as a WG document.

Thanks,
    John

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 8 Jul 2011 17:46:31 -0700

cool,

could we potentially pigeonhole you for a review of the doc from the vantage point of someone using it?

joel

On Jul 7, 2011, at 8:09 PM, John Mann (ITS) wrote:

> I am doing an ISATAP deployment, think the document is useful/interesting, and I support advancing this as a WG document.
> 
> Thanks,
>     John
>  
>

---

From: "John Mann (ITS)" <[email-masked]>
Date: Sun, 10 Jul 2011 12:39:09 +1000

Joel,

Sure,
   John

---

From: "John Mann (ITS)" <[email-masked]>
Date: Thu, 14 Jul 2011 10:28:34 +1000

v6ops people,

Fred and I have done round of review off-list.
This is my reply to that ..

On 14 July 2011 02:53, Templin, Fred L <[email-masked]> wrote:

> **
> Hi John,
>
> Thanks again for the comments, and see below for proposed
> resolutions:
>
>  ------------------------------
> *From:* John Mann (ITS) [mailto:[email-masked]]
> *Sent:* Tuesday, July 05, 2011 11:24 PM
> *To:* Templin, Fred L
>
> *Subject:* Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
>
> Fred,
>
> The per-page heading is "Routing Loop Attack".
>
> Good catch. I will change this to "ISATAP Operational Guidance".
>
>
>  1.  Introduction
>
> s/RANGERS/RANGER/
>
>
> There are actually two documents - RANGER is [RFC5720] and RANGERS
> is [RFC6139]. I was meaning to cite the latter.
>
>
>  2.  Enabling IPv6 Services using ISATAP
>
>    "Many existing sites within the Internet predominantly use IPv4-based
>    services for their internal networking needs, but there is a growing
>    requirement for enabling IPv6 services to support communications with
>    IPv6-only correspondents."
>
> This sentence is a a re-hash of the last paragraph of section 1.
> Perhaps it can be removed ??
>
>
> Good point, but I'd still like  a lead-in sentence to that paragraph so
> how would it be if I simply replaced that sentence with the following:
>
>   "Existing IPv4 sites within the Internet will soon need to enable
>    IPv6 services."
>

Fine.

>
>     "Smaller sites that wish to enable IPv6
>    typically arrange to obtain public IPv6 prefixes from an Internet
>    Service Provider (ISP), where the prefixes may be either purely
>    native, the near-native prefixes offered by 6rd [RFC5969] or the
>    transitional prefixes offered by 6to4 [RFC3056][RFC3068]. "
>
> I would split this into
>    Smaller sites that wish to enable IPv6
>    can arrange to obtain public IPv6 prefixes from an Internet
>    Service Provider (ISP), where the prefixes may be either purely
>    native, or the near-native prefixes offered by 6rd [RFC5969].
>    Or use an ISP-independant method like
>    transitional prefixes offered by 6to4 [RFC3056][RFC3068],
>    or prefixes from a tunnel-broker [ref?].
>
>
> Good point, although I think perhaps a bit more should be said about
> 6to4. Rephrasing slightly, see if this sounds OK:
>
>   "Smaller sites that wish to enable IPv6 can arrange to obtain public IPv6
>    prefixes from an Internet Service Provider (ISP), where the prefixes may
>    be either purely native or the near-native prefixes offered by 6rd
> [RFC5969].
>    Alternatively, the site can obtain prefixes independently of an ISP e.g.,
> via
>    a tunnel broker [RFC3053], by using one of its public IPv4 addresses to
>    form a 6to4 prefix [RFC3056][RFC3068], etc."
>

Please add something like
   Note that 6to4 is not recommended for new implementations
[draft-ietf-v6ops-6to4-to-historic or draft-moore-6to4-experimental ],
and should be implemented with care [ draft-ietf-v6ops-6to4-advisory or
RFC-new ].

>     "Advertising ISATAP
>    routers configure their site-facing ISATAP interfaces as advertising
>    router interfaces "
>
> "site-facing" isn't defined.  How many interfaces each router has is not
> defined.
>
>  =>  Each advertising ISATAP router configures an site-internal interface
> as an ISATAP advertising router interface.
>
>    "ISATAP hosts
>    configure their site-facing ISATAP interfaces as simple host
>    interfaces and ..."
>
> "site-facing"?  how many interfaces?
>
> => Each ISATAP host configures an interface as a simple ISATAP host
> interface and ...
>
>
> I get your point, and I think perhaps a bit more work is needed here.
> Any node (host or router) can have any number of ISATAP interfaces
> connected to any number of sites. The host may be an advertising
> ISATAP router on some sites, a non-advertising ISATAP router on
> other sites, and a simple ISATAP host on other sites. Each such
> "personality" of the node would be represented by a distinct ISATAP
> interface. With that in mind, here is a proposed rewrite of the paragraph:
>
>   "The ISATAP service is based on two node types known as
>    advertising ISATAP routers and simple ISATAP hosts. (A third node
>    type known as non-advertising ISATAP routers is defined in
>    [draft-templin-isupdate] but out of scope for this document.) Each node
>    may further have multiple ISATAP interfaces (i.e., one interface for
> each
>    site), and may act as an advertising ISATAP router on some of those
>    interfaces and a simple ISATAP host on others. Hence, the node type
>    is considered on a per-interface basis.
>
>    Advertising ISATAP routers configure their ISATAP interfaces as
>    advertising router interfaces (see: [RFC4861], Section 6.2.2). ISATAP
>    hosts configure their ISATAP interfaces as simple host interfaces and
>    also coordinate their autoconfiguration operations with advertising
> ISATAP
>    routers. In this sense, advertising ISATAP routers are "servers" while
>    ISATAP hosts are "clients" in the service model."
>

I am a little bit confused here about the possibility that a host may be
connected to a number of sites.
For the purposes of this document, is it useful to simplify the model a
little:

| *IPv4 view* | *ISATAP view* | *Connectivity* | *Multi-site* |
| host | ISATAP host | connected to one ISATAP subnet | No |
| gateway | advertising ISATAP router | can connect to multiple ISATAP
subnets | Possible |

[ I know, I have introduced a new term "gateway" ]

>  3.3.  Reference Operational Scenario - Shared Prefix Model
>
> I think this could be _slightly_ improved by being a bit more explicit when
> packets are encapsulated,
> and whether they are sent to a host/routers IPv4 or IPv6 address.
>
>
> I like the idea of being more explicit. In your proposed text below,
> however, would you mind if I omitted the "IPv6-in-IPv4" and just
> used the word "encapsulated". Reason being is that, since we
> are talking about ISATAP, IPv6-in-IPv4 is already assumed.
>
>
>  "Assuming 'A' is closest, 'C' receives an
>     _IPv6-in-IPv4 encapsulated_
>    RA from 'A' then configures a default
>    IPv6 route with next-hop address fe80::5efe:192.0.2.1 via the ISATAP
>    interface and processes the IPv6 prefix 2001:db8::/64 advertised in
>    the PIO. "
>
> " 'D' next performs an
>      _IPv6-in-IPv4 encapsulated_
>    anycast RS/RA exchange that is serviced by 'B', "
>
> "If the site is not partitioned internally, the
>    router that receives the packet can use ISATAP to statelessly forward
>    the packet directly to 'C' _using IPv6-in-IPv4 encapsulation_.
>
>
Yes, IPv6-in-IPv4 should be clear in context.

>  ===
> Otherwise, excellent stuff.
>
>
> Thanks, and I hope this work may be useful to you and others.
>
>
> I have installed, but not gone live with a slightly different model.
> I don't know if it is interesting enough to be included in the draft ...
>
> Large enterprise network, mostly IPv6 dual-stack, but not on wireless.
> Staff wireless --> one /64 ISATAP subnet
> Student wireless --> different ISATAP subnet
> Staff and student wireless aren't geographically separate, so I can't split
> PRL by site.
> One pair of ISATAP gateways for staff advertise anycast 130.194.29.255/32
> One pair of ISATAP gateways for students advertise anycast
> 130.194.29.254/32
> PRL contains 130.194.29.255 and 130.194.29.254
>
> Separation managed by ACL inbound on ISATAP interface including
>     ...
>     permit ipv6 FE80::200:5EFE:317F:0/112 any
>     deny ipv6 FE80::200:5EFE:0:0/96 any
>     deny ipv6 FE80::5EFE:0:0/96 any
>     ...
> i.e. permit encapsulated RS's from ISATAP-mapped 49.127/16 but not from
> other IPv4 address ranges
>
>
> I like this method for logically partitioning an ISATAP link that is not
> physically partitioned. A similar method is covered in the third
> paragraph of Section 3.5, but your description augments what is
> already there. Please check the following to see if this looks like
> a worthwhile augmentation of that paragraph:
>
>   "When individual prefixes are used, site administrators can configure
>    advertising ISATAP routers to advertise different individual prefixes
> to
>    different sets of clients, e.g., based on the client's IPv4 subnet
> prefix.
>    (For example, administrators can configure each advertising ISATAP
>    router to provide services to some sets of ISATAP clients but not
>    others through inbound IPv6 Access Control List (ACL) entries that
>    discard encapsulated messages with certain ISATAP source addresses
>    based on the embedded IPv4 subnet prefix). When a shared prefix is
>    used, the site administrator could instead configure the ISATAP routers
>    to advertise the shared prefix to all clients."
>

Fine, except for the last sentence.
s/could/would/ ??
If a shared prefix is used, when would that shared prefix _not_ be
advertised to all clients.

>
>     John
>
>
> Thanks again for all of your great suggestions. Please let me know
> if this adequately addresses everything.
>
> Fred

=== New

I see that loop avoidance gets mentioned in sections 3.6 and 10.
How about more-generic address checking?

An ISATAP router SHOULD check all incoming encapsulated addresses to make
sure that the embedded IPv6 source address is valid --
link-local or global within the range of IPv4-mapped addresses for that
subnet.
An ISATAP router SHOULD check all IPv6 packets to be encapsulated to make
sure that the IPv6 destination address is valid --
link-local or global within the range of IPv4-mapped addresses for that
subnet, or multicast.
For SLAAC-assigned addresses in the shared prefix model above providing
services to 192.0.2.0/24, the valid addresses would be  fe80::5efe:
192.0.2.0/120 and 2001:db8::5efe:192.0.2.0/120 .

However, if Global IPv4 addresses are used, the ISATAP prefix is 0200:5efe::
rather than 0000:5efe:: see http://tools.ietf.org/html/rfc5214#section-6.1
Is 192.0.2.0/24 an example "global" or "private" address?
http://tools.ietf.org/html/rfc3330 doesn't say.

This question impacts the examples in this Draft, and elsewhere such as
http://tools.ietf.org/html/draft-ietf-v6ops-tunnel-loops-07#section-3.2.4.5
The "wisdom of crowds" is divided on this:
  Google search for "isatap fe80::200:5efe:C000" == 243 hits
  Google search for "isatap fe80::5ef5:C000" == 571 hits

My Cisco router seems to do the local/global bit wrong [ "????" and "####"
== address obfuscation. ]
---
Interface Tunnel9
 ipv6 address 2001:388:608C:????::/64 eui-64
 tunnel mode ipv6ip isatap
 ...

Tunnel9 is up, line protocol is up
Global unicast address(es):
    2001:388:608C:????:0:5EFE:82C2:####, subnet is 2001:388:608C:????::/64
[EUI]
---
The 82C2:#### mapped IPv4 address is 130.194.0.0/16 which is definitely
globally valid.

    John

>
> On 2 July 2011 08:54, Templin, Fred L <[email-masked]> wrote:
>
>> **
>> Hi Joel,
>>
>>  ------------------------------
>>  *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Templin, Fred L
>> *Sent:* Wednesday, June 22, 2011 8:13 AM
>> *To:* Joel Jaeggli
>>  *Cc:* [email-masked]
>> *Subject:* Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
>>
>>   Hi Joel,
>>
>>  ------------------------------
>> *From:* Joel Jaeggli [mailto:[email-masked]]
>> *Sent:* Friday, June 17, 2011 12:50 PM
>> *To:* Templin, Fred L
>> *Cc:* [email-masked]
>> *Subject:* Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?
>>
>> Replying to this message as a way to maintain the threading. these notes
>> are relative to the current version of the draft which I reviewed last week:
>>
>> So I tried for a while to separate the operational advice that could be
>> applied to my 2005 era knowledge of isatap and there's  quite a few things
>> that jive with that (tunnel loops for example).
>>
>> OK.
>>
>> In other cases such isatap dhcpv6 (4.5) I'm a bit-off in the weeds, what
>> implementations are capable of doing that? Are we recommending that they do
>> it? do they already?
>>
>> Are there participants with extant isatap deployements or host
>> implementations or knowledge fresher than mine that would care to comment on
>> this draft.
>>
>>
>> section 9 alternative approaches, there's some consensus that rfc 3056 was
>> never really deployed so the reference to 6to4 should probably be to 3068
>>
>>
>>
>> OK - I can fix this.
>>
>> Thanks - Fred
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Jul 2011 11:33:48 -0700

Hi John,

Thanks for this, and see below for follow-up:

________________________________
From: John Mann (ITS) [mailto:[email-masked]]
Sent: Wednesday, July 13, 2011 5:29 PM
To: [email-masked]
Cc: Templin, Fred L
Subject: Re: [v6ops] 'draft-templin-v6ops-isops' as v6ops wg item?

v6ops people,

On 14 July 2011 02:53, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi John,

________________________________
From: John Mann (ITS) [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, July 05, 2011 11:24 PM
To: Templin, Fred L

Fred,

1.  Introduction

s/RANGERS/RANGER/

Fine.

I would split this into

  "Smaller sites that wish to enable IPv6 can arrange to obtain public IPv6
   prefixes from an Internet Service Provider (ISP), where the prefixes may
   be either purely native or the near-native prefixes offered by 6rd [RFC5969].
   Alternatively, the site can obtain prefixes independently of an ISP e.g., via
   a tunnel broker [RFC3053], by using one of its public IPv4 addresses to
   form a 6to4 prefix [RFC3056][RFC3068], etc."

Please add something like
   Note that 6to4 is not recommended for new implementations [draft-ietf-v6ops-6to4-to-historic or draft-moore-6to4-experimental ],
and should be implemented with care [ draft-ietf-v6ops-6to4-advisory or RFC-new ].

I would really rather not fan the flames of the recent list discussions
on this subject, so would you be OK the following:

  "Note that experience shows that the 6to4 method has some problems in current
   deployments that can lead to connectivity failures [ draft-ietf-v6ops-6to4-advisory ]."

(Also, the advisory document already cites the historic document, so there
should be no need for citing it again in this document.)

   "Advertising ISATAP

"site-facing" isn't defined.  How many interfaces each router has is not defined.

 =>  Each advertising ISATAP router configures an site-internal interface as an ISATAP advertising router interface.

   "ISATAP hosts

=> Each ISATAP host configures an interface as a simple ISATAP host interface and ...

   may further have multiple ISATAP interfaces (i.e., one interface for each

   also coordinate their autoconfiguration operations with advertising ISATAP

I am a little bit confused here about the possibility that a host may be connected to a number of sites.
Take for example a host that connects to an IPv4 network where
the ISATAP service is deployed, and also VPNs into an IPv4
enterprise network where a separate ISATAP service is also deployed.
The host should be able to configure a first ISATAP interface
("is0") over the locally-connected IPv4 network interface and a
second ISATAP interface ("is1") over the VPN interface. That would
be two different ISATAP interfaces; each with its own associated set
of PRL routers, IPv6 prefixes, etc. It is up to the host as to how it
would keep the two different domains separate, but multiple ISATAP
host interfaces are indeed possible.
For the purposes of this document, is it useful to simplify the model a little:

| *IPv4 view* | *ISATAP view* | *Connectivity* | *Multi-site* |
| host | ISATAP host | connected to one ISATAP subnet | No |
| gateway | advertising ISATAP router | can connect to multiple ISATAP subnets | Possible |

Are you meaning to suggest any changes to the document?
3.3.  Reference Operational Scenario - Shared Prefix Model

I think this could be _slightly_ improved by being a bit more explicit when packets are encapsulated,
and whether they are sent to a host/routers IPv4 or IPv6 address.

" 'D' next performs an

I came up with a slightly different fix which I hope you will find
satisfactory. Rather than saying "using encapsulation" in multiple
places, I added the following new paragraph to Section 2:

  "After the PRL is published, ISATAP clients within the site can automatically
   perform unicast IPv6 Neighbor Discovery Router Solicitation (RS) / Router
   Advertisement (RA) exchanges with advertising ISATAP routers using
   IPv6-in-IPv4 encapsulation [RFC4861][RFC5214]. In the exchange, the
   IPv4 source address of the RS and the destination address of the RA are
   an IPv4 address of the client, while the IPv4 destination address of the RS
   and the source address of the RA are an IPv4 address of the server found in
   the PRL. Similarly, the IPv6 source address of the RS and the destination
   address of the RA are a link-local ISATAP address that embeds the client's
   IPv4 address, while the IPv6 destination address of the RS and the source
   address of the RA are a link-local ISATAP address that embeds the server's
   IPv4 address."

Then, everywhere else throughout the document, I simply say "RS/RA
exchange" rather than "IPv6-in-IPv4 encapsulated RS/RA exchange". Is
that OK with you?
===
Otherwise, excellent stuff.

Large enterprise network, mostly IPv6 dual-stack, but not on wireless.
Staff wireless --> one /64 ISATAP subnet
Student wireless --> different ISATAP subnet
Staff and student wireless aren't geographically separate, so I can't split PRL by site.
One pair of ISATAP gateways for staff advertise anycast 130.194.29.255/32<http://130.194.29.255/32>
One pair of ISATAP gateways for students advertise anycast 130.194.29.254/32<http://130.194.29.254/32>
PRL contains 130.194.29.255 and 130.194.29.254

i.e. permit encapsulated RS's from ISATAP-mapped 49.127/16 but not from other IPv4 address ranges

   advertising ISATAP routers to advertise different individual prefixes to
   different sets of clients, e.g., based on the client's IPv4 subnet prefix.

Fine, except for the last sentence.
s/could/would/ ??
If a shared prefix is used, when would that shared prefix _not_ be advertised to all clients.

Will "s/could/would".

    John

Fred

=== New

An ISATAP router SHOULD check all incoming encapsulated addresses to make sure that the embedded IPv6 source address is valid --
link-local or global within the range of IPv4-mapped addresses for that subnet.
An ISATAP router SHOULD check all IPv6 packets to be encapsulated to make sure that the IPv6 destination address is valid --
link-local or global within the range of IPv4-mapped addresses for that subnet, or multicast.
For SLAAC-assigned addresses in the shared prefix model above providing services to 192.0.2.0/24<http://192.0.2.0/24>, the valid addresses would be  fe80::5efe:192.0.2.0/120<http://192.0.2.0/120> and 2001:db8::5efe:192.0.2.0/120<http://192.0.2.0/120> .

This looks like potential new material for the tunnel-loops document,
however any intentional or unintentional abuse of the embedded IPv4
address field would already be nullified by the RFC5214, Section 10
recommendation that site border rotuers implement ip-protocol-41
filtering. In other words, any packets with addresses with an IPv6 prefix
specific to the local site but an embedded IPv4 address prefix specific
to some other site would be dropped by a site border router (and
possibly logged).
However, if Global IPv4 addresses are used, the ISATAP prefix is 0200:5efe:: rather than 0000:5efe:: see http://tools.ietf.org/html/rfc5214#section-6.1

That's not *exactly* what the spec says. The spec says "When the IPv4
address is known to be globally unque ...". But, no implementation can
ever know for sure that the IPv4 address is globally unique without some
global form of duplicate address detection. Indeed, the spec goes on to
say that: "...ISATAP nodes are not required to validate the interface
identifiers created with modified EUI-64 tokens with the "u" bit set to
universal are unique".
Is 192.0.2.0/24<http://192.0.2.0/24> an example "global" or "private" address? http://tools.ietf.org/html/rfc3330 doesn't say.

My Cisco router seems to do the local/global bit wrong [ "????" and "####" == address obfuscation. ]
---
Interface Tunnel9
 ipv6 address 2001:388:608C:????::/64 eui-64
 tunnel mode ipv6ip isatap
 ...

Tunnel9 is up, line protocol is up
Global unicast address(es):
    2001:388:608C:????:0:5EFE:82C2:####, subnet is 2001:388:608C:????::/64 [EUI]
---
The 82C2:#### mapped IPv4 address is 130.194.0.0/16<http://130.194.0.0/16> which is definitely globally valid.
I suspect the cisco router simply sets u/l to 0 always when it
configures its ISATAP link-local address and ignores the u/l bit
on receipt - which seems like a reasonable interpretation of the
spec. Hindsight being 20/20, it probably would have been better
had the spec said to simply set the u/l bit to 0 in all cases.

Do any implementors have anything to add wrt this?

Fred

    John

On 2 July 2011 08:54, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Hi Joel,

The new piece is now called: "ISATAP Updates" and I guess might
be more appropriate for some other working group. The other piece
retains the original name and is strictly about operational
aspects
of widely-deployed implementations:

Thanks - Fred

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Templin, Fred L

Hi Joel,

From: Joel Jaeggli [mailto:[email-masked]<mailto:[email-masked]>]

Hello,

Thanks - Fred

OK - I can fix this.

Thanks - Fred

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Jul 2011 10:15:27 -0700

Hi John,

Regarding your message from 7/14/2011:

http://www.ietf.org/mail-archive/web/v6ops/current/msg09637.html

I have posted a new draft version which which contains
a number of updates based on our discussions. Please see
below for the I-D announcement, and let me know if this
satisfies the concerns.

Thanks - Fred

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, July 27, 2011 9:40 AM
To: [email-masked]
Subject: I-D Action: draft-templin-v6ops-isops-13.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Operational Guidance for IPv6 Deployment in IPv4 Sites using ISATAP
	Author(s)       : Fred L. Templin
	Filename        : draft-templin-v6ops-isops-13.txt
	Pages           : 21
	Date            : 2011-07-27

   Many end user sites in the Internet today still have predominantly
   IPv4 internal infrastructures.  These sites range in size from small
   home/office networks to large corporate enterprise networks, but
   share the commonality that IPv4 continues to provide satisfactory
   internal routing and addressing services for most applications.  As
   more and more IPv6-only services are deployed in the Internet,
   however, end user devices within such sites will increasingly require
   at least basic IPv6 functionality for external access.  This document
   therefore provides operational guidance for deployment of IPv6 within
   predominantly IPv4 sites using the Intra-Site Automatic Tunnel
   Addressing Protocol (ISATAP).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-templin-v6ops-isops-13.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-templin-v6ops-isops-13.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt