Subject: [v4tov6transition] ISP support of Native IPv6 across NAT44 CPEs - Proposed 6a44 Specification

From: Rémi Després <[email-masked]>
Date: Tue, 5 Oct 2010 11:26:05 +0200

Hi all,

Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just been posted (http://tools.ietf.org/html/draft-despres-softwire-6a44-00).
It describes a solution for ISPs to offer native IPv6 across IPv4-only CPEs (NAT44 CPEs).

It results from convergence discussion between authors of draft-carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, taking into account comments made by authors of draft-lee-softwire-6rd-udp-01, and those made other Softwire WG participants since IETF 78.

It is submitted to become, after discussion in the WG, a Softwire I-D.

Regards,
RD 

Internet Engineering Task Force                               R. Despres
Internet-Draft                                                 RD-IPtech
Intended status: Standards Track                            B. Carpenter
Expires: April 8, 2011                                 Univ. of Auckland
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                         October 5, 2010

                  Native IPv6 Across NAT44 CPEs (6a44)
                     draft-despres-softwire-6a44-00

Abstract

   Most CPEs should soon be dual stack, but a large installed base of
   IPv4-only CPEs is likely to remain for several years.  Also, with the
   IPv4 address shortage, more and more ISPs will assign private IPv4
   addresses to their customers.  The need for IPv6 connectivity
   therefore concerns hosts behind IPv4-only CPEs, including such CPEs
   that are assigned private addresses.  The 6a44 mechanism specified in
   this document addresses this need, without limitations and
   operational complexities of Tunnel Brokers and Teredo to do the same.

   6a44 is based on an address mapping and on a mechanism whereby
   suitably upgraded hosts behind a NAT may obtain IPv6 connectivity via
   a stateless 6a44 server function operated by their Internet Service
   Provider.  With it, traffic between two 6a44 hosts in a single site
   remains within the site.  Except for IANA numbers that remain to be
   assigned, the specification is intended to be complete enough for
   running codes to be independently written and interwork.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 8, 2011.

Despres, et al.           Expires April 8, 2011                 [page 1]

Internet-Draft    Native IPv6 behind NAT44 CPEs (6a44)      October 2010

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  6a44 IPv6 Address Format . . . . . . . . . . . . . . . . . . .  6
   4.  Address Mappings and Encapsulations  . . . . . . . . . . . . .  8
   5.  MTU considerations . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Host Acquisition of IPv6 Addresses and their Lifetimes . . . . 10
   7.  Security considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
     10.2.  Informative References  . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Oct 2010 09:50:31 +1300

> It is submitted to become, after discussion in the WG, a Softwire I-D.

By the way, we do discuss in the draft why it's a useful alternative to
both tunnel brokers (such as Hexago and SixXs) or Teredo. We don't
explicitly discuss why we think it's also a useful alternative to an L2TP
solution, but the arguments are, I think, similar to those for the tunnel
brokers (apart from our "hobbyist" comment).

    Brian

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Oct 2010 08:57:35 +0200

Brian,

> brokers (apart from our "hobbyist" comment).

perhaps you could also add some deployment considerations with regards to host tunneling versus "network" tunneling?

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 07 Oct 2010 11:10:27 +1300

> perhaps you could also add some deployment considerations with regards to host tunneling versus "network" tunneling?

OK, if there is enough interest to continue this work. Of course, in the
context of legacy CPE, there is no alternative to host tunnels.
(Except for the idea in draft-lee-softwire-6rd-udp of a tiny
relay plugged into the customer LAN.)

     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Oct 2010 16:21:51 -0700

Hi Brian, 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Wednesday, October 06, 2010 3:10 PM
> To: Ole Troan
> Cc: Softwires; [email-masked]
> Subject: Re: [Softwires] ISP support of Native IPv6 across 
> NAT44 CPEs -Proposed 6a44 Specification
> 
> >>> Draft-despres-softwire-6a44-00, coauthored with Brian and 
> Sheng, has just been posted 
> (http://tools.ietf.org/html/draft-despres-softwire-6a44-00).
> >>> It results from convergence discussion between authors of 
> draft-carpenter-6man-sample-00 and 
> draft-despres-softwire-6rdplus-00, taking into account 
> comments made by authors of draft-lee-softwire-6rd-udp-01, 
> and those made other Softwire WG participants since IETF 78.
> >>>
> > perhaps you could also add some deployment considerations 
> with regards to host tunneling versus "network" tunneling?
> 

I agree that the tunnel endpoint device in the end user
network needs to configure the 6a44 tunnel interface as a
host interface, but if the device also configures another
tunnel over *that* then the inner tunnel could be used as
a router interface.

If you can bear with me for a moment (*), consider the 6a44
tunnel as an underlying interface over which the tunnel
endpoint device configures an IRON tunnel. Yes, that would
make for nested encapsulations - in particular, the nesting
would be IPv6-in-IPv6-in-UDP-in-IPv4. But, the inner tunnel
could be used as a router interface to service a PI IPv6
prefix. This would work even if the inner tunnel was
configured over multiple underlying 6a44 tunnels - one
each for each ISP the end user network connects to.

(*) Of course, the sticking point once again is the pesky
tunnel MTU issue. 6a44 appears to be punting on MTU yet
again and setting a static 1280 MTU. That means that there
is not enough available MTU to configure another tunnel
over the 6a44 tunnel without fragmentation. If 6a44 is
already implementing a control message protocol as per
the I-D, however, it could also add a 6a44 "Packet Too
Big" control message and use the IRON/SEAL method for
reporting fragmentation as a means for supporting path
MTU discovery. If you'd like a more detailed discussion
of this idea, let me know.

Thanks - Fred
[email-masked]

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

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 6 Oct 2010 20:46:17 -0400

Agree because 6a44 address schema won't generate a prefix shorter than /64.
Let's put the technology aside. The ultimate question is: "Will O/S vendors
be willing to consider to implement another tunnel protocol on the host?"

On 10/6/10 6:10 PM, "Brian E Carpenter" <[email-masked]> wrote:

>>>> Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has just
>>>> been posted (http://tools.ietf.org/html/draft-despres-softwire-6a44-00).
>>>> draft-carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00,
>>>> taking into account comments made by authors of
>>>> draft-lee-softwire-6rd-udp-01, and those made other Softwire WG
>>>> participants since IETF 78.
>>>> 
>> perhaps you could also add some deployment considerations with regards to
>> host tunneling versus "network" tunneling?
>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Wed, 6 Oct 2010 20:56:38 -0400

Hi Fred,

This is an interesting idea, but I will argue this is as complex as L2TP
softwire. When Brian, Remi and I discussed, we would like to have a simple
and cost effective technology that could be deployed by SP w/o upgrading the
CPE. This double tunneling tech seems scary.

Thanks,
Yiu

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Oct 2010 15:40:08 +0200

Le 7 oct. 2010 à 02:56, Yiu L. Lee a écrit :

> CPE.

Indeed.
We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs.

Whether some more complex and more powerful models can be designed next is an open issue.
IMHO, it MUST NOT delay in any way adoption of the simple scheme.

RD

> This double tunneling tech seems scary.
> 
> Thanks,
> Yiu
> 
> 
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Oct 2010 15:45:37 +0200

> We need some reliable and easily deployable solutions for IPv6 use to become widespread, including in hosts behind legacy CPEs.

why?

my personal experience with host tunneling hasn't been great (ISATAP, Teredo, 6to4, configured, L2TP). and do ISPs really have an interest in supporting individual hosts? and be exposed to all of their peculiarities?

it appears to me that we are filling in every possible square in the solution matrix. just because it is possible doesn't mean that it is useful or deployable...

cheers,
Ole

---

From: "Yiu L. Lee" <[email-masked]>
Date: Thu, 7 Oct 2010 09:53:51 -0400

Hi Ole,

I agree with you the host model isn't very attractive for average users. If
IPv4 can get me to every site, why I want to install a software to bring me
to the same set of sites over v6? 6rd is great tech, users don't need to do
anything. The only drawback is users will have to change the CPE. For some
operators, this may be a hurdle.

I can't say how bad operators want to support IPv6 over legacy CPEs. If
there is demand. Can somebody (except me :-) ) speak it out?

Thanks,
Yiu

On 10/7/10 9:45 AM, "Ole Troan" <[email-masked]> wrote:

>> We need some reliable and easily deployable solutions for IPv6 use to become
>> widespread, including in hosts behind legacy CPEs.
> 
> why?
> 
> my personal experience with host tunneling hasn't been great (ISATAP, Teredo,
> 6to4, configured, L2TP). and do ISPs really have an interest in supporting
> individual hosts? and be exposed to all of their peculiarities?
> 
> it appears to me that we are filling in every possible square in the solution
> matrix. just because it is possible doesn't mean that it is useful or
> deployable...
> 
> cheers,
> Ole

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Oct 2010 16:56:37 +0200

Le 7 oct. 2010 à 15:45, Ole Troan a écrit :

> my personal experience with host tunneling hasn't been great (ISATAP, Teredo, 6to4, configured, L2TP).

That is the whole point of proposing a really SIMPLE solution to solve a real problem.
 
> and do ISPs really have an interest in supporting individual hosts? and be exposed to all of their peculiarities?

ISPs that aren't concerned with what their customer would like to have will eventually face competition.
A key point is that supporting 6a44 is very inexpensive compared to other supports they have to envisage.

Yet, as Yiu says, this still depends on which hosts will support 6a44.
My personal hope is that we will soon see trials, including with mobile phones.  

> it appears to me that we are filling in every possible square in the solution matrix.

If you believe that IPv6 deployment is rapid enough, your lack of interest is understandable, but some have a different view. 

> just because it is possible doesn't mean that it is useful or deployable...

I never believed that!!!

Yet a simple, reliable, and scalable solution is sometimes a good way to cut the gordian knot.
6rd was an example, and I personally believe that 6a44 has a great potential too. 

Cheers,
RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 7 Oct 2010 17:02:15 +0200

Le 7 oct. 2010 à 05:21, Olivier Vautrin a écrit :

> Hi all, very interesting draft.
> 
> I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed.
> 
> In this draft, I see 2 issues described for Teredo:
> 1) "clients sometimes believing that they have Teredo connectivity when in fact they don't"
> Clients could have the same issue in 6a44 AFAIK.

One problem of Teredo is that, between two valid Teredo addresses, it can break with some NAT behaviors.
6a44 avoids that.

> There is no mechanism in 6a44 to check the data path connectivity.

For hosts that are on LANs behind NAT44-CPEs, there is no more IPv6 connectivity to be checked than between two any pair of hosts having native IPv6 addresses.

Yet, there seems to be be something to add about customer sites having internally cascaded NATs, something like: 
NATs that are cascaded behind CPE NATs should disable the 6a44 well-nown port W for incoming packets.
This can be done by a port mapping to an address that doesn't belong to the set of DHCP assigned addresses.

> I think the real issue here is lack of reliable teredo relay or lack of reliable data path (MTU issues).
> 2) "Teredo server and relay being very remote"
> 
> Both issues can be fixed if ISPs deploy their own Teredo server/relay.

Do you mean ALL ISPs? If yes, it isn't a practical solution.
Besides, do you suggest that IPv6 sensor devices that need the incoming connectivity that IPv6 can restore would have to support Teredo?

> Which is basically what they will do with 6a44.

The point of 6a44 is that each ISP can incrementally deploy the solution (like 6rd, or also the 4rd that both of us proposed ;-))

> So, I don't really see the issues described in the paper as important enough to create another protocol.
> 
> I do think there are other issues with Teredo:
> 1) Use of a WK prefix instead of an ISP prefix. This means the return path can be broken as with 6to4.
> 2) Most client Teredo implementation need a full cone NAT on the CPE. Most CPE use symmetric NAT. so a CPE upgrade could be needed.
> 3) Most OS still prefer IPv4 over Teredo. This means it does not increase the Ipv6 traffic.
> 4) On vista, it seems that traffic is sent to a Teredo tunnel only if another Ipv6@ is created (I didn't check this though). Source: http://yorickdowne.wordpress.com/2008/01/26/ipv6-at-home-part-1-overview-teredo/

It shouldn't be long to developer who knows 6to4 under Linux to implement 6a44. 
It's a new protocol, yes, but a very simple one to implement and to operate.

Regards,
RD

> /Olivier
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Brian E Carpenter
>> Sent: Tuesday, October 05, 2010 9:51 PM
>> To: Softwires
>> Cc: [email-masked]
>> Subject: Re: [Softwires] ISP support of Native IPv6 across NAT44 CPEs -
>> Proposed 6a44 Specification
>> 
>>> Draft-despres-softwire-6a44-00, coauthored with Brian and Sheng, has
>> just been posted (http://tools.ietf.org/html/draft-despres-softwire-
>> 6a44-00).
>>> It results from convergence discussion between authors of draft-
>> carpenter-6man-sample-00 and draft-despres-softwire-6rdplus-00, taking
>> into account comments made by authors of draft-lee-softwire-6rd-udp-01,

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 7 Oct 2010 09:39:21 -0700

Hi Yiu, 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yiu L. Lee
> Sent: Wednesday, October 06, 2010 5:57 PM
> To: Templin, Fred L; Brian E Carpenter; Ole Troan
> Subject: Re: [v4tov6transition] [Softwires] ISP support of 
> Native IPv6across NAT44 CPEs -Proposed 6a44 Specification
> 
> Hi Fred,
> 

I used the double tunneling example as something that
could be done and not necessarily something that should
be done - it is not at all a requirement of IRON, and
would not be as efficient as deploying IRON alone without
also deploying 6a44 or the like. But, it might be worth
noting that the hard-coded 1280 MTU precludes configuring
other tunnels over 6a44 tunnels.

AFAICT, if the ISPs want to let their customers set up
native IPv6 networks behind unmodified IPv4 NATs the
two choices are to 1) do nothing, and let outside
agencies deploy the IRON service, or 2) deploy the IRON
service themselves.

This gets back to a point that needs to be bumped up a
level in visibility. Some of these proposed approaches
are strictly provider-aggregated, which may be good for
the ISPs but maybe not so optimal for the customers. IRON
provides the customers with a provider-independent routing
and addressing service that can be carried over any ISP(s)
the customers happens to procure their basic connectivity
services from.

About complexity comparisons, based on my limited knowledge
of L2TP the IRON architectural principles don't have a
parallel in the L2TP model. But, when it comes to control
and data plane messaging, I can say with some confidence
based on the code I am writing that IRON is much simpler.

Thanks - Fred
[email-masked]

---

From: Ole Troan <[email-masked]>
Date: Thu, 7 Oct 2010 21:28:20 +0200

Remi,

[...]

> ISPs that aren't concerned with what their customer would like to have will eventually face competition.

we are in complete agreement of the end goal. it is just how we get there...

> My personal hope is that we will soon see trials, including with mobile phones.  

issues I have with host tunneling:
 - how to communicate with native IPv6 nodes on the same network?
 - how to communicate to another 6a44 host on a different link in the same home?
 - do you need non-congruent topology multi-homing policy?
   http://tools.ietf.org/html/draft-troan-multihoming-without-nat66-01
   how do you distribute that policy when you don't have a on-link router?
 - a general unease that now every host is supposed to have a "VPN" connection?
   how do I configure my own firewall and other network border policy?

how much would a new CPE cost the customer? 80USD? that's only 5 pints of beer (if bought in Norway.)
I really liked the dongle idea by the way. perhaps with a L2TP LAC.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Oct 2010 11:47:36 +1300

Ole,

> I really liked the dongle idea by the way.

I'm not convinced. If people are willing to buy such a thing,
and if you are correct about $80 IPv6-enabled CPEs, I think the
latter will win.

So the real question for me is whether a $0 dollar download will beat
an $80 purchase. Predicting customer bahaviour is hard.

IMHO, we can put both on the market and see what happens.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Oct 2010 13:07:04 +1300

> there is demand. Can somebody (except me :-) ) speak it out?

Well, when we surveyed 31 ISPs for draft-ietf-v6ops-isp-scenarios,
we found "When asked which types of equipment are unable to support IPv6, the
most common answer was CPE (10 mentions)." That doesn't directly answer
your question, but it suggests the size of the problem.

Regards
   Brian Carpenter

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Oct 2010 13:12:29 +1300

Olivier,

Rémi has mainly answered you. In particular, the operational problems
caused by missing Teredo servers don't just harm the customers of
the ISP concerned; like missing 6to4 relays, they also harm customers
of *other* ISPs. 6a44 doesn't have this problem.

> I think it would be worthwhile to elaborate a bit more in the draft why Teredo is not viable and thus an alternative is needed.

I believe that a separate draft on "operational problems with Teredo"
would be useful (in v6ops, most likely). Personally, I'd rather keep
the 6a44 draft more focussed.

Regards
   Brian

On 2010-10-07 16:21, Olivier Vautrin wrote:
> Clients could have the same issue in 6a44 AFAIK. There is no mechanism in 6a44 to check the data path connectivity. I think the real issue here is lack of reliable teredo relay or lack of reliable data path (MTU issues).
> Both issues can be fixed if ISPs deploy their own Teredo server/relay. Which is basically what they will do with 6a44. So, I don't really see the issues described in the paper as important enough to create another protocol.
>

---

From: Olivier Vautrin <[email-masked]>
Date: Wed, 6 Oct 2010 20:21:02 -0700

/Olivier

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 7 Oct 2010 18:41:07 -0700

> your question, but it suggests the size of the problem.

Brian is right.  And when a customer asks for IPv6 features in end
nodes, through any number channels (public, private, RFP, ...), the
answers is frequently something like /dev/null .  For instance,
http://tinyurl.com/2f753c5 ...

So, if you work for a vendors that makes CPE / UE, please consider
turning IPv6 on in your product.

Cameron

---

From: Ed Jankiewicz <[email-masked]>
Date: Thu, 07 Oct 2010 22:07:11 -0400

a colleague asked his broadband cable provider if he could get IPv6 on 
his Internet service.  The customer service rep didn't know but assured 
him he would look into it.  He got a quick reply via e-mail "thank you 
for your recent inquiry about IPV6.  We do our best to respond to 
customer requests for specific programming but technical limitations 
mean that we can't carry every piddling little international sports 
channel that..." Or something to that effect.

They will remain nameless, but I assure you this operator is 
well-represented in IETF.  I did stand up at a v6ops meeting to tell 
that story and say "to all of you who say we are ready to turn on IPv6 
as soon as our customers demand it - they may ask for it, but if your 
customer service folks and other staff don't know about IPv6 - you will 
never hear that the customers are asking."

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Oct 2010 09:43:54 +0200

Le 7 oct. 2010 à 21:28, Ole Troan a écrit :
> ...

The 6a44-S decapsulates IPv6 packets coming from a 6a44 host and, if not destined to another 6a44 host of its network, forwards them in IPv6, in this case on the same network.

> - how to communicate to another 6a44 host on a different link in the same home?

6a44 is only for hosts on a LAN behind a NAT44 attached to a 6a44-capable ISP network.
If the LAN has several bridged links, it does apply.
Links that are behind extra NATs in the site are out of scope.

As I said to Olivier Vautrin in a previous mail on this thread, these extra NATs should be configured so that hosts behind them never receive 6a44 IPv6-Address-Indication messages. (e;g. with the 6a44 well-known port bound to an unassigned internal address.
This point isn't in the draft yet but, if co-authors agree, should be in the next version.

>   how do you distribute that policy when you don't have a on-link router?

Not sure to understand the question.
The answer should be NO: 6a44 only needs classical topologies.

>   how do I configure my own firewall and other network border policy?

If the NAT binds the 6a44 well-known port to an unassigned internal address, no host will be able to receive a 6a44 IPv6 address. 
Besides, a firewall could filter all packets having this port, source or destination.

> I really liked the dongle idea by the way. perhaps with a L2TP LAC.

The dongle idea of 6rd-UDP, if without a stateful NAT66 in the dongle, needs an assigned /16 to the function. (The /64 subnet prefix has to contain the site IPv4 address plus the port of the tunnel).
This is in general not realistic.

Now, if there is a NAT66 in the dongle, it can work with a 6a44 external address.

I hope it helps to understand that 6a44 isn't just one more design for the pleasure to make one, but a pragmatic solution to a real problem, specified after an in depth study. 

Cheers,
RD

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Oct 2010 10:08:24 +0200

Remi,

> The 6a44-S decapsulates IPv6 packets coming from a 6a44 host and, if not destined to another 6a44 host of its network, forwards them in IPv6, in this case on the same network.

I was thinking of another native IPv6 node in the same home. as 6a44 doesn't enable IPv6 support in the home network I don't see how this would work.

> This point isn't in the draft yet but, if co-authors agree, should be in the next version.

I was thinking of the case of a routed home. no additional NATS. I don't see how the mechanism would work across routers. since you don't get a prefix for the site. the homegate/homenet WG proposal was rejected by the IESG, but it would have been useful to have the home network architecture document as background for this discussion...

> The answer should be NO: 6a44 only needs classical topologies.

if a 6a44 node is multi-homed to 3 networks, the 6a44 network the IPV4 network and possibly a native IPv6 network (e.g. ULA in the home), would you need to distribute SAS/NH/DNS policy?

> Besides, a firewall could filter all packets having this port, source or destination.

that doesn't give me ability to filter on IPv6 applications on the network border... not specific to 6a44, this is just an artifact of host tunneling.

> This is in general not realistic.

my suggestion is to use L2TP, which has none of those particular shortcomings.

> I hope it helps to understand that 6a44 isn't just one more design for the pleasure to make one, but a pragmatic solution to a real problem, specified after an in depth study. 

is the in-depth study available?

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Fri, 8 Oct 2010 11:26:48 +0200

Hi Ole,

As you will see below, you helped to find a bug in the draft!
Many thanks for that.
I hope that after its correction you may become more positive about 6a44. 

> I was thinking of another native IPv6 node in the same home. as 6a44 doesn't enable IPv6 support in the home network I don't see how this would work.

The draft says "In a host, the 6a44 Client function is activated only if the host has an IPv4 address and doesn't have, by any other means, a global unicast IPv6 address".
If there is native IPv6 in a site, 6a44 doesn't apply.

> I was thinking of the case of a routed home. no additional NATS. I don't see how the mechanism would work across routers. since you don't get a prefix for the site.

OOPS, Figure 3, where detailed mappings and encapsulations of the intra-site case is bugged (sorry for that).
Hosts A and A2 should have different tunnel ports, i.e. Z and Z2 instead of the same Z:
----------------------------------------------------------
(v6,<D.N.Z.A>,<D.N.Z2.A2>, data)
        |
        | (v4,A,A2,(UDP,W,W,(v6,<D.N.Z.A>,<D.N.Z2.A2>, data)))
        |                  |
   +----|--+--------+      |             HOST TO HOST
   |    |  |        |      |
   |  -->--+ 6a44-C +------>------
   |  IPv6 |        |<A   IPv4
   +-------+--------+
           Host 
---------------------------------------------------------

To be consistent, the host to BR case must only be concerned the destination being different from D.N (not D.N.Z).
It becomes:
----------------------------------------------------------
(v6,<D.N.Z.A>,<not D.N...>, data)
         |
         | (v4,A,B,(UDP,W,W,(v6,<D.N.Z.A>,not<D.N...>, data)))
         |                  |
    +----|--+--------+      |       HOST TO BORDER ROUTER
    |    |  |        |      |
    |  -->--+ 6a44-C +------>------
    |  IPv6 |        |<A   IPv4
    +-------+--------+
           Host
----------------------------------------------------------

With these behaviors, direct host-to-host communication even if there are routers between them (provided there are no NATs.
This should be clarified in a next version of the draft. (In Figure 1, LAN should be replaced by NAT-less private-IPv4 network.)

> the homegate/homenet WG proposal was rejected by the IESG, but it would have been useful to have the home network architecture document as background for this discussion... 

> if a 6a44 node is multi-homed to 3 networks, the 6a44 network the IPV4 network and possibly a native IPv6 network (e.g. ULA in the home), would you need to distribute SAS/NH/DNS policy?

See above: 6a44 only applies in a host if there isn't any other IPv6 address.

> that doesn't give me ability to filter on IPv6 applications on the network border... not specific to 6a44, this is just an artifact of host tunneling.

If no 6a44 packet traverses the FW, there seems to be no need to look at what what they might contain at higher layers.
Did I miss something?

> my suggestion is to use L2TP, which has none of those particular shortcomings.

6a44 doesn't prevent anyone to do something else.
In my understanding, L2TP doesn't keep within a site traffic between two hosts of the site (and is much more complex). 

> is the in-depth study available?

Just its conclusion, in the draft itself.
I meant a "long and hard" study to get things operational and simple at the end.

Remember that it took me also a long and hard study to finally invent 6rd but that, once it was done, it only took half an hour of verbal explanation to Rani Assaf of Free.fr to understand the solution, and decide to implement it. (He didn't need a study document.) 

Of course 6a44 isn't quite as simple as 6rd, but I the draft is all I personally need to keep about the solution. Everything else is noise and history.

Cheers,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Oct 2010 07:51:55 -0700

> CPE. This double tunneling tech seems scary.

More to this point about double-tunneling, how were
folks thinking that IPv6 VPNs would be run over a
1280 MTU IPv6-in-IPv4 tunnel? That is double-tunneling,
and seems like it would be a quite common case, but the
MTU seems deficient. Should it use IPv6 fragmentation?

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Oct 2010 10:17:40 -0700

End systems in end user networks that connect to the
IPv6 Internet will likely want to configure IPv6 VPNs,
e.g., so that they can securely connect to their home
office networks. Those VPN links must present a 1280
minimum MTU to upper layers, but if they traverse a
link in the path with a too-small MTU then the end
system will see an MTU underrun and will need to use
IPv6 fragmentation.

An IPv6-in-IPv4 tunnel with a fixed static 1280 MTU is
an example of a link in the path that could cause such
an MTU underrun for end system VPN links. So, should we
be concerned that tunnels with a fixed 1280 MTU would
make life difficult for the common operational practice
of end systems using VPNs?

Thanks - Fred

> [mailto:[email-masked]] On Behalf Of 
> Templin, Fred L
> Sent: Friday, October 08, 2010 7:52 AM
> To: Yiu L. Lee; Brian E Carpenter; Ole Troan
> NativeIPv6across NAT44 CPEs -Proposed 6a44 Specification
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Oct 2010 11:24:17 -0700

FYI, here's my tunnel MTU guy that I showed back during
the Vancouver meeting (December 2007)? I think he is
still left with the same conundrum today that he was
back then...

Fred

> [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Friday, October 08, 2010 10:18 AM
> To: Softwires; [email-masked]
> Subject: [Softwires] IPv6 VPNs configured over 1280 MTU tunnels
>

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 8 Oct 2010 14:36:22 -0400

Hi Brian,

I think this is all relative. I discussed internally about software
download. Their answer to me is "BIG NO". Reason is SP must run QA tests for
every possible OS/patches combination. Worst is we need to redo this again
when a new patch/upgrade is released. This is far costly than you can
imagine (way more than the $80 new CPE). In the end, I would vote for the
dongle based over host based anytime.

Is dongle more viable option than new CPE? I think this is the real debate.

Cheers,
Yiu

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Oct 2010 11:54:08 -0700

Yiu, 

> [mailto:[email-masked]] On Behalf Of Yiu L. Lee
> Sent: Friday, October 08, 2010 11:36 AM
> To: Brian E Carpenter; Ole Troan
> Subject: Re: [Softwires] [v4tov6transition] ISP support of 

But then the dongle/CPE becomes the ball-and-chain that
locks the customer into the SP's PA addressing scheme...

Fred
 
> >>> ISPs that aren't concerned with what their customer would 
> like to have will
> >>> eventually face competition.
> >> 
> >>> A key point is that supporting 6a44 is very inexpensive 
> compared to other
> >>> supports they have to envisage.
> >>> 
> >>> My personal hope is that we will soon see trials, 
> including with mobile
> >>> phones.  
> >> 
> >>  - how to communicate to another 6a44 host on a different 
> link in the same
> >> home?
> >> how much would a new CPE cost the customer? 80USD? that's 
> only 5 pints of
> >> beer (if bought in Norway.)

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 8 Oct 2010 14:57:55 -0400

Hi Fred,
 
> locks the customer into the SP's PA addressing scheme...
This is what most ISPs offer to residential and small home office users. So
this is no worse.

Cheers,
Yiu

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Oct 2010 12:00:42 -0700

HI Yiu, 

> Sent: Friday, October 08, 2010 11:58 AM
> Native IPv6acrossNAT44 CPEs -Proposed 6a44 Specification
> 
> Hi Fred,
>  

Understood that it is PA in the underlay network space,
and that is all well and good. But, PI in the overlay
network space (instead of PA) is an option that should
be made available to customers.

Thanks - Fred

---

From: "Yiu L. Lee" <[email-masked]>
Date: Fri, 8 Oct 2010 17:43:37 -0400

> be made available to customers.
Maybe if there is enough demand.

Cheers,
Yiu

---

From: Washam Fan <[email-masked]>
Date: Sat, 9 Oct 2010 11:02:07 +0800

Hi,

> An IPv6-in-IPv4 tunnel with a fixed static 1280 MTU is

I assume you were refering 6a44. The reason why 6a44 restricts 1280
MTU is IPv6 PMTU performance is not reliable practically, per Remi's
reponse to me. If PMTU could (and I think it should) perform well,
6a44 would permit more larger MTU.

For this bullet in sec5, draft-despres-softwire-6a44-00

   o  6a44 Server functions refuse packets received from their IPv6
      pseudo interfaces if their sizes exceed 1280 octets, with ICMPv6
      Packet Too Big messages returned to sources as required by
      [RFC2460].)

I think it could only apply to the case where the received IPv6
packets forwarded to the external domain. In the case the 6a44 server
does the hairpinning, the 6a44 server would refuse packets whose size
exceed (IPv4 MTU - 28) octets, with ptb ICMPv6 msg.

Thanks,
washam

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Oct 2010 08:53:31 -0700

> From: Washam Fan [mailto:[email-masked]] 
> Sent: Friday, October 08, 2010 8:02 PM
> To: Templin, Fred L
> Subject: Re: [v4tov6transition] IPv6 VPNs configured over 
> 1280 MTU tunnels
> 
> Hi,
> 
> I assume you were refering 6a44.

No; I'm referring to any IPv6-in-IPv4 tunnel that sets
a static 1280 MTU. There are more than one of these.

> The reason why 6a44 restricts 1280

Its not about IPv6 PMTUD; its about IPv4 PMTUD. If a
tunnel router in an end user site sends an
IPv6-in-UDP-in-IPv4 packet out though its NAT and into
the ISP network, and if the ISP network needs to drop
the packet and send back an ICMPv4 PTB, then the NAT
could drop the PTB or the PTB might not contain enough
information for stateless translation into an ICMPv6
PTB. That's one profile for an MTU-related black hole. 

> exceed (IPv4 MTU - 28) octets, with ptb ICMPv6 msg.

The point is that if the tunnel router sets a static
1280 MTU on its tunnel virtual interface then VPN
tunnel endpoints behind the tunnel router will see
an MTU underflow. That is double-tunneling, but it
is a fact of life in common operational practice.

Fred

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 18:29:17 +0200

Hi Washam and Fred,

>>> MTU seems deficient. Should it use IPv6 fragmentation?

Actually, the 6a44 specification should, instead of 1280, require IPv4 MTU - 28 octets, both for hairpinning and traversal cases.
(It is only hosts that should better take 1280 as default MTU if not having reliable PMTU discovery.)
I will check with co-authors to fix it in a later version.

Thanks to both of you for the discussion.
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Oct 2010 09:42:18 -0700

> From: Rémi Després [mailto:[email-masked]] 
> Sent: Monday, October 11, 2010 9:29 AM
> To: Washam Fan; Templin, Fred L
> Actually, the 6a44 specification should, instead of 1280, 
> require IPv4 MTU - 28 octets, both for hairpinning and 
> traversal cases.

How can you be sure that IPv4 PMTUD will work in
the traversal case?

Fred

---

From: Rémi Després <[email-masked]>
Date: Mon, 11 Oct 2010 19:04:49 +0200

> How can you be sure that IPv4 PMTUD will work in

In the to-host direction, because the ISP network is all what is left to traverse before reaching the CPE.

In the from host direction, one can't be sure, but doesnt' need to.
If a smaller PMTU is encountered further downstream, a PTB ICMPv6 error message will be returned from there.

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Oct 2010 10:13:43 -0700

Remi, 

> Sent: Monday, October 11, 2010 10:05 AM
> To: Templin, Fred L
> Cc: Washam Fan; Softwires; [email-masked]
> In the to-host direction, because the ISP network is all what 
> is left to traverse before reaching the CPE.

In what you call the to-host direction, any ICMPv4
returned from the ISP network might not have enough
information for stateless translation to ICMPv6.

> If a smaller PMTU is encountered further downstream, a PTB 
> ICMPv6 error message will be returned from there.

In the from-host direction, any ICMPv4 returned from
the ISP network might not be delivered to the tunnel
endpoint due to NAT filtering, and might not have
enough information for stateless translation to ICMPv6.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Oct 2010 11:23:02 -0700

> information for stateless translation to ICMPv6.

I should also say, any ICMPv4 returned from within
the end user network (where MTUs might not be so well
managed) might not be delivered to the tunnel endpoint
in the ISP network.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Oct 2010 10:25:34 +1300

Fred

> managed) might not be delivered to the tunnel endpoint

Well, yes, and there were several years when I frequently found myself
in hotel rooms having to manually set the IPv4 MTU on my laptop to a
low value, when connecting through broken dial-up ISPs. No doubt
we'll also go through some years before all operators are providing
an adequately large MTU to cope with IPv6-in-foo tunnels. I don't
think any transition solution can hope to be 100% watertight
on this. We'll make the changes that Rémi mentioned, but
you're correct that IPv6-in6a44 tunnels might have MTU issues.

    Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Oct 2010 16:19:32 -0700

Hi Brian, 

> Sent: Monday, October 11, 2010 2:26 PM
> To: Templin, Fred L
> Subject: Re: [Softwires] [v4tov6transition] IPv6 VPNs 
> configured over1280MTU tunnels
> 
> Fred
> 
> on this.

IROM (vis-a-vis SEAL) is striving for a true tunnel MTU
solution and I think has made significant strides. The
SEAL approach is dissimilar from IPv4 PMTUD in that it
is the tunnel far end (and not a router on the path) that
returns the PTB message. SEAL relies on routers in the path
correctly implementing IPv4 fragmentation, which is a
required behavior even for tunnel paths that traverse
untrusted/unmanaged domains.

SEAL's only requirement is that the IPv4 first fragment of a
fragmented IPv4 datagram contain at least enough information
to include a tunnel identifier. The minimum size for a first
fragment is 8 bytes beyond the IP header, since the fragment
offset field counts the number of 8 byte blocks. Common
operational practices also suggest that routers tend to make
the first fragment be approximately MTU-sized since this may
be useful to allow the destination to measure the path MTU.
There is also enough uncertainty about tiny fragment attacks
(RFC1858, RFC3128, etc.) that it seems highly unlikely that
the first fragment of a multi-fragment IPv4 datagram would
contain less than 16 bytes (UDP header plus enough extra to
contain a tunnel ID). 

> We'll make the changes that Rémi mentioned, but

Please have a look at my tunnel MTU guy when deciding how
to set the static MTU configuration knob:

http://www.ietf.org/mail-archive/web/softwires/current/msg01659.html

The term "configuration knob" came from RFC4213, which
also has an analysis of setting a static MTU that may
be helpful. But, remember that VPNs configured over
paths containing IPv6-in-IPv4 tunnels will need more
headroom, so 1280 seems insufficient.

Thanks - Fred

---

From: Washam Fan <[email-masked]>
Date: Tue, 12 Oct 2010 10:37:31 +0800

Hi,

If 6a44 deployed in a managed ISP network, the 6a44 client could be
configured with IPv4_MTU-28 for its IPv6 MTU. For inbound direction,
6a44 server would reject any IPv6 packets whose size exceeds
IPv4_MTU-28 with a ICMPv6 PTB message, so no ICMPv6-ICMPv4 translation
needed. For outbound direction, 6a44 server would encapsulate any
ICMPv6 PTB messages it received in UDP in IPv4, and then forward to
the 6a44 client, so no NAT filtering worried.

Thanks,
washam

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Oct 2010 19:58:25 -0700

Hi Washam, 

> Sent: Monday, October 11, 2010 7:38 PM
> To: Templin, Fred L
> Cc: Rémi Després; Softwires; [email-masked]
> configured with IPv4_MTU-28 for its IPv6 MTU.

My understanding is that the 6a44 server is in the managed
ISP network, and the 6a44 client is in the UNmanaged end
user network.

> For inbound direction,
> needed.

Huh? How does the server have any idea what MTU the client
set on its tunnel interface? The client is behind a NAT in
an unmanaged end user network. Are you expecting the server
to probe the path MTU to the client and maintain state? (An
IRON server might be in position to do something like that,
but I was assuming the 6a44 server would be stateless, right?) 

> For outbound direction, 6a44 server would encapsulate any

Correct, but no one has suggested an MTU problem for what
happens to IPv6 packets *beyond* the tunnel; we are only
discussing the case of MTU issues *within* the tunnel.

Fred

---

From: Washam Fan <[email-masked]>
Date: Tue, 12 Oct 2010 13:48:27 +0800

Hi Fred,

I might see your points.

Let H represents Host, N represents NAT, S represents the 6a44
servers. PMTU(H,S) stands for the PMTU between H and S. HOME_MTU
represents MTU within home LAN (i.e., unmanaged network), SP_MTU
represents MTU within SP network(i.e., managed network). We assume
both SP_MTU and SP_MTU should exceed or equal to 1308.

if HOME_MTU>=SP_MTU, PMTU(H,S)=SP_MTU, the H could configure SP_MTU-28
as the IPv6 virtual interface MTU.
H->S direction: if S received or trigger any ICMPv6 PTB messages, it
can forward ICMPv6-in-UDP-in-IPv4 to H.
S->H direction: S would reject any IPv6 packets exceeding SP_MTU-28
with ICMPv6 PTB.
I don't see problems here.

If HOME_MTU<SP_MTU,PMTU(H,S)=HOME_MTU, the H could configure
HOME_MTU-28 as IPv6 virtual interface MTU.
H->S direction: if S received or trigger any ICMPv6 PTB messages, it
can forward ICMPv6-in-UDP-in-IPv4 to H. I don't expect the size of the
encapsulated packet is too much.
S->H direction: if S forward some IPv6 packets whose size is between
HOME_MTU-28 and SP_MTU-28, N might trigger a ICMPv4 PTB or filtering
them. For the former, S might don't have enough info to infer which
IPv6 original packet it is related, for the latter, black hole might
occur. I see problems here.

Thanks,
washam

---

From: Rémi Després <[email-masked]>
Date: Tue, 12 Oct 2010 09:25:43 +0200

Fred and Washam,

I reacted too fast to previous remarks when I proposed to modify the accepted IPv6 MTU in 6a44 draft.
If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could receive them in fragmented IPv4 datagrams.
This would be contrary to the objective of simplicity (datagram reassembly would have to be include in 6a44 clients) and to the objective of security (a new door would be open to dos attacks).
No change on this point will therefore appear in the next version of the draft. 
Some additional explanations may be appropriate, but preferably after a consensus on what has to be said.

Then the MTU issue of IPv6 in IPv6 tunnels that Fred underlines remains as is.
If the PMTU of such a tunnel is unknown, or known to be less than 1280+40, tunnel endpoints have to tunnel 1280-octets external packets in two pieces, using a fragmented IPv6 datagram for this. 
Reassembly at the other end is then necessary. 
It can be facilitated if the tunnel is treated as only one flow, with packets in general kept in sequential order. 

Regards,
RD

> information for stateless translation to ICMPv6.

1. Could you be more specific?
Do yout see a significant difference with what happens with 6to4,

> endpoint due to NAT filtering,

2. Then the IPv6 service is somewhat damaged concerning fault diagnosing, like the underlying IPv4 service.
But at least packets that should be delivered are delivered.

> and might not have

3. Same as 1. above.

> managed) might not be delivered to the tunnel endpoint

4. Same as 2. above.
(Since IPv4 fragments rather than returning packet-too-big ICMP messages, this cannot concern MTUs).

Yet, there remains another problem with the replacement of 1280 by "IPv4 MTU - 28" (I proposed it too quickly) because it creates risks of fragmentation ...

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Oct 2010 08:05:30 -0700

Hi Washam, 

> Sent: Monday, October 11, 2010 10:48 PM
> To: Templin, Fred L

Good.

> both SP_MTU and SP_MTU should exceed or equal to 1308.

This is an incomplete characterization. PMTU is not
necessarily symmetric, e.g., even just within the end
user it could be different in the H->N direction than
in the N->H direction. Also, there could be multiple N's
in the path; each imparting their own MTU uncertainties.
 
> as the IPv6 virtual interface MTU.

A couple of things here. First, you seem to be assuming a
static S instead of a redundantly replicated S with anycast,
where there may be many distinct paths with varing SP_MTUs to
reach the multiple S's. Second, how does H discover SP_MTU;
by engaging in an initial probing by sending large packets
and getting a PTB message back? Again, this won't give a
deterministic SP_MTU value if  S is replicated across paths
with varying PMTUs.

> can forward ICMPv6-in-UDP-in-IPv4 to H.

You keep saying this, and I keep saying that you are right
but that this has never been a matter for concern. PMTUD
*beyond* the tunnel is not in question; it is only PMTUD
*within* the tunnel that bears further discussion.

> I don't see problems here.

Huh? Is S supposed to cache the SP_MTU to each and every
potential host H? I assume the goal is for a completely
stateless S - right?

> HOME_MTU-28 as IPv6 virtual interface MTU.

So again, H could discover this only by sending probes?
And again, any probing would be non-deterministic if S
is an anycast (and not unicast) address.

> can forward ICMPv6-in-UDP-in-IPv4 to H.

Yes, we have confirmed this several times now; not
a point in question.

> I don't expect the size of the encapsulated packet is too much.

Encapsulated PTB could be as big as 1280 + 20 + 8.

> IPv6 original packet it is related,

Right.

> for the latter, black hole might occur. I see problems here.

Right.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Oct 2010 08:17:32 -0700

Hi Remi, 

> [mailto:[email-masked]] On Behalf Of Rémi Després
> Sent: Tuesday, October 12, 2010 12:26 AM
> To: Templin, Fred L; Washam Fan
> Subject: Re: [Softwires] [v4tov6transition] 6a44 MTU issues
> 
> Fred and Washam,
> 
> I reacted too fast to previous remarks when I proposed to 
> modify the accepted IPv6 MTU in 6a44 draft.
> If IPv6 packets longer than 1280 would be accepted by 6a44 
> servers, hosts could receive them in fragmented IPv4 datagrams.

Or they might be reassembled in the NAT(s) in front of
the host.

> This would be contrary to the objective of simplicity 
> (datagram reassembly would have to be include in 6a44 
> clients) and to the objective of security (a new door would 
> be open to dos attacks).
> Some additional explanations may be appropriate, but 
> preferably after a consensus on what has to be said.
> 

Right.

> If the PMTU of such a tunnel is unknown, or known to be less 
> than 1280+40,

Actually, 1280+40+IPsec headers and trailers in the case
of VPN.

> tunnel endpoints have to tunnel 1280-octets 
> external packets in two pieces, using a fragmented IPv6 
> datagram for this.

OK, so steady-state IPv6 fragmentation and reassembly between
VPN tunnel endpoints is expected as normal operation in this
model.

> It can be facilitated if the tunnel is treated as only one 
> flow,

Can you say more about what you mean by this?

> with packets in general kept in sequential order.

In-order delivery is not a strict requirement for
correct IPv6 reassembly - but the fact that steady-state
IPv6 frag/reass is required seems onerous.

Fred

> 2. Then the IPv6 service is somewhat damaged concerning fault 
> diagnosing, like the underlying IPv4 service.
> (Since IPv4 fragments rather than returning packet-too-big 
> ICMP messages, this cannot concern MTUs).
> 
> Yet, there remains another problem with the replacement of 
> 1280 by "IPv4 MTU - 28" (I proposed it too quickly) because 
> it creates risks of fragmentation ...
>   
> 
> 
> 
> 
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 13 Oct 2010 17:43:26 +0200

> Or they might be reassembled in the NAT(s) in front of
They would indeed.
But they would then be forwarded across the customer network.
There, they may somewhere be fragmented to fit into fragments shorter than the ISP MTU + 28.
This happens for example if the ISP IPv6 MTU would be 1500-28 and that of some link in the customer site would be 1500-40 (say, for an IPv4 in IPv6 tunnel). 
Right?

> Actually, 1280+40+IPsec headers and trailers in the case

I was only discussing the direct IPv6 in IPv6 case.
But, yes, it is in general 1280 + the encapsulation header, whatever its size.

> VPN tunnel endpoints is expected as normal operation in this

Yes.
(A consequence of privileging connectivity and stateless operation).

> Can you say more about what you mean by this?

I mean that, because packets are almost always kept in sequence for a flow (otherwise TCP efficiency would be in general very poor) reassembly can be limited to consecutive fragments of only one datagram (the one being currently reassembled).
A packet permutation that interleaves fragments of two different datagrams leads in this case to a loss (but with low enough a frequency for it to be acceptable). 
This is significantly simpler than in the case where fragments of many datagrams my be interleaved.
 
> IPv6 frag/reass is required seems onerous.

See just above.

Regards,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Oct 2010 13:04:39 -0700

Hi Remi, 

> Sent: Wednesday, October 13, 2010 8:43 AM
> To: Templin, Fred L
> This happens for example if the ISP IPv6 MTU would be 1500-28 
> and that of some link in the customer site would be 1500-40 
> (say, for an IPv4 in IPv6 tunnel). 
> Right?

The fact of life is that we have the ISP managed network
domain and the end user network unmanaged network domain,
whether the ISP controls the CPE or not. The managed domain
should be well-behaved, but any manner of MTU irregularities
is possible within the unmanaged domain. For example, I can
login to my Linksys home router and manually set the MTU to
any value I want.

Anything that can be configured can be mis-configured, and
the ISP has no control of any misconfigurations that might
occur in the end user network. As far as the ISP can tell,
the end user network is just a black hole that silently
consumes packets. 
 
> But, yes, it is in general 1280 + the encapsulation header, 

Right, and whatever size the encapsulation header it makes
the underlying 1280 MTU insufficient for efficient operation.

> (A consequence of privileging connectivity and stateless operation).

That could become onerous. Let's say that an IPv6 tunnel
is configured over an IPv6-in-IPv4 tunnel with MTU=1280.
Then, the IPv6 packets would be fragmented into packet
pairs with the first being 1280 and the second being
80 bytes. That means that there would be a long/short
packet pair sent whereas a single long packet could be
sent if the IPv6-in-IPv4 tunnel had a slightly larger MTU.

One of the benefits of keeping a small amount of state is
that black hole detection is made possible such that a
larger tunnel MTU can be configured. This would lead to
more efficient handling of packets that are just slightly
larger than 1280.

> I mean that, because packets are almost always kept in 
> sequence for a flow (otherwise TCP efficiency would be in 
> general very poor) reassembly can be limited to consecutive 
> fragments of only one datagram (the one being currently reassembled).
> A packet permutation that interleaves fragments of two 
> different datagrams leads in this case to a loss (but with 
> low enough a frequency for it to be acceptable). 
> This is significantly simpler than in the case where 
> fragments of many datagrams my be interleaved.

Well, reordering and duplication are always possible within
the network. But, I'm not sure here whether you are referring
to IPv6 reassembly in the end system or IPv4 reassembly in
the network. The former should work, while the latter has
known issues at high data rates (RFC4459). Both are inefficeint.

Thanks - Fred

---

From: Rémi Després <[email-masked]>
Date: Thu, 14 Oct 2010 09:09:11 +0200

> the end user network is just a black hole that silently

The point isn't about misconfigurations.
It is that stateless tunnels (i.e. without SEAL ...) are legitimate within customer sites.
They can lead some intra-site IPv4 PMTUs that are less than 1500, and even less than 1500 - 28.

Then, because the 6a44 design privileges robustness, it is better to avoid more constraints on intra-site PMTUs than those that are absolutely mandatory.
In order to statelessly support IPv6/UPD/IPV4 packets intra-site IPv4 PMTUs of 1280 + 8 + 20 = 1308 octets IS the obligation (one that should be satisfied with all realistic stateless tunnels in customer sites).

RD

---

From: Washam Fan <[email-masked]>
Date: Thu, 14 Oct 2010 20:50:06 +0800

Hi Fred,

Please see inline. I did have some different assumptions. And those
assumptions might be wrong. It might be better at this stage we let
the tunneled IPv6 MTU be 1280 and tunneling IPv4 MTU not less than
1308.

> in the path; each imparting their own MTU uncertainties.

I assume H->N->S PMTU can be probed, Ns in between should be capable
of translating ICMPv4 messages appropriately. As you said, S->N->H can
not be probed as Ss are stateless.

> reach the multiple S's.

I assume all Ss shared the same MTUs since they are located in managed
networks. Or the MTU on their interfaces attaching SP networks can be
configured with the least IPv4 MTU value.

> Second, how does H discover SP_MTU;
> and getting a PTB message back?

I assume H can discover PMTU traversing Ns in between.

> Again, this won't give a

I assume all Ss configured with the same MTUs on their interfaces
attaching to SP networks.

> potential host H? I assume the goal is for a completely

I assume MTU is statically configured on Ss' interfaces attaching the
SP networks.

> is an anycast (and not unicast) address.

See above.

Thanks,
washam

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Oct 2010 05:40:16 -0700

Hi Remi, 

> Sent: Thursday, October 14, 2010 12:09 AM
> To: Templin, Fred L

No; the point is that (without a deterministic MTU discovery
scheme) you can't control the few end user networks that set
a 1308 MTU so the vast majority of end user networks that
set a 1500+ MTU are made to suffer.

Fred

> Then, because the 6a44 design privileges robustness, it is 
> better to avoid more constraints on intra-site PMTUs than 
> those that are absolutely mandatory.
> In order to statelessly support IPv6/UPD/IPV4 packets 
> intra-site IPv4 PMTUs of 1280 + 8 + 20 = 1308 octets IS the 
> obligation (one that should be satisfied with all realistic 
> stateless tunnels in customer sites).
> 
> RD
> 
> 
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 14 Oct 2010 06:08:28 -0700

Hi Washam, 

> Sent: Thursday, October 14, 2010 5:50 AM
> To: Templin, Fred L

All of your assumptions are lowest-common-denominator.
All end user networks are made to suffer because of the
few that are poorly configured. GigE is a current day
reality, and MTUs much larger than the lowest common
denominator should be made available to the end user
networks that paid good money for them when possible.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 Oct 2010 11:09:46 +1300

Fred,

> All of your assumptions are lowest-common-denominator.

What else can an operator safely do but make such assumptions?

Regards
   Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 15 Oct 2010 05:56:46 -0700

Hi Brian, 

> [mailto:[email-masked]] On Behalf Of Brian 
> E Carpenter
> Sent: Thursday, October 14, 2010 3:10 PM
> To: Templin, Fred L

They can roll up their sleeves and probe the paths to
the clients.

Thanks - Fred