[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

6to4 MRU - still need WG consensus



Tony,

People refuse to stay on a single topic however many times I twiddle
the subject field, but yes the issue is in fact the 6to4 MRU. 

I think your formulation is the best yet.

   Brian

(conversation switched to v6ops list)

Tony Hain wrote:
> 
> itojun wrote:
> > >How about this as a compromise:
> > >All nodes SHOULD configure a 6to4 MRU at least as large as their
> > >interface MTU, but that value MUST NOT be smaller than 1480.=20
> > >
> > >This would allow for the future case where both ends were GigE, but
> > >would also allow for IPv6 PMTU discovery to figure out that
> > one end was
> > >limited to < 1500.
> >
> >       we are talking about 6to4, correct?  if so, even if you
> > have GigE and
> >       I have GigE, you are not sure where 6to4 packet will
> > travel to.  it can
> >       go to anywhere (based on value on 3rd to 6th octet in ip6_dst).
> >       this is why i have been proposing to have fixed MTU
> > value for 6to4
> >       interface.
> 
> Yes the packet might go through a router without a 100bT interface, so
> the router upstream from it would have to fragment. As long as the
> receiving 6to4 router is able to reassemble the fragments, there is no
> problem.
> 
> Are we talking about MTU or MRU??? There is no need for a fixed IPv6 MTU
> since that is already defined as something between 1280 and the physical
> link. Also there is no need for a defined IPv4 MTU since that is
> something between 68 and the physical link. What I thought the point of
> the thread was about is finding a minimum IPv4 MRU that would support
> reassembly of IPv4 fragments into IPv6 packets. If any specific receiver
> can't support an IPv4 MRU larger than 1280, the IPv6 PMTU discovery will
> fail until it gets down to an acceptable value. The only real
> interoperability problem will be when the IPv4 MRU is less than 1280.
> Everything else is simply an optimization.
> 
> We shouldn't need to specify that a node should implement an MRU that is
> at least as large as the physical interface MTU, but if that is
> confusing then I don't think it hurts. I also don't believe we need to
> specify that a 6to4 MRU needs to be at least 1280 since that is already
> specified, but if there were problems getting that to work between
> implementations, then again it doesn't hurt to pick a value. If we are
> going to do that we should pick one that is large enough to accommodate
> the common option headers.
> 
> I personally don't see why anything smaller than 4k for an MRU makes any
> sense, but I also don't see that there is anything here worth arguing
> over. If all nodes can receive as much as they can transmit, with a
> minimum greater than 1280, then the overall system will self correct. I
> don't see why a fixed value is needed.
> 
> Tony

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland