Subject: RE: mech-v2-05pre

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Wed, 25 Aug 2004 10:58:25 +0200

Hi Pekka,

Thanks. Now I understand what you want to say.

Personally, I would prefer the long explanation though.

I find, as Alex, the following formulation under Configured tunnelling
in Section 1.1. of 05 to be confusing:

"All tunnels are assumed to be
 bidirectional, behaving as virtual point-to-point links
between the IPv4 tunnel endpoint addresses"

as it speaks about a IPv6 layer logical link, namely the
point-to-point link, which connects two IPv4 addresses.

Further in its nature of trying to say many things at the same time
it is not entirely clear from this formulation whether
the IPv6 tunnel link is indeed considered to be a true IPv6 point-to-point link
in the terms of the definition from 2461. And I think that I would
like that to be spelled out more clearly.

I would thus suggest to say something like the following:

 Configured tunnelling:

                IPv6-over-IPv4 tunnelling where the IPv4 tunnel endpoint
                address(es) are determined by configuration information
                on tunnel endpoints.  All tunnels are assumed to be
                bidirectional.  At the IPv6 layer the tunnel provides
                a virtual point-to-point link, the lower layer endpoints 
                of which are the IPv4 tunnel endpoint addresses 

An additional issue (really minor - may be ignored)
that I have with 05 is the second last paragraph 
on page 6:

"In configured tunnelling, the tunnel endpoint address is determined
   from configuration information in the encapsulator.  For each tunnel,
   the encapsulator must store the tunnel endpoint address.  When an
   IPv6 packet is transmitted over a tunnel, the tunnel endpoint address
   configured for that tunnel is used as the destination address for the
   encapsulating IPv4 header."

Reading this I can't help wondering - "and what about the source address ?".
It would be good for completeness also to say where the source address comes from, if nothing else then simply by adding a reference to a place in the doc, where this is specified.

BR, Karen

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Wednesday, August 25, 2004 10:03 AM
> To: Karen E. Nielsen (AH/TED)
> Cc: Alex Conta; [email-masked]
> Subject: RE: mech-v2-05pre
> 
> 
> On Wed, 25 Aug 2004, Karen E. Nielsen (AH/TED) wrote:
> > Wrt the definition of the point-to-point link concept for 
> IPv6  - then
> > RFC 2461, Section 2.2,  states:
> > 
> >   "point-to-point - a link that connects exactly two interfaces.  A
> >                     point-to-point link is assumed to have multicast
> >                     capability and have a link-local address."
> > 
> > When using the term "point-to-point links" in section 3.8 
> of mech-v2, 
> > I have always assumed the above definition to be the one 
> referred to - ?
> 
> Yes, that's how sect 3.8 uses Neighbor Discovery. I don't see a
> conflict.  The goal of that definition is to define point-to-point for
> higher layers.  We want to give a clear statement on what the
> point-to-point is from the perspective of the lower layers.
> 
> The quote says p2p connects two interfaces.  That's OK, but that
> refers (in this case) to the logical IPv6 tunnel interfaces, not the
> physical underlying interfaces which are not necessarily even
> IPv6-capable.
> 
> What we want to say is that the v6 link is a virtual point-to-point as
> defined in above, and the lower layer endpoints of that p2p link are
> the v4 addresses which are configured on the endpoint nodes' physical
> interfaces. [and specifically, the lower layer endpoints aren't just 
> any addresses on the endpoint nodes, rather the specific v4 addresses]
> 
> But that seems way too confusing way to put it, so just saying
> "virtual p2p between v4 addresses" seems shorter and sufficiently
> clear.
> 
> -- 
> 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: Pekka Savola <[email-masked]>
Date: Wed, 25 Aug 2004 12:21:04 +0300 (EEST)

Hi,

We seem to be getting close to being done; I'd like to submit the 
drafts today and conclude this discussion:

http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05rc.txt
http://www.netcore.fi/pekkas/ietf/temp/draft-ietf-v6ops-mech-v2-05rc-diff.html

>                 of which are the IPv4 tunnel endpoint addresses 

OK -- I tweaked it a bit to:

        Configured tunneling:

                IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
                address(es) are determined by configuration information
                on tunnel endpoints.  All tunnels are assumed to be
                bidirectional.  At the IPv6 layer the tunnel provides a
                (virtual) point-to-point link, the lower layer endpoints
                of which are the configured IPv4 addresses.

> Reading this I can't help wondering - "and what about the source
> address ?". It would be good for completeness also to say where the
> source address comes from, if nothing else then simply by adding a
> reference to a place in the doc, where this is specified.

It's hinted at in the last paragraph of that section, and in section 
3.5, so I reworded the paragraph to:

   In configured tunneling, the tunnel endpoint addresses are determined
   in the encapsulator from configuration information stored for each
   tunnel.  When an IPv6 packet is transmitted over a tunnel, the
   destination and source addresses for the encapsulating IPv4 header
   are set based on that information as described in Section 3.5.

---

From: Alex Conta <[email-masked]>
Date: Thu, 26 Aug 2004 18:55:26 -0400

Pekka Savola wrote:
> Hi,[...]
>[...]
> [...]

I sent, earlier today a suggestion which just has to be adapted to the 
new text.

Regards,
Alex