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

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:
> Thanks Karsten, I look forward to your review.
> 
> Best regards,
> Ole
> 
> > On 12 Jan 2015, at 12:52 , Karsten Thomann 
<[email protected]>
> > 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 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:
> > > 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 protected] in CC.
> > > 
> > > Best regards,
> > > Ole
> > > 
> > > --------------------------------------------------------------------
> > > IETF IPv6 working group mailing list
> > > [email protected]
> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > > --------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------