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

Re: mech-v2-05pre



Running ND on a 6to4 tunnel doesnt quite make sense. Maybe we should think
of revising RFC 3056

----- Original Message ----- 
From: "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>
To: "'Brian E Carpenter'" <brc@zurich.ibm.com>; "'Pekka Savola'"
<pekkas@netcore.fi>; <v6ops@ops.ietf.org>
Sent: Wednesday, August 25, 2004 2:54 PM
Subject: RE: mech-v2-05pre


> Hi Brian, Pekka, All
>
> (Pekka, you're explicitly addressed here in your capacity as mech-v2
editor.)
>
> Now that we are discussing mech-v02 I wonder if I can take the chance
> to take up an issue which have bothered me for some time.
>
> Mech-v2 concerns configured bi-directional IPv6-in-IPv4 tunnels. These
> tunnels are point-to-point links in terms of RFC 2461 and mech-v02 talks
> about the behaviour of IPv6 ND mechs, NUD in particular, over these
tunnels.
>
> Now, 6to4, RFC 3056 in Section 3.1 refers to RFC 2893 for how NUD should
be handled
> on 6to4 pseudo interfaces.
>
> When we made our implementation of 6to4 a while back we interpreted
> this as to refer to what in RFC 2893, Section 3.8,
>  was said about unidirectional tunnels, because although 6to4 tunnels
> may in some senses be considered bidirectional
> they are not point-to-point links in the terms of RFC 2461,
> as link-local multicast isn't supported.
>
> Now, some people have let me know that this may not be the correct
interpretation of what
> was intended to be said in Section 3.1 of RFC 3056, and this certainly
complies well with the fact that the unidirectional part of RFC 2893 is
being deprecated.
>
> But it still makes me wonder what then is the intend of what is being said
in section 3.1
> of RFC 3056 and how to handle this reference now that Section 3.8 of
mechv02 explicitly
> refers to the point-to-point link capacity of the tunnel link - ?
>
> I apologize in advance if this has been discussed at length in the early
stages
> of the work on mech-v2.
>
> Thanks, Karen
>
>