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

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

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