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

["Templin, Fred L" <[e-mail]>]

Hi John,

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

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

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 <[e-mail]<mailto:[e-mail]>> wrote:
Hi John,

Thanks again for the comments, and see below for proposed
resolutions:

________________________________
From: John Mann (ITS) [mailto:[e-mail]<mailto:[e-mail]>]
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 ].

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

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

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.

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.

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.

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

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.

Will "s/could/would".

    John

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

Fred
[e-mail]<mailto:[e-mail]>


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

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<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 <[e-mail]<mailto:[e-mail]>> wrote:
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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Templin, Fred L
Sent: Wednesday, June 22, 2011 8:13 AM
To: Joel Jaeggli
Cc: [e-mail]<mailto:[e-mail]>
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:[e-mail]<mailto:[e-mail]>]
Sent: Friday, June 17, 2011 12:50 PM
To: Templin, Fred L
Cc: [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>


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
[e-mail]<mailto:[e-mail]>

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