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

["John Mann (ITS)" <[e-mail]>]

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

> **
> Hi John,
>
> Thanks again for the comments, and see below for proposed
> resolutions:
>
>  ------------------------------
> *From:* John Mann (ITS) [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 ].


>     "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
> [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, 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 <[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]] *On
>> Behalf Of *Templin, Fred L
>> *Sent:* Wednesday, June 22, 2011 8:13 AM
>> *To:* Joel Jaeggli
>>  *Cc:* [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]]
>> *Sent:* Friday, June 17, 2011 12:50 PM
>> *To:* Templin, Fred L
>> *Cc:* [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]
>>
>>
>> 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]
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>