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

[Fred Templin <ftemplin@iprg.nokia.com>]

Hi Pekka,

Pekka Savola wrote:

> On Thu, 3 Jun 2004, Fred Templin wrote:
>  
>
> > 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.
> >    
>
> (without any hats)
>
> Good point -- I don't think ISATAP has been discussed to be used
> *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].

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

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.

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

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

> And since we're already past WG last call(s), this is probably a moot
> 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
ftemplin@iprg.nokia.com