Subject: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03

From: Suresh Krishnan <[email-masked]>
Date: Tue, 14 Jan 2014 04:46:16 +0000

Hi all,
   This message starts a two week softwire working group last call on 
advancing the draft about Lightweight 4over6 as a Standards Track RFC. 
The authors believe that this version has addressed all the issues 
raised on the document till now. The latest version of the draft is 
available at

http://www.ietf.org/id/draft-ietf-softwire-lw4over6-03.txt
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-03

Substantive comments and statements of support/opposition for advancing 
this document should be directed to the mailing list. Editorial 
suggestions can be sent directly to the authors. This last call will 
conclude on January 28, 2014.

Regards,
Suresh & Yong

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Jan 2014 08:19:12 +0100 (CET)

> conclude on January 28, 2014.

I have re-read this document in its entirety, and found two things I would 
like to have discussed.

The fragmentation handling needs more guidance. 5.2.1. says:

"On receiving an encapsulated packet containing an IPv4 fragment, the
    lwB4 MUST wait until all other fragments have been received and de-
    capsulated."

What happens if one of the fragments are lost? I would believe there is 
work to be referenced when it comes to handling fragmentation, and the 
document would be better guidance if that was referenced.

Also:

"When an lwB4 receives an IPv4 packet from its connected host that is
    larger than the MTU size after encapsulation, the lwB4 MUST fragment
    the IPv4 packet before encapsulation."

If the DF flag is set, the packet shouldn't be fragmented, instead PMTUD 
mechanism should be honored. Right? Fragmenting an IPv4 packet with DF bit 
set sounds like a bad thing.

Now, going on to ICMP handling.

The wording in section 8 at least to me could read like an implementor 
could implement "drop all ICMP on the outside interface" and say they've 
complied to the SHOULD in the second paragraph. I think the logic in 
section 8 should be that an implementor SHOULD implement 1, 2 and 3, and 
if they don't, then they SHOULD drop all ICMP. Right now it's SHOULD for 
(1-3 OR drop). I don't think the "drop" option should be in the initial 
SHOULD. So wrapping 1-3 in the initial SHOULD, and then say alternative to 
this is to drop.

Also, the RFC6269 reference, RFC6269 is an informational issues document, 
it doesn't give guidance to implementors on how to solve the problem 
(right?). In the next-to-last paragraph there is guidance to how to solve 
the problem. I think the better way would be to bring up the 
second-to-last paragraph of section 8 to between paragraph 1 and 2, and 
then look at what the 3 bullet points says and if they're mentioned in 
RFC5508 and if they are, just point to RFC5508 instead. So the flow would 
be RFC6269 points out the problem, to solve it, implementor SHOULD 
implement 5508, and then have the current "either/or" sections say what's 
specific to lw4o6, and have a last entry to say that if proper ICMP 
handling isn't implemented at all, SHOULD drop the packet.

So to sum up above, section 8 seems to me to contain enough information, I 
would just like to see it structured in a different way/order and the 
logic checked so implementors do the right thing. Right now I find it a 
bit hard to understand.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Simon Perreault <[email-masked]>
Date: Thu, 16 Jan 2014 09:17:36 -0500

> document would be better guidance if that was referenced.

You're right, the advice in the text is wrong, if only because it's 
possible to do it correctly without waiting for all fragments (e.g., 
what Cisco calls "virtual reassembly").

We need to keep in mind that fragmentation and reassembly issues 1) are 
very complex, 2) apply to a ton of protocols in addition to lw4o6, 3) 
there's more than one way to do it, and 4) there's no one true way to do 
it, they all suck a little in different ways.

My suggestion would be to steal the very carefully written text from RFC 
6146, page 19.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Branimir Rajtar <[email-masked]>
Date: Thu, 16 Jan 2014 15:46:44 +0000

> set sounds like a bad thing.

One more thing I find puzzling - RFCs 2473 and 6333 state that you have to encapsulate the packet first into IPv6 and if it exceeds the IPv4-in-IPv6 tunnel MTU, fragment the IPv6 packet. This draft states the opposite thing, if the encapsulated packet is larger than the tunnel MTU, you have to fragment IPv4 and then encapsulate it into IPv6. In my opinion, the simpler thing to do would be to encapsulate first and fragment afterwards.

I think this is also a problem because RFC 6333 describes fragmentation only from the AFTR's viewpoint and this draft describes it from the B4's viewpoint. Since this draft refers to RFC6333 for fragmentation, it would mean that the lwAFTR and lwB4 would have different fragmentation logic.

Branimir

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 16 Jan 2014 18:59:29 +0100 (CET)

On Thu, 16 Jan 2014, Branimir Rajtar wrote:

> One more thing I find puzzling - RFCs 2473 and 6333 state that you have 
> to encapsulate the packet first into IPv6 and if it exceeds the 
> IPv4-in-IPv6 tunnel MTU, fragment the IPv6 packet. This draft states the 
> opposite thing, if the encapsulated packet is larger than the tunnel 
> MTU, you have to fragment IPv4 and then encapsulate it into IPv6. In my 
> opinion, the simpler thing to do would be to encapsulate first and 
> fragment afterwards.

You really really want to avoid having fragmented IPv6 packets on the 
wire if you can. Yes, I guess this might be ok since this is in within the 
provider network so they can control forwarding performance of fragmented 
IPv6 packets, but having the lwAFTR do re-assembly for most traffic is 
just bad for performance. We really really want to give guidance that 
avoids fragmentation regardless of where it happens.

> I think this is also a problem because RFC 6333 describes fragmentation 
> only from the AFTR's viewpoint and this draft describes it from the B4's 
> viewpoint. Since this draft refers to RFC6333 for fragmentation, it 
> would mean that the lwAFTR and lwB4 would have different fragmentation 
> logic.

It would be good if there was clarification on both aspects I believe.

---

From: Ole Troan <[email-masked]>
Date: Thu, 16 Jan 2014 21:27:04 +0100

Branimir,

> One more thing I find puzzling - RFCs 2473 and 6333 state that you have to encapsulate the packet first into IPv6 and if it exceeds the IPv4-in-IPv6 tunnel MTU, fragment the IPv6 packet. This draft…

RFC4459 gives a good analysis of the problem.

> I think this is also a problem because RFC 6333 describes fragmentation only from the AFTR's viewpoint and this draft describes it from the B4's viewpoint. Since this draft refers to RFC6333 for fr…

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jan 2014 16:10:16 -0500

All,

I re-read the draft carefully. I noticed two issues:

1. Section 5.1:

>    An IPv6 address from an assigned prefix is also required for the lwB4
>    to use as the encapsulation source address for the softwire.  In
>    order to enable end-to-end provisioning, the IPv6 address is
>    constructed by taking the /64 prefix assigned to the WAN interface

What happens if there is more than one prefixes assigned to the WAN 
interface?

If that case results in undefined behaviour (fine by me), it needs to be 
stated in the text.

2. See other mails about section 5.2.1.

And a minor suggestion:

>    The DNS considerations described in Section 5.5 and Section 6.4 of
>    [RFC6333] SHOULD be followed.

This SHOULD is suspicious. Suggestion: s/SHOULD be followed/also apply/

Simon

---

From: <[email-masked]>
Date: Tue, 21 Jan 2014 10:19:29 +0100

Hi Simon,

Thanks for the comments. Please see inline.

Cheers,
Ian

>If that case results in undefined behaviour (fine by me), it needs to be

[ian] More than one prefix (of the same scope) is a pretty likely case
here. Behaviour does need to be defined, as if the wrong prefix is
selected for the source v6 encapsulation address, then it¹s going to be
discarded by the lwAFTR, for some provisioning methods at least.. Suggest
that we update to make this clear.

>This SHOULD is suspicious. Suggestion: s/SHOULD be followed/also apply/

[ian] Will update.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Jan 2014 09:11:35 -0500

> [ian] More than one prefix (of the same scope) is a pretty likely case

What do you mean by "scope"?

> that we update to make this clear.

I'm not following you. If the CPE picks the "wrong" prefix, sets up its 
tunnel interface, then sends packets on it, they will get discarded by 
the lwAFTR. How does the CPE handle this? How does it figure out which 
one is the "right" prefix? How do we go from "the Internet doesn't work" 
to "the Internet works"?

Thanks,
Simon

---

From: <[email-masked]>
Date: Tue, 21 Jan 2014 16:25:26 +0100

Hi Simon,

>What do you mean by "scope"?

[ian] RFC4007 scope.

>one is the "right" prefix? How do we go from "the Internet doesn't work"

[ian] The current text describes how the CPE creates the /128 prefix to
use as its tunnel endpoint (when its provisioned with DHCPv6). This prefix
has been constructed using an existing /64 prefix and a suffix that has
been learnt through the v4 configuration information in OPTION_S46_LW4o6.
The CPE can’t try and build a tunnel until it has received all of these
parameters, as it wouldn’t have a tunnel endpoint address for the lwAFTR
either.

So, it learns the parameters over DHCPv6, creates the tunnel source /128
based on these parameters and builds the tunnel from there. In all
likelihood, there is also a SLAAC or IA_NA address on also that interface,
but as the lw4o6 client is configuring the source prefix as well as
building the tunnel, the right prefix is the one that its just configured.

Is the current text not conveying this, or do you think that there’s
something wrong with the method?

Cheers,
Ian

---

From: Simon Perreault <[email-masked]>
Date: Tue, 21 Jan 2014 10:42:45 -0500

> parameters, as it wouldn’t have a tunnel endpoint address for the lwAFTR

Ok, good, this is as I expected.

> something wrong with the method?

As I read it, the current text is not conveying this. I would suggest:

OLD:
    An IPv6 address from an assigned prefix is also required for the lwB4
    to use as the encapsulation source address for the softwire.  In
    order to enable end-to-end provisioning, the IPv6 address is
    constructed by taking the /64 prefix assigned to the WAN interface
    (learned via SLAAC, DHCPv6 or manual configuration) and suffixing
    64-bits for the interface identifier.  The /128 prefix is constructed
    as follows:

NEW:
    An IPv6 address from an assigned prefix is also required for the lwB4
    to use as the encapsulation source address for the softwire.  In
    order to enable end-to-end provisioning, the IPv6 address is
    constructed by taking a /64 prefix assigned to the WAN interface
    and suffixing 64-bits for the interface identifier.  As there may be
    multiple WAN prefixes, of which only one can be used for lw4o6, the
    CPE is provisioned with the knowledge of which one to take.  The /128
    prefix is then constructed as follows:

Simon

---

From: <[email-masked]>
Date: Fri, 24 Jan 2014 09:10:12 +0100

>    prefix is then constructed as follows:

[ian] I think that reads better. Can I suggest a slight wording tweak?:

s/knowledge of which one to take/logic to select the correct one

Cheers,
Ian

---

From: Qi Sun <[email-masked]>
Date: Mon, 27 Jan 2014 10:44:28 +0800

I support this document to move forward.

//Some nits:
1) Page 9
The working flow of the lwB4 is illustrated in figure 3.
=> The working ... in figure 4.
2) It would be better if all Captions could be centered.

Best Regards,
Qi

On 2014-1-14, at 下午12:46, Suresh Krishnan wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Cong Liu <[email-masked]>
Date: Tue, 28 Jan 2014 03:02:13 +0800

Hi all,

I support advancing this document.

Best Regards,
Cong

2014-01-14 Suresh Krishnan <[email-masked]>

---

From: Ian Farrer <[email-masked]>
Date: Mon, 27 Jan 2014 20:03:44 +0100

I also support it advancing, with the requested updates (as a co-author)

Ian

---

From: "Yuchi Chen" <[email-masked]>
Date: Tue, 28 Jan 2014 10:23:42 +0800

Hi all,

I support to move forward the document.

Best regards!

Yuchi Chen

From: Suresh Krishnan
Date: 2014-01-14 12:46
To: Softwires WG
CC: Yong Cui
Subject: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03
Hi all,

Regards,
Suresh & Yong

---

From: <[email-masked]>
Date: Tue, 28 Jan 2014 08:16:48 +0100

I support the doc to move forward.
	Olaf

-----Ursprüngliche Nachricht-----
Von: Softwires [mailto:[email-masked]] Im Auftrag von Suresh Krishnan
Gesendet: Dienstag, 14. Januar 2014 05:46
An: Softwires WG
Cc: Yong Cui
Betreff: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03

Hi all,
   This message starts a two week softwire working group last call on advancing the draft about Lightweight 4over6 as a Standards Track RFC. 
The authors believe that this version has addressed all the issues raised on the document till now. The latest version of the draft is available at

Substantive comments and statements of support/opposition for advancing this document should be directed to the mailing list. Editorial suggestions can be sent directly to the authors. This last call will conclude on January 28, 2014.

Regards,
Suresh & Yong

---

From: Tina TSOU <[email-masked]>
Date: Tue, 28 Jan 2014 08:10:38 +0000

Dear all,
I support advancing this document. It is being deployed in some networks.

Thank you,
Tina

-----邮件原件-----
发件人: Softwires [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2014年1月24日 16:10
收件人: [email-masked]; [email-masked]
主题: Re: [Softwires] Working group last call for draft-ietf-softwire-lw4over6-03

Cheers,
Ian

---

From: Sheng Jiang <[email-masked]>
Date: Tue, 28 Jan 2014 08:42:12 +0000

I also support advancing this document. It is mature now.

Best regards,

Sheng

>-----Original Message-----
>From: Softwires [mailto:[email-masked]] On Behalf Of Suresh
>Krishnan
>Sent: Tuesday, January 14, 2014 12:46 PM
>To: Softwires WG
>Cc: Yong Cui

---

From: [email-masked]
Date: Tue, 28 Jan 2014 16:47:37 +0800

Support +1

BRs，
Wei

---

From: Branimir Rajtar <[email-masked]>
Date: Tue, 28 Jan 2014 10:04:50 +0100

+1 for support

Branimir

---

From: "Lee, Yiu" <[email-masked]>
Date: Tue, 28 Jan 2014 12:47:19 +0000

I also support moving forward.

BR,
Yiu

From:  Cong Liu <[email-masked]>
Date:  Monday, January 27, 2014 at 2:02 PM
To:  Suresh Krishnan <[email-masked]>
Cc:  Softwires WG <[email-masked]>, Yong Cui <[email-masked]>
Subject:  Re: [Softwires] Working group last call for
draft-ietf-softwire-lw4over6-03

Hi all, 

Best Regards,
Cong

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 29 Jan 2014 07:20:14 +0800

Hi all,

Support to move forward. 

Best wishes
Qiong