[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



(Trimmed Cc: list)

On Fri, 4 Jun 2004, Fred Templin wrote:
> >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].

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

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

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

Good catch -- thanks!

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