Hi Tina,

To use PMTU in this scenario, this is more complicated than what you explain. 
First, this traffic flow is from mAFTR to the mB4. In between, there could be 
more than one IPv6 multicast routers. In our spec, mAFTR will replicate the 
packet once in the multicast I/F to the IPv6 MDT, can you explain to me your 
poropose how PMTU can work here? Does it mean mAFTR will send PMTU to every B4s 
and take the least common denominator?

Regards,
Yiu

From: Jacni Qin <[email protected]<mailto:[email protected]>>
Date: Sat, 27 Aug 2011 09:48:12 +0800
To: Tina TSOU 
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: [Softwires] Comments on section 6.3 of 
draft-qin-softwire-dslite-multicast-04

hi,

On Sat, Aug 27, 2011 at 2:32 AM, Tina TSOU 
<[email protected]<mailto:[email protected]>> wrote:
Dear Jacni,
Just after reading RFC 1981, I think fragmentation of IPv6 is needed. In 
section 5.1, it says, “It is possible that a packetization layer, perhaps a UDP 
application outside the kernel, is unable to change the size of messages it 
sends.  This may result in a packet size that exceeds the Path MTU.
To accommodate such situations, IPv6 defines a mechanism that allows large 
payloads to be divided into fragments, with each fragment sent in a separate 
packet (see [IPv6-SPEC] section "Fragment Header").”

If the node which makes PMTU is the multicast source, it can change the size of 
message when the size exceeds the PMTU value.
However, mAFTR, as a router, is unable to change the size of the message. Here 
is an example: An IPv4 packet is sent from the multicast source to mAFTR with 
size of 1000, while the IPv6 PMTU for mAFTR and mB4 is 960, how does mAFTR 
forward the packet? One possible way is to make IPv6 fragmentation, with two 
fragments: one is 960 and the other is 40 with “IPv6 Fragment Header”.
In addition, there may be also other ways to avoid fragmentation, e.g., cache 
in mAFTR as defined in [draft-jiang-behave-v4v6mc-proxy].

Jacni>: Please see Yiu's comments,
while for the discovery if you really want to do it, this way to help you to 
understand, it's the end point of tunnel which seems to "source" the v6 
packets. Hope you can get it.


Cheers,
Jacni


_______________________________________________ Softwires mailing list 
[email protected]<mailto:[email protected]> 
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to