Subject: Request to Advance "Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks"

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 00:29:45 +0300 (EEST)

David,

On behalf of the v6ops WG, we'd like to request that the following
document be published as Informational RFC:

Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-unmaneval-03.txt

The first WG last call was completed on 26th February.  -02 version
was published, and a one-week WGLC held which ended on 30th May;  
only one person responded with minor nits, and those have been fixed
in -03.

Thanks,
 Pekka & Jonne
 v6ops WG co-chairs

---

From: Fred Templin <[email-masked]>
Date: Thu, 03 Jun 2004 16:31:15 -0700

Not sure what the procedure is here, but I just noticed that this document
fails to mention [ISATAP] as an applicable automatic tunnel mechanism
(without NAT traversal) for unmanaged networks.

[ISATAP] is needed for host-to-host and host-to-router interactions
within unmanaged networks - especially accross bridges, ND proxies,
multi-link subnets, etc.

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 12:13:45 +0300 (EEST)

> within unmanaged networks - especially accross bridges, ND proxies,

(without any hats)

Good point -- I don't think ISATAP has been discussed to be used
*within* an unmanaged network.

I personally think this is probably of very marginal applicability, as
the unmanaged networks are very small (typically only one subnet or
link), with about one router.  Further, the links almost always used
inside an unmanaged network are able to support IPv6.  

So, it would seem that ISATAP might make sense here either if 

1) the gateway supported IPv6 but the links wouldn't, or

2) the gateway wouldn't support IPv6, but the nodes in a multi-link
unmanaged network would want to use IPv6 between each other.

Both cases seem very marginal to me.

Hence, I personally don't think it is necessary to include ISATAP
here.  (Remember that so-called [multi-hop] ad-hoc networks, where
this would possibly be more strongly arguable for, were considered out
of scope for the v6ops scenarios work, AFAIR.)

And since we're already past WG last call(s), this is probably a moot
point in any case..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Tim Chown <[email-masked]>
Date: Fri, 4 Jun 2004 10:31:50 +0100

I was just about to post with pretty much what Pekka said.

I would support a comment in the draft saying why ISATAP is not so applicable
here (and unmanaged usally implies single link, and no managed networking
within the SOHO site).   The comment could point to the enterprise analysis
where ISATAP (I hope!) will be soundly included as a tool for disparate nodes
in a large site.

Otherwise the reader may think "but what about ISATAP?".

Tim

---

From: "Soininen Jonne (Nokia-NET/Helsinki)" <[email-masked]>
Date: Fri, 04 Jun 2004 16:17:17 +0300

Hello everybody,

(chair hat on)
there has been a lot of time to comment on this draft (years) and this
has not come up. We have concluded that the draft is good enough to go
to the IESG and it has been submitted. I don't think this is such an
important issue that we would recall the draft from the IESG.

However (ok here we go ;), there is always the IETF last-call. Comments
can be made to the document during the IETF last-call and you are not
too late for that. 

Summary: If you think this is that important issue in the draft that it
really does need changing, you can give the comments during the IETF
last-call. (Well, basically everybody can!) 

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: Fred Templin <[email-masked]>
Date: Fri, 04 Jun 2004 11:52:49 -0700

Hi Pekka,

>*within* an unmanaged network.

Inserting more careful phrasing, I believe there may be two
aspects of the question to consider:

 1) Near-term implications for connecting hosts and routers
    within an unmanaged network using [ISATAP].

 2) Somewhat longer-term implications for connecting hosts
    within an unmanaged network to hosts/routers in the Internet
    using [ISATAP] over a virtual link extended via ND Proxy,
    multi-link subnet, hybrid bridge/router, etc. (i.e., with no
    "traditional" NAT traversal needed).

The phrasing in my original message appears to have focused
your reply on 1) only, which I think is fine for now since it seems
to be the proper scope for the current analysis in [unmaneval-03].

>unmanaged network would want to use IPv6 between each other.

I am not an expert in the unamanged network transition space, but it seems
that we are beginning to see heterogeneous link technologies in home/SOHO
applications that are not easily bridged. ([unmaneval-03], sections 
4.1.1 and 7)
provide good analysis and recommendations on extending a subnet to span
multiple links, but provide no guidance on mechanisms to connect nodes
accross such an extended subnet when link technologies with disparate MAC
address formats and/or link MTUs are included. Both of these conditions
could be mitigated by IPv6-in-IPv4 encapsulation using ISATAP, but this
is not currently stated in the document.

>Both cases seem very marginal to me.

Well again, I am no expert, but from a recent trip to Fry's (our local
electronics mega-store) it seems that general-purpose computers are
now providing features like Digitial Video Recording that were once
implemented only in set-top boxes, and home electronics like TV's,
cameras, DVDs, etc. are now providing LAN-like interconnects
(e.g., IEEE 1394) that were once used only by computers.

So, it seems like we may be on the near-term cusp of a fusion of
technologies and interconnects within the unmanaged realm that
may not be so marginal after all.

>of scope for the v6ops scenarios work, AFAIR.)

I agree that there is no need to visit the multi-hop ad-hoc paradigm
to identify potential near-term use cases.

>point in any case...

I'm not so sure; ([unmaneval-03], sections 4.1.1 and 7) give analysis and
recommendations on how to _extend_ a subnet to span multiple links
but no analysis and recommendations on mechanisms that nodes can
use to _traverse_ such an extended subnet. I believe ISATAP fits this
space for the near-term at least, with potential for wider applicability
in the somewhat longer term as described above.

Also FYI, there appears to be a typo in: ([unmaneval-03], section 5),
first sentence of the 2nd paragraph. Here, it seems like "case B"
should be changed to: "case C".

Thanks - Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Fri, 04 Jun 2004 12:19:27 -0700

Hi Tim,

>I was just about to post with pretty much what Pekka said.

OK. I just replied to Pekka's message on this.

>within the SOHO site).

Well, based on my message to Pekka I believe there may be some near-term
applicability and also somewhat longer term applicability to be considered
for the unmanaged case. (We have also seen the near-term need for a simple
host-router mechanism in the 3GPP case, and ISATAP has been mentioned
as a candidate there.)

>The comment could point to the enterprise analysis

I agree that ISATAP seems like a natual fit for the enterprise, so
I believe I can speak for my co-authors in saying that we intend to
continue to pursue standards-track status for ISATAP over the
somewhat longer term, e.g., as the enterprise analysis evolves.

>Otherwise the reader may think "but what about ISATAP?".

Agreed.

Fred
[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Fri, 04 Jun 2004 12:28:26 -0700

Thanks Jonne, for explaining the pragmatic aspects of this 11th-hour input.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 8 Jun 2004 14:33:16 +0300 (EEST)

(Trimmed Cc: list)

> to be the proper scope for the current analysis in [unmaneval-03].

You said '*within* unmanaged networks' (emphasis mine), and as the 
ISP's network is hopefully managed, I took it to mean you were only 
referring to 1).

I'm not quite sure what you mean by 2).  There has been no consensus
(as far as I could see) for including ISATAP for 2) in the context of
obtaining IPv6 connectivity from the ISP or communicating between the
customers of the ISP.  But trying to read the issue 2) you note above 
carefully, I think you're referring to something slightly different 
(but not sure).   If so, could you clarify a bit?
 
> I am not an expert in the unamanged network transition space, but it
> seems that we are beginning to see heterogeneous link technologies
> in home/SOHO applications that are not easily bridged.
> ([unmaneval-03], sections 4.1.1 and 7) provide good analysis and
> recommendations on extending a subnet to span multiple links, but
> provide no guidance on mechanisms to connect nodes accross such an
> extended subnet when link technologies with disparate MAC address
> formats and/or link MTUs are included. Both of these conditions
> could be mitigated by IPv6-in-IPv4 encapsulation using ISATAP, but
> this is not currently stated in the document.

Is there evidence of such heterogenous environments emerging where
different link MTUs would be used, or different format of MAC
addresses which could not be proxied? I'm not an expert on unmanaged
networks either, but I think these are a bit more futuristic scenarios
(and all of these non-problems if a router is used instead of a
bridge/proxy).

But let's step back a bit.  How this would be helped by using ISATAP?  
Link MTU problem could potentially be affected somehow (but that's 
probably not a big problem in any case), but I don't see how different 
format of MAC addresses would change the situation -- it wouldn't be 
possible to interconnect those boxes with IPv4 either, you'd have to 
have an IPv4 router or NAT box in the middle -- and it wouldn't help.
[...]
> in the somewhat longer term as described above.

Traversing such an extended subnet can be done by the same mechanism
as extending it, AFAICS -- except if there are disallow traversing
with bigger packets than used for extending (1500 bytes for example).  
But these are addressed e.g., by ND proxies already by sending Pkt Too
Big messages, so I'm not sure what is the exact problem here.
 
> should be changed to: "case C".

Good catch -- thanks!