Subject: [pim] IPv6 Register Fragmentation

From: [email-masked]
Date: Tue, 18 May 2004 19:43:33 +0900

Hello,

I have a few comments regarding the Register message fragmentation in IPv6,
described as below in draft-ietf-pim-sm-v2-new-09.

    In IPv6, the DR MUST perform Path-MTU discovery, and an ICMP
    Fragmentation Required message MUST be sent by the encapsulating DR if
    it receives a packet that will not fit in the effective MTU of the
    tunnel.  If the MTU between the DR and the RP results in the effective
    tunnel MTU being smaller than 1280 (the IPv6 minimum MTU), the DR MUST
    send Fragmentation Required messages with an MTU value of 1280 and MUST
    fragment its PIM register messages as required, using an IPv6
    fragmentation header between the outer IPv6 header and the PIM Register
    header.

Here are my comments.

1) "ICMP Packet Too Big message" is appropriate rather than
   "ICMP Fragmentation Required message" in IPv6.

2) I believe that DR should not send ICMP Packet Too Big message
   when the original multicast packet is equal or smaller than
   the IPv6 minimum MTU. 
   The sender of multicast packets cannot send smaller packets,
   even if it has received such ICMP message. 

   I think IPv6 Register fragmentation should be treated the same as
   "IPv6 Tunnel Packet Fragmentation" described in RFC2473 Section 7.1.

   That is, ICMP "Packet Too Big" message should be sent by the
   encapsulating DR if the original IPv6 packet size is larger than
   the IPv6 minimum MTU. If the original IPv6 packet is equal or smaller
   than  the IPv6 minimum link MTU, DR must fragment its PIM register
   messages as required, using an IPv6 fragmentation header between
   the outer IPv6 header and the PIM Register header.

   IMHO, the encapsulating DR MAY fragment its register message whenever
   the original IPv6 packet size is larger than the effective tunnel MTU,
   and MAY not send ICMP "Packet Too Big" message.
   Because RP can process such fragmented register messages, and I think
   many implementations currently would works so. 

Any comments would be appreciated.

Best Regards,
Shiroko.

_______________________________________________
pim mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pim

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 May 2004 20:47:45 +0200

> described as below in draft-ietf-pim-sm-v2-new-09.

I also have a comment on this that I've meant to give for some time.

>     tunnel.  If the MTU between the DR and the RP results in the effective
[...]

I don't think is a good idea. Usually I think it's better to have
the DR simply fragment the register packets instead of sending
"Packet Too Big" back.

Let me try to describe why I don't like it. Let's say for simplicity
that we have a PIM domain where all links have MTU 1500, and a source
sends 1500 byte datagrams. The MTU of the register tunnel is <1500 so
the DR will send ICMP PTB to the source. The source learns the smaller
PMTU and starts sending fragmented datagrams.

I believe that it's common for the RP to switch to native forwarding
immediately. Once the switch is done there's no need for fragmentation.
But the source will keep fragmenting until it tries to send larger
packets again, that typically happens after 10 minutes. At least some
implementations use 10 minutes, and it's also suggested in RFC 1191.

So, the first few packets, perhaps for a couple of seconds, are
sent as register packets; while the source will unnecessarily keep
doing it for say 10 minutes.

In this case I believe it's better for the DR to fragment the packets
itself. I would rather say that the DR MAY send ICMP PTB. Whether the
DR does it or not can be implementation specific. Some DRs could
immediately send ICMP PTB back, others could do it if they keep
registering for a long time or if load is too high or whatever. But
I don't think it should be a MUST.

I'm aware that one is supposed to always do PMTU discovery in IPv6
and do fragmentation at the source, but do we really need to follow
this for register tunnels?

Stig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 May 2004 23:14:35 +0300 (EEST)

> this for register tunnels?

Bear in mind that this requires also defragmentation at decapsulation.

There's at least one hardware implementation that AFAIR doesn't do 
defrag.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 May 2004 22:30:17 +0200

> There's at least one hardware implementation that AFAIR doesn't do 

ok, but the draft also says:

   In IPv6, the DR MUST perform Path-MTU discovery, and an ICMP
   Fragmentation Required message MUST be sent by the encapsulating
   DR if it receives a packet that will not fit in the effective MTU
   of the tunnel.  If the MTU between the DR and the RP results in the
   effective tunnel MTU being smaller than 1280 (the IPv6 minimum MTU),
   the DR MUST send Fragmentation Required messages with an MTU value
   of 1280 and MUST fragment its PIM register messages as required,
   using an IPv6 fragmentation header between the outer IPv6 header
   and the PIM Register header.

So there are valid cases where the register message will be fragmented
anyway (even with the current MUST).

One more thing. By only reading the text above, it might seem that
one should send ICMP PTB (FragReq) every time a packet too large
for the <1280 register tunnel MTU is received. I don't think it
should be, at least not if the packet was 1280. In that case the
source won't fragment the packet anyway and possibly keep sending
1280 byte packets. Also IPv6 hosts not doing PMTU discovery would
send packets up to 1280 anyway. So I believe one should only send
ICMP PTP if the packet was >1280.

Stig

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 May 2004 23:14:35 +0300 (EEST)

---

From: Stig Venaas <[email-masked]>
Date: Wed, 19 May 2004 22:30:17 +0200

Stig