Hi Erik, One more thing. The ICMP to the source is one issue which has been discussed in the earlier mail and you have rightly pointed.
I am already trying to work with Jonathan to get the solution for this. One of the ways is when using the new header we can have the address[0] contain the source address of the device which last modified the packet. ICMP can then be sent to this address. Regarding PMTUD have a look at RFC 4821 which extends RFC 1981 and you will understand what I mean by my previous mail. Thanks, Vishwas On Tue, Jun 1, 2010 at 9:50 PM, Vishwas Manral <vishwas.i...@gmail.com> wrote: > Hi Erik, > > Sorry for the late response. > > One thing I wanted to clarify was that not everytime we add data do we > change the source address. IPsec transport mode is a case in point. I > guess others have pointed out other cases. Can you explain your views > on the same? > > Here is how ESP is done: > > BEFORE APPLYING ESP > --------------------------------------- > IPv6 | | ext hdrs | | | > | orig IP hdr |if present| TCP | Data | > --------------------------------------- > > AFTER APPLYING ESP > --------------------------------------------------------- > IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| > |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| > --------------------------------------------------------- > |<--- encryption ---->| > |<------ integrity ------>| > > >>> The first thing is IPv6 MTU discovery is optional and the only >>> requirement is that the Minimum MTU is satisfied. >> >> Yes, but 1280 plus a routing header will exceed 1280. >> Thus the minimum MTU by itself doesn't save you. > One thing to consider is 802.15.4 has an MTU of only 127 octets. There > is a fragmentation and reassembly layer below the IP layer to satisfy > the MTU at each IP hop (just read RFC 4944). Once that is present in > my view it is not a problem to reassemble a larger packet. 802.15.4 > experts would however be better suited to answer the question. > >>> Also in cases like LLN the Routing paths may change so even after >>> discovery the Packet too big may come anyway. Besides PMTU issues you >>> mention are no different than a lot of cases such as tunnelling and >>> transition mechanisms. >> There is a very big difference. >> Tunneling means that the entity which added the tunneling headers is >> in the source IP address field in the outer header. Thus ICMP errors >> will be sent packet to the tunnel entry point. It can then compensate >> for the added headers by sending an ICMP packet too big with a >> smaller MTU back to the original source. This how IPvx in IPvy >> tunneling is done. See for instance RFC 4213 and RFC 2473. > You seem to take things literally. Can you explain the behavior in the > case of IPsec transport mode where no new IP header is added and how > it is different? > >> The big difference is that when a router does something to grow the size of >> the packet (for instance, inserting a routing header) and it does not add an >> outer IP header with its source address, then the ICMP errors will go back >> to the original sender without being adjusted for the added header. > > Thanks, > Vishwas > > >>> Thanks, >>> Vishwas >>> >>> On Sun, May 30, 2010 at 7:56 AM, Erik Nordmark<erik.nordm...@oracle.com> >>> wrote: >>>> >>>> The draft says: >>>> A RPL Router MAY insert a Type 4 Routing header if one does not >>>> already exist. The conditions for inserting a Type 4 Routing header >>>> are out of scope of this document. >>>> >>>> Having routers insert headers in packets they forward is know to be >>>> problematic in general, since it breaks path MTU discovery. >>>> Taking an example of a host which sends a packet which is 1500 bytes, and >>>> then receives an ICMP packet too big error saying "please limit packets >>>> to >>>> 1500 bytes", will not change the host's behavior. But that can happen if >>>> some router grows the packet to be more than 1500 bytes. >>>> >>>> Thus in general, the only safe way to insert headers in a packet is to >>>> have >>>> the "inserter" put an extra IP header, with itself as a source, then the >>>> inserted header, and then the original packet. >>>> That extra IP header ensures that any ICMP error go back to the >>>> "inserter", >>>> which can then compensate for its insertion before sending the ICMP error >>>> towards the sender of the original packet. >>>> >>>> Thus I think there is a question for 6man whether we think the >>>> constrained >>>> environment of ROLL is such that we can relax this. But it does require >>>> that >>>> all the routers at the edge of the ROLL network adjust the ICMP errors >>>> they >>>> forward to compensate for any inserted RH4 headers. >>>> >>>> Erik >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
