Subject: 6MAN cross-wg review: draft-ietf-l2tpext-keyed-ipv6-tunnel-01

From: Ole Troan <[email-masked]>
Date: Tue, 6 Jan 2015 12:14:14 +0100

Hi,

The chairs of l2tpext have asked for a 6man review of:

Title: Keyed IPv6 Tunnel
https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-01

Can we get a couple of volunteers please? As well as any other comments to the lists are welcome of course.
Please keep [email-masked] in CC.

Best regards,
Ole

---

From: 神明達哉 <[email-masked]>
Date: Wed, 7 Jan 2015 11:08:01 -0800

At Tue, 6 Jan 2015 12:14:14 +0100,

>From a quick read of the draft, my only comment is this:

- In Section 4:

   o  Hop Limit.  Set to 0xFF, and decremented by one by each router in
      the path to the egress router.

What's the rationale of 0xFF (the possible maximum hop limit)?  It's
way too large compared to other general cases, and it's not
immediately clear how the L2TP usage is different.

As for volunteering to do a 6man review: if there's no other (or
enough) volunteer who is more familiar with the underlying topic, I'm
willing to spend my time for it.  But I'm afraid I'll not be able to
provide very useful feedback due to lack of my understanding of the
background technology (as it's suggested by the fact that my only
comment so far is the above one).  I'm stating this anyway as I've not
seen any public response to the request yet, but if there are already
volunteers who replied offlist, please just ignore this paragraph.

--
JINMEI, Tatuya

---

From: Karsten Thomann <[email-masked]>
Date: Mon, 12 Jan 2015 12:52:31 +0100

As Jinmai already wrote, I can volunteer, but only under the same constrains, as I have no prior 
experience with reviews.

Some comments:
I know it is also written in RFC4719, but why was "or" used at "Ethernet frame, without the 
preamble or frame check sequence (FCS)".
At the payload section is "and" used...
"As noted above preamble and FCS are stripped before encapsulation."

As already written by Jinmai, the hop limit is with 255 as a default setting a bit high, a default of 
64 should be high enough for nearly all cases.

Kind regards
Karsten

Am Dienstag, 6. Januar 2015, 12:14:14 schrieb Ole Troan:
> Can we get a couple of volunteers please? As well as any other comments to
> the lists are welcome of course. Please keep [email-masked] in CC.
> 
> Best regards,
> Ole
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Jan 2015 09:59:28 +0100

Thanks Karsten, I look forward to your review.

Best regards,
Ole

> On 12 Jan 2015, at 12:52 , Karsten Thomann <[email-masked]> wrote:
> 
> As Jinmai already wrote, I can volunteer, but only under the same constrains, as I have no prior experience with reviews.
>  
> Some comments:
> I know it is also written in RFC4719, but why was "or" used at "Ethernet frame, without the preamble or frame check sequence (FCS)".
> As already written by Jinmai, the hop limit is with 255 as a default setting a bit high, a default of 64 should be high enough for nearly all cases.
>  
> Kind regards
> Karsten
>

---

From: Karsten Thomann <[email-masked]>
Date: Thu, 22 Jan 2015 15:50:19 +0100

Hi,

my comments about the draft:
1. As far as I know the IETF processes this must be a standards track draft 
instead of a informational, as it not only simplifies the tunnels like 
removing the control plane, but uses MUST where the L2TPv3 RFC only set 
it as optional (e.g. Cookie).

2. In my opinion the terms key, cookie and authentication key for the 
required 64bit cookie should be cleaned up, as the terms have in some 
context of the rfc the same meaning

3. Why is the explicit value for the hop limit mentioned? In my opinion it 
should be lower, or are there any implementations which really use that 
value as a default? Should be rewritten to something without a fixed hop 
limit

4. Is there any reason to not use src + dst ip for all cases instead to only 
use it for the case that the local ip is used for more than one tunnel?
I think every device should know from which IPs it receives packets for a 
specific local l2tp ip as the cookie must be configured and should be 
unique per tunnel.

5. I didn't understand the meaning of the last sentence:
   o  Payload.  The customer data, with s-tag or s-tag/c-tag removed.
      As noted above preamble and FCS are stripped before encapsulation.
      A new FCS will be added at each hop when the IP packet is
      transmitted.
There is no relation between the routing of the l2tp packet and the 
payload FCS, as there is no FCS in the payload.
6. I'm not sure if it should be added to the security considerations section, 
but in RFC 3931 it is mentioned that there are no checksums for the 
packets as ipv6 and l2tp have none. I know it was especially mentioned for 
the control packets, but it also applies to all other packets with payload.

Regards
Karsten

Am Dienstag, 13. Januar 2015, 09:59:28 schrieb Ole Troan:
> > On 12 Jan 2015, at 12:52 , Karsten Thomann 
<[email-masked]>
> > wrote:
> > 
> > As Jinmai already wrote, I can volunteer, but only under the same
> > constrains, as I have no prior experience with reviews.
> > 
> > Some comments:
> > I know it is also written in RFC4719, but why was "or" used at "Ethernet
> > frame, without the preamble or frame check sequence (FCS)". At the
> > payload section is "and" used...
> > As already written by Jinmai, the hop limit is with 255 as a default
> > setting a bit high, a default of 64 should be high enough for nearly all
> > cases.
> > 
> > Kind regards
> > Karsten
> > 
> > > Can we get a couple of volunteers please? As well as any other 
comments
> > > to