Subject: Re: FW: 6PE Path MTU Discovery

From: "Levy-Abegnoli, Eric" <[email-masked]>
Date: Tue, 20 Feb 2007 14:20:46 +0100

Hi Roberta,
see comments in line

At 12:35 20/02/2007 +0100, Maglione Roberta wrote:
>Re-sending because I didn't see the original mail on the mailing list...
>Sorry for double posting.
>
>Roberta
>
>------------------------------------------------------------------------
>----
>Roberta Maglione
>Telecom Italia - Broadband Network Services Innovation
>Via G. Reiss Romoli, 274 - 10148 Torino - Italy
>Phone: +39 011 228 5007
>e-mail: [email-masked]
>------------------------------------------------------------------------
>------
>
>
>-----Original Message-----
>From: Invernizzi Fabrizio
>Sent: Friday, February 16, 2007 10:40 AM
>To: [email-masked]'
>Cc: Maglione Roberta
>Subject: 6PE Path MTU Discovery
>
>Hi all
>
>we are currently investiganting on the deployment impacts of the 6PE
>solution as described in the recently published RFC4798 (Connecting IPv6
>Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)) and we
>have some doubts about the IPv6 Path MTU discovery mechanism traversal
>of a MPLS cloud described in the RFC.
>In particular the section 3 says:
>"... , routers in the IPv4 MPLS network have the option to
>    generate an ICMP "Packet Too Big" message using mechanisms as
>    described in section 2.3.2 "Tunneling Private Addresses through a
>    Public Backbone" of [RFC3032]."
>
>What is not clear to us is:
>1- how can a P router, IPv4 only, generate an IPv6 icmp message (for
>example, which source addres should it use?)

If the router is IPv4 only, it simply cannot. However, if it has IPv6 
capability, but not IPv6 connectivity, then it is not very different from a 
P router when it needs to generate an ICMP message to a VPN destination. 
Does not know the destination; and does not have any topologically  valid 
source address. For reaching the destination, it tunnel the icmp message in 
mpls. For the source, it picks one among the one it has, and "hope" the 
destination will not filter it.
For 6PE, it's the same. The source address can be any IPv6 address in the 
box, and if they are none, it can be a v4-mapped IPv6 address. None is 
going to be topologically correct of course ...

>2- does this imply enabling IPv6 on all the MPLS network? If yes, is
>correct to say that this would reduce the benefits of using the 6PE
>solution? (no changes required on the MPLS network and IPv6 enabled only
>on the "edge" routers, the 6PEs)

No, not at all. IPv6 does not need to be enabled. But P-routers need to be 
capable of generating IPv6 icmp messages, and tunnel them per RFC3032, 
section 2.3.2 ("Tunnelling Private Addresses through a Public Backbone")
Eric

>Would be interesting for this community to investigate a mechanism to
>make the 6PE routers able to dynamically discover the PMTU for each LSP
>to be used to transport the IPv6 packets through the MPLS network(may be
>leveraging on the native MPLS PMTU discovery mechanism?)
>If yes, we are available to cohoperate to produce a proposal on this
>topic.

>Thanks in advance
>
>Roberta and Fabrizio
>--------------------------------------------------------------------
>
>CONFIDENTIALITY NOTICE
>
>This message and its attachments are addressed solely to the persons above 
>and may contain confidential information. If you have received the message 
>in error, be informed that any use of the content hereof is prohibited. 
>Please return it immediately to the sender and delete the message. Should 
>you have any questions, please contact us by replying to 
>[email-masked].
>
>         Thank you
>
>                                         www.telecomitalia.it
>
>--------------------------------------------------------------------
>

---

From: "Levy-Abegnoli, Eric" <[email-masked]>
Date: Thu, 22 Feb 2007 18:06:32 +0100

Hi Fabrizio,
At 15:24 22/02/2007 +0100, Invernizzi Fabrizio wrote:
>Hi Eric
> >       If the router is IPv4 only, it simply cannot. However, if it has
>IPv6 capability, but not IPv6 connectivity, then it is not very
>different from a P router when it needs to generate an ICMP message to a
>VPN destination. Does not know the destination; and does not have any
>topologically  valid source address. For reaching the destination, it
>tunnel the icmp message in mpls. For the source, it picks one among the
>one >it has, and "hope" the destination will not filter it.
> >       For 6PE, it's the same. The source address can be any IPv6
>address in the box, and if they are none, it can be a v4-mapped IPv6
>address.
> >None is going to be topologically correct of course ...
>
>
>
>We agree with you about the general behaviour of a P regarding an ICMP
>(v4/v6) message to be sent back to a generic source. However, as you
>say, a P node in an MPLS backcbone is not able to generate an IPv6
>packet (in this case an ICMPv6). So a specific functionality is required
>for the P router to generate the IPv6 packet even if IPv6 has not been
>enabled (may be supported, but not enabled).
>IMHO this would require, to fully support the 6PE mechanism, an upgrade
>of all the P-router releases; that is exactly what i was trying to avoid
>with the 6PE solution.

If you are after a mechanism that would enable the ingress PE to 
"v4-discover" the MTU
up-front, so that it can report it to the IPv6 host if needed (via IPv6 
PMTU), I am completely with you. I guess something in the line of rfc3988 ...
My concern is not (lack of) P's icmpv6 capability. But even if it has it, 
when it has an outgoing link MTU smaller than 1280, it is guarantied to 
black-hole IPv6 traffic (icmpv6 messages won't go through as they have to 
reach the egress PE). In addition, if the P does not have an IPv6 address, 
and has to use a v4-mapped, any source-address filtering mechanism (uRPF, 
acl, etc.) is going to block it.
Eric

>Roberta & Fabrizio