Subject: Re: [dhcwg] [Softwires] SOFTWIRE working group last call on 6rd

From: Ole Troan <[email-masked]>
Date: Sun, 7 Mar 2010 08:27:56 +0100

Timothy,

>> We'd like to announce the softwire WG LC on the 6rd technology. I've
>> copied both SOFTWIRE and DHC mailing lists and solicit comments from both
>> groups of experts. The draft is here:
>> 
>> http://www.ietf.org/internet-drafts/draft-ietf-softwire-ipv6-6rd-07.txt
> 
> The end of section 4 states:
>  "The prefix lifetimes
>   advertised in Router Advertisements or used by DHCP on the CE LAN
>   side MUST be equal to or shorter than the IPv4 address lease time."
> 
> PPP doesn't have the concept of a lease time, which makes that MUST 
> impossible. Instead the advertised prefixes must be revoked if the IPv4 
> address changes, and if the prefix has not be written to persistent storage 
> the advertised must be short (about a minute) to prevent prolong mis-
> configuration of the hosts in the event of the IPv4 address changing after a 
> reboot of the router.
> 
> In the case of DHCPv4, is it intended to prohibit assigning a new address to 
> CE router before its address lease expires, even if the router reboots to 
> the DHCPv4 INIT state?

the intention is to achieve some resemblance of a renumbering event. difficult when you typically have zero overlap between the old and the new prefix.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Mar 2010 14:33:04 +0100

all,

thank you very much for good and constructive comments!
I've tried to summarize the comments received and the changes made below.

cheers,
Ole

** Include option Parameter Request List option for the DHCPv4 option:
   New text:
	 <t>The CE MUST include a Parameter Request List Option <xref
	 target="RFC2132"></xref> for the OPTION_6RD. Because the
	 OPTION_6RD contains one IPv4MaskLen/6rdPrefixLen/6rdPrefix
	 block, and because DHCP cannot convey more than one instance
	 of an option, OPTION_6RD is limited to provision at most a
	 single 6rd domain.  Provisioning of a CE router connected to
	 multiple 6rd domains is outside the scope of this protocol
	 specification.</t>

   => Accepted

** Loop avoidance
   Suggestion was to adopt solution in
   draft-nakibly-v6ops-tunnel-loops. Issues with scalability and
   checking of "well-known" bits in ISATAP addresses.

   => Keep existing text.  

** MTU
  There are well documented issues with tunnels and MTU. There are
  issues with anycast and fragmentation. The draft references the
  existing mechanisms for tunnelling and MTU, and recommend following
  existing practice. Since the mechanism is contained within a single
  SP network, one can assume that the MTU is well managed. Just as in
  an MPLS network. 

  => Keep existing text. Should the working group start a separate
  effort for a more general solution to MTU issues?
   
** Use of anycast
   There are issues with the use of anycast. The draft
   supports the use of unicast BR addresses too. The issues around
   ECMP, fragmentation and ICMP messages ending up on the wrong BR are
   to some extent operational. It depends on the network having a well
   maintained MTU as recommended in the draft. ECMP should be done on
   a per flow basis not on a per packet.

   => Keep existing text.

** Analysis of domain of applicability
   The draft already sets the context of the solution to within an SP
   network. More detail and operational scenarios might be more
   suitable to a 6rd operational document.

   => No action.
  
** IPv4 lease time in case of PPP
   What lease-time should be used on the LAN-side in IPv6 RAs when the
   IPv4 WAN side address is aquired via IPCP?

  Proposed new text:

      <t>6rd IPv6 address assignment and hence the IPv6 service itself
      is tied to the IPv4 address lease, thus the 6rd service is also
      tied to this in terms of authorization, accounting, etc. For
      example, the 6rd delegated prefix has the same lifetime as its
      associated IPv4 address. The prefix lifetimes advertised in
      Router Advertisements or used by DHCP on the CE LAN side MUST be
      equal to or shorter than the IPv4 address lease time. If the
      IPv4 lease time is not known, the lifetime of the 6rd delegated
      prefix SHOULD follow the defaults specified in <xref
      target="RFC4861"></xref>.</t>

   => Accepted.

---

From: Rémi Després <[email-masked]>
Date: Mon, 8 Mar 2010 15:01:14 +0100

Hi Ole,

Thanks for this useful summary.
The point below, discussed on Friday is one more for your list.

Cheers,
RD

> 
> De : Brian E Carpenter <[email-masked]>
> Date : 5 mars 2010 21:37:59 HNEC
> 
> On 2010-03-06 05:52, Templin, Fred L wrote:

>>> -----Original Message-----
>>> From: Rémi Després [mailto:[email-masked]]
>>> Sent: Friday, March 05, 2010 6:34 AM
>> 

>>> 
>>> 
>>> Until PMTUD is made reliable in IPv6 (btw an important objective), all IPv6-enabled hosts should have
>>> their MTU set to 1280 to avoid IPv6 blackholes.
>>> This could in principle apply only to IPv6 packets that leave customer sites, but as long as hosts
>>> have only one MTU parameter, it has to apply to all packets.
>>> Since typical hosts have longer default MTUs than 1280, advertising MTU=1280 on links that offer
>>> paths to the global Internet appears to be the only available tool at hand.
>>> 
>>> The proposal is then to replace:
>>> "A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automatically or configured
>>> directly, on the LAN side by setting the MTU option in Router Advertisements [RFC4861] messages to
>>> the 6rd Tunnel MTU."
>>> by:
>>> "As long as the path MTU discovery has not been made reliable, a 6rd CE SHOULD advertise on the LAN
>>> side, in the MTU option of Router Advertisements [RFC4861], an  MTU of 1280 octets . This is to
>>> prevent that longer packets that could have traversed the local 6rd domain may be discarded, because
>>> of their size, further in the Internet because of their size. Note that this may cause all hosts
>>> attached to the link to use a reduced MTU even for link-local communications, IPv6 and IPv4."
>> 
>> The 1280 would be disappointing; I'm sure we can do better.
> 
> As has been said before, in theory there is no difference between theory
> and practice, but in practice, there is.
> 
> Right now today a number of ISPs are planning to deploy 6RD, and we have
> already seen clear evidence from 6to4 deployment that setting the MTU to
> 1280 is a necessary evil at the moment. So I think this advice should be
> in the specification, as a SHOULD. Otherwise we'd be misleading those
> ISPs.
> 
> I don't like this any more than you do, from a long term perspective.
> 
>     Brian

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Mar 2010 09:53:45 -0800

Ole,

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Monday, March 08, 2010 5:33 AM
> To: Durand, Alain
> Cc: softwires; DHC WG; David Ward
> Subject: [dhcwg] 6rd LC - summary of comments
> 
> all,
> 

If 6rd used SEAL, the CE would be able to set a much
larger tunnel MTU (say, 64KB). Then, end systems in
customer sites would be able to automatically discover
and utilize larger MTUs as long as the SP network links
can support them. (And no; I am *not* requiring the CE
or BR devices to support segmentation and reassembly
unless they want to.)

But, SEAL is about more than just MTU - it also includes
mechanism to detect and defeat IPv4 source address spoofing.
Since the 6rd checks are useless if IPv4 source address
spoofing is possible, it is necessary to consider the
domain of applicability to determine whether anti-
spoofing mitigations are needed. SEAL provides such
a mitigation.

>    a per flow basis not on a per packet.

I have shown that there is a possibility for data corruption
for BR use of anycast source address - to the point that the
BRs MUST ensure that no fragmentation will occur when anycast
source is used. That means that the BR MUST set DF=1 if it
uses an anycast source address. The document needs to say
that somewhere.

>    suitable to a 6rd operational document.

I disagree; there are operational limitations that would
limit applicability to only tightly-managed SP network
scenarios as I have pointed out in my messages. The
document therefore requires an applicability statement,
as has been required for other "transition" mechanisms.

Fred
[email-masked]

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Mar 2010 20:07:33 +0100

Fred,

[...]

> or BR devices to support segmentation and reassembly

not quite sure what the purpose of a 64KB MTU on the tunnel link would be, but sure a 1500 byte MTU would have been nice. I'm unsure of the consequences of reassembly/fragmentation on the tunnel end-points. so far experience has shown that to be 'harmful'. would SEAL be any different?
6rd is a patch to 6to4. one goal of 6rd was to be able to ride on an existing 6to4 implementation with only small changes. SEAL would not be that. 

I'm fine with working on more general solutions to the MTU problem which may then apply to any tunnel. I would not want to accept SEAL as that solution without much more analysis.

> spoofing mitigations are needed. SEAL provides such

I missed that part of SEAL. pointer?

> uses an anycast source address. The document needs to say

it follows the rules and setting of the DF bit as specified in RFC4213.

> as has been required for other "transition" mechanisms.

in the introduction we have:

   6rd specifies a protocol mechanism to deploy IPv6 to sites via a
   Service Provider's (SP's) IPv4 network.  It builds on 6to4 [
   RFC3056],  with the key differentiator that it utilizes an SP's own IPv6 address
   prefix rather than a well known prefix (2002::/16).  By using the
   SP's IPv6 prefix, the operational domain of 6rd is limited to the SP
   network and under its direct control.  From the perspective of
   customer sites and the IPv6 Internet at large, the IPv6 service
   provided is equivalent to native IPv6.

I'm not sure what more needs to be said. at least not in the basic protocol spec. (which I originally wanted to be a single page saying: this is 6to4 with a SP prefix instead of 2002::/16). :-)

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Mar 2010 12:00:19 -0800

Ole,

> Sent: Monday, March 08, 2010 11:08 AM
> To: Templin, Fred L
> Cc: Durand, Alain; softwires; David Ward; DHC WG
> Subject: Re: [dhcwg] 6rd LC - summary of comments
> 
> Fred,
> 
> [...]
> 
> >> ** MTU
> not quite sure what the purpose of a 64KB MTU on the tunnel link would be, but sure a 1500 byte MTU
> would have been nice.

The 64KB MTU is to admit packets into the tunnel without any
pre-conceived notion of an initial size restriction. Any size
restrictions will then be discovered dynamically, with a
reduced size conveyed back to the original source if necessary.

> I'm unsure of the consequences of reassembly/fragmentation on the tunnel end-
> points. so far experience has shown that to be 'harmful'. would SEAL be any different?

With SEAL, the tunnel egress can choose to reassemble as much
or as little as it likes, with the limiting case being that the
egress performs no reassembly at all. In that case, SEAL still
provides value since the tunnel will still be able to support
larger MTUs (e.g., 9KB) as long as all links in the SP network
between ingress->egress support an MTU at least that large.

In the case that the egress decides to support some reassembly
(e.g., up to 1500 bytes), SEAL avoids the issues incurred for
IP fragmentation and reassembly since it uses a (much) larger
ID to unambiguously associate fragments of the same packet.
SEAL also has a way of gracefully "backing down" if reassembly
becomes problematic due to excessive congestion so that "loss
unit smaller than retransmission unit" would be a short-lived
transient condition if it ever occurs in operational practice
(which I am told should be rare).

> 6rd is a patch to 6to4. one goal of 6rd was to be able to ride on an existing 6to4 implementation
> with only small changes.

It is still my view that 6rd "closes the gap" between 6to4
and ISATAP. Indeed, all three are implemented within the
same *.c module in the linux kernel.

> SEAL would not be that.

I have working code for RFC5320 with full segmentation and
reassembly, but tunnel endpoints that do not wish to support
reassembly can omit ~90% of that.
 
> I'm fine with working on more general solutions to the MTU problem which may then apply to any
> tunnel. I would not want to accept SEAL as that solution without much more analysis.

Then, let's get on with the analysis!

> I missed that part of SEAL. pointer?

(draft-templin-intarea-seal), Section 4.6.

> it follows the rules and setting of the DF bit as specified in RFC4213.

RFC4213 does not examine the implications of setting the DF
bit in the presence of anycast source address; 6rd must.
 
> I'm not sure what more needs to be said. at least not in the basic protocol spec. (which I originally
> wanted to be a single page saying: this is 6to4 with a SP prefix instead of 2002::/16). :-)

>From a few mails back, here are the items which I believe bear
specific mention in an applicability statement:

  "During the NGTRANS days, the ISATAP team was strongly required
  to include a "Domain of Applicability" statement, and I think
  the same should be required of 6rd. I see a number of aspects
  of 6rd that IMHO would limit its applicability, including:
  
  - IPv6 prefix tied to IPv4 address (renumbering implications)
  - potential black holes when ICMPs can't be translated
  - provider-aggregated addressing only (no provider-independent)
  - not compatible with multihoming via a single, stable IPv6 prefix
  - not compatible with traffic engineering (i.e., CE can't select
    specific BRs)
  - interactions with load balancing; ECMP within provider network
  - MTU clamping exposes degenerate MTUs to the customer network
    and doesn't allow for automatic discovery of larger MTUs
  - requires operators to exercise tight controls on link MTUs
  - requires operators to exercise tight controls on ICMP
    generation and ICMP filtering"

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Mon, 8 Mar 2010 21:56:41 +0100

Fred,

[...]

> same *.c module in the linux kernel.

OK, so we don't quite see that the same then. I see ISATAP and RFC2529 as siblings. and 6to4 and 6rd together. all with automatic tunnels from rfc1933 as their common ancestor. anyway, not particularly important.

> Then, let's get on with the analysis!

sure, but let's do that on a separate thread. I do not want to make 6rd dependent on SEAL at this point.

> (draft-templin-intarea-seal), Section 4.6.

OK, still didn't get it.

> bit in the presence of anycast source address; 6rd must.

OK, what about: 
"The use of an anycast source address may lead to any ICMP error message generated on the path being sent to a different BR. Therefore using dynamic tunnel MTU [section 3.2.2, RFC4213] is subject to IPv4 Path MTU blackholes."

>    generation and ICMP filtering"

as in:
http://tools.ietf.org/html/rfc5214#section-4

we have covered that reasonably well already. I think some of those issues could well be covered in a deployment document though.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 8 Mar 2010 13:39:00 -0800

Ole,

> From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
> Sent: Monday, March 08, 2010 12:57 PM
> To: Templin, Fred L
> OK, so we don't quite see that the same then. I see ISATAP and RFC2529 as siblings. and 6to4 and 6rd
> together. all with automatic tunnels from rfc1933 as their common ancestor. anyway, not particularly
> important.

The more accurate comparison is between 6rd and VET
rather than 6rd and ISATAP. Both 6rd and VET work within
a closed domain (which VET chooses to call an "enterprise"
or "site", but for which an ISP SP network is simply one
use case example) and both 6rd and VET deal with discovery
and utilization of exit routers that can reach networks
outside of the SP network domain. 6rd CE routers fit the
same role as VET EBRs, and 6rd BRs fit the same role as
VET EBGs. In many ways, 6rd is just VET with a number of
shortcuts taken (e.g., anycast, stateless PD etc.).

> sure, but let's do that on a separate thread. I do not want to make 6rd dependent on SEAL at this

This gets back again to the crux question. If 6rd can go
forward with robust MTU handling in the first iteration
it would greatly reduce the pressure for ISPs to upgrade
their entire infrastructure to native IPv6 - perhaps even
indefinitely. So, why not get it right the first time?

> > (draft-templin-intarea-seal), Section 4.6.

Can you be more specific? Did you not understand what
was written, or do you think there is something wrong
with it?

> "The use of an anycast source address may lead to any ICMP error message generated on the path being
> sent to a different BR. Therefore using dynamic tunnel MTU [section 3.2.2, RFC4213] is subject to
> IPv4 Path MTU blackholes."

I have told you several times what is wrong with anycast
source and DF=0. If you want to remain silent and allow
open a potential for undetected data corruption, that
seems like a serious omission.

> deployment document though.

I gave you a valid list of limitations above. These speak
to the need for truth in advertising in terms of where 6rd
is suited for operation and where it is not.

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 09 Mar 2010 11:06:49 +1300

Ole,

I agree with this as a summary of the common ground in the
discussions, even if a few people may disagree here and there.

>   effort for a more general solution to MTU issues?

Agreed to the existing text. Also, I'm not sure that the general
discussion is specific to SOFTWIRE. Maybe it should be raised
in INTAREA?

Regards
   Brian Carpenter

On 2010-03-09 02:33, Ole Troan wrote:
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 8 Mar 2010 23:25:37 +0100

> between ingress->egress support an MTU at least that large.

The discussion on SEAL, despite some interesting technical issues, does not belong to this last call discussion:
- 6rd is an transition technique which, to be as useful as it can be for rapid IPv6 deployments, should be stabilized asap. 
- The DHCP option, which is specified in this document and nowhere else is urgent.
- Combining SEAL with 6rd is a disjoint subject. 

>  - potential black holes when ICMPs can't be translated

- There is no potential blackhole caused by 6rd per se.
- Potential blackholes of IPv6 packets as long as ICMPv6 error messages and PMTUD are not treated properly belong to IPv6 in general, not to 6rd. 
- Such blackholes can be completely avoided in the short term, despite buggy ICMPv6 and/or PMTUD treatments, by sending IPv6 packets that don't exceed 1280 octets, the guaranteed IPv6 path MTU of RFC 2460.
- Provided *the last sentence of the section 9.1 on MTUs is deleted* (as already proposed in my previous e-mail), the document is therefore sound in this respect.  

IMHO, with modifications Ole has listed, and with the sentence deletion above, the draft can be accepted.

Regards,
RD

---

From: Ole Troan <[email-masked]>
Date: Wed, 10 Mar 2010 12:12:02 +0100

Fred,

[...]

> indefinitely. So, why not get it right the first time?

if there was consensus on what's right...
SEAL appears to be a solution described in section 3.1, RFC4459.
the 6rd draft is leaning towards the solution described in section 3.3 of RFC4459.

> was written, or do you think there is something wrong

OK, I see, so you pass a nonce around to use for verification against source spoofing. that requires state.

[...]

> seems like a serious omission.

sorry, yes I agree we should point that out.
what about:

  "The use of an anycast source address may lead to any ICMP error message generated on the path being sent to a different BR. Therefore using dynamic tunnel MTU [section 3.2.2, RFC4213] is subject to IPv4 Path MTU blackholes.

Multiple BRs using the same anycast source address may send fragmented packets to the same IPv6 CE at the same time. If the fragmented packets from different BRs happen to use the same fragment ID, incorrect reassembly may occur. For this reason a BR using an anycast source address MUST set the IPv4 Don't Fragment flag."

[...]

cheers,
Ole

---

From: Rémi Després <[email-masked]>
Date: Wed, 10 Mar 2010 14:01:53 +0100

Le 10 mars 2010 à 12:12, Ole Troan a écrit :
...
> Multiple BRs using the same anycast source address may send fragmented packets to the same IPv6 CE at the same time. If the fragmented packets from different BRs happen to use the same fragment ID,…

Note that in "well managed" 6rd domains (ref. sec 9.1), there is no fragmentation between BRs and CEs.
The DF bit has therefore no effect.
I don't see the need for this addition.

RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Mar 2010 15:04:59 -0800

Hi Ole,

Catching up on the recent exchanges:

> Sent: Wednesday, March 10, 2010 3:12 AM
> To: Templin, Fred L

Good question.

> SEAL appears to be a solution described in section 3.1, RFC4459.

No, that's not right; RFC4459, Section 3.1 talks about
*outer* fragmentation and reassembly, but SEAL explicitly
seeks to tune out any outer fragmentation whenever it occurs.
SEAL is also not an example of an inner fragmentation scheme
referred to in RFC4459, Section 3.4.

Instead, SEAL is a mid-layer segmentation and reassembly
approach described in RFC2764, Section 3.1.7. RFC4459 missed
this approach in its analysis.

> the 6rd draft is leaning towards the solution described in section 3.3 of RFC4459.

That section includes text that shows a clear need for an
applicability statement. For example:

  "This approach is highly assumptive of the deployment scenario."
 
> OK, I see, so you pass a nonce around to use for verification against source spoofing. that requires

That is true. Tunnel endpoints that wish to synchronize
sequence numbers must maintain state, e.g., in neighbor
cache entries. Tunnel endpoints that do not wish to
synchronize sequence numbers can omit this state, but
will not realize the benefits of avoiding off-path
spoofing attacks.

>   "The use of an anycast source address may lead to any ICMP error message generated on the path
> being sent to a different BR. Therefore using dynamic tunnel MTU [section 3.2.2, RFC4213] is subject
> to IPv4 Path MTU blackholes.
> 
> Multiple BRs using the same anycast source address may send fragmented packets to the same IPv6 CE at
> the same time. If the fragmented packets from different BRs happen to use the same fragment ID,
> incorrect reassembly may occur. For this reason a BR using an anycast source address MUST set the
> IPv4 Don't Fragment flag."

That pretty much matches up with what I asked for, so I
don't have a problem with it per se. Still, I feel we can
do so much better of a service to end users if we can get
them a solid 1500 as well as the ability to discover and
utilize larger MTUs without any assumptions of what links
might be in the ISP network path.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 11 Mar 2010 15:08:54 -0800

Remi,

> Sent: Wednesday, March 10, 2010 5:02 AM
> To: Ole Troan
> Cc: Templin, Fred L; Durand, Alain; softwires; DHC WG
> Subject: Re: [Softwires] [dhcwg] 6rd LC - summary of comments
> 
> 
> > Multiple BRs using the same anycast source address may send fragmented packets to the same IPv6 CE
> at the same time. If the fragmented packets from different BRs happen to use the same fragment ID,

Still, DF=0 is an open invitation to the network to
fragment the packet if it decides to do so, and there
is no recourse to say back to the network "you should
not have fragmented that". DF=1 gives the network no
leg to stand on whereby it could legitimately fragment
the packet.

Thanks - Fred

---

From: "Lee, Yiu" <[email-masked]>
Date: Fri, 12 Mar 2010 13:15:48 -0500

+1. I agree with the current text to handle MTU and I support to move
forward for this draft.

On 3/8/10 5:25 PM, "Rémi Després" <[email-masked]> wrote:

> - 6rd is an transition technique which, to be as useful as it can be for rapid
> IPv6 deployments, should be stabilized asap.
> - Potential blackholes of IPv6 packets as long as ICMPv6 error messages and
> PMTUD are not treated properly belong to IPv6 in general, not to 6rd.
> - Such blackholes can be completely avoided in the short term, despite buggy
> ICMPv6 and/or PMTUD treatments, by sending IPv6 packets that don't exceed 1280
> octets, the guaranteed IPv6 path MTU of RFC 2460.
> - Provided *the last sentence of the section 9.1 on MTUs is deleted* (as
> already proposed in my previous e-mail), the document is therefore sound in
> this respect.  
>

---

From: Rémi Després <[email-masked]>
Date: Sat, 13 Mar 2010 12:38:22 +0100

Lee,

1.
Good to have support for the 6rd RFC to progress now quickly.

How to interpret your support is however not 100% clear:
- either you agree on ALL what I propose, as the +1 suggests (i.e. with the deletion of the last sentence of 9.1).
- or you agree ONLY if this sentence is not deleted (as your "with the current text" suggests).

This is in fact a good opportunity to summarize, after many mails exchanged on-list and off-list, the problem with the following sentence:
<< A 6rd CE SHOULD advertise the 6rd Tunnel MTU, whether determined automatically or configured directly, on the LAN side by setting the MTU option in Router Advertisements [RFC4861] messages to the 6rd Tunnel MTU. >>

2.
The rationale to delete the sentence is AFAICT:

- A 6rd RFC is NOT the right place to recommend that the MTU advertised to host, on a given link, should differ from the real MTU of this link: the purpose of such a recommendation concerns IPv6 in general, not specifically 6rd. 

- Not having the sentence in the 6rd RFC doesn't prevent implementations to advertise reduced MTUs. 

- In any case, if advertising reduced MTUs is recommended, the technically consistent value is fixed (not ISP dependent), and is 1280 as explained below.

3.
The reason why, for IPv6 in general, 1280 is the right default transmit MTU comes from the following facts:

- 1280 is the PMTU that is guaranteed to be supported across all IPv6 paths. (Most paths are expected to have larger local MTUs than 1280, e.g. 1480 for 6to4 or 6rd across Ethernet links, but the only guarantee is "at least 1280"). 

- Standardizing a minimum PMTU was not needed in IPv4 because fragmentation is permitted within the network, which is NOT the case in IPv6. (The real minimum in IPv4, which is header + smallest fragment, i.e. 68, is not, like 1280, a practicable value for a transmit MTU). 

- 1280 is such that, on links having the most common MTU, i.e. 1500, a small number of piled up encapsulations can be supported, with a good margin in typical cases. 

- Hosts having 1280 as their default transmit MTU are not prevented from using larger MTUs on all e2e paths known to have larger MTUs: PMTU Discovery is designed for this. (PMTUD has some reported short term problems, but this should eventually be fixed.)

4.
Coming back to the 6rd draft:

- The text says:
"The 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU may be set to 1480 bytes".
The first sentence clearly suggests that some ISPs will have 6rd tunnel MTUs smaller than 1480. 

- Now, assume such an ISP has 1400 as its tunnel MTU. Then, if a 1480B packet is sent to it (from some ISP where 1480 is supported) it will fall into a blackhole: it will be discarded when entering the ISP network that has the 1400 MTU. 

Unless I am mistaken somewhere, the 6rd RFC MUST NOT recommended this to happen.    

On the other hand, if all hosts send 1280B packets maximum, the standard value has its intended effect: NO MTU RELATED BLACKHOLE. 
There is a cost in terms of performance of this MTU security but, thanks to a good choice of the standard value, this cost remains quit reasonable in typical cases: in the extreme case of TCP packets having all their maximum size, using 12810 instead of 1280 as transmit MTU reduces the number of packets by less than 17%).

Note also that the transmit MTU of Teredo is AFAICT 1280.

5. 
Conclusion: as more and more IPv6 will be deployed, it will be more and more important to make all IPv6 specifications right, and for this to understand how to avoid future blackholes.  

Best regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 17 Mar 2010 10:13:51 +0100

Le 1 mars 2010 à 08:44, Gabi Nakibly a écrit :
> ...
> Second, regarding loops via internal relays the draft mentions that:
>  
>    To avoid forwarding loops via other internal relays, the BR should
>    employ outgoing and incoming IPv4 packets filters, filtering out all
>    known relay addresses for internal 6rd BRs, ISATAP routers or 6to4
>    relays, including the well known anycast address space for 6to4.
>  
> Does the SP necessarily knows of every ISATAP router or 6to4 relay deployed in the 6rd domain? After all, a customer can deploy an ISATAP router or even a 6to4 relay for that matter without the knowledge of the SP, while using a configured tunnel (by a tunnel broker) for its IPv6 connectivity.

Gabi,

I didn't succeed to create a detailed configuration where a 6rd CE, which is also an ISATAP router, can create a routing loop.

Would you have one that you can share?

Cheers,
RD