>>>>> On Mon, 22 Apr 2002 14:44:17 -0700, 
>>>>> Steve Deering <[EMAIL PROTECTED]> said:

>> In my understanding, the only "translating router" that needs the
>> indication of the fragment header is an SIIT (or similar) translation
>> router.  In fact, neither NAT-PT (RFC 2766) nor TCP-relay (RFC 3142)
>> needs the indication.
>> 
>> So my questions are:
>> 
>> - is my understanding correct?

> Perhaps.  That depends on how generous your "(or similar)" qualifier is.
> :-)

Indeed...by the word I primarily meant a translation router that
cannot assign a unique IPv4 ID for a given IPv6 address.  An SIIT
translator cannot do this, because the translated IPv4 (source)
address is derived from the original IPv6 address.  A TCP relay can do
this, because it uses an IPv4 address of its own for the IPv4 side.
As for NAT-PT, I thought it belonged to the latter group, but I may be
wrong.

>> - if so, is it allowed for a host not implementing SIIT client side to
>> ignore the requirement to insert the fragment header upon receiving
>> an ICMPv6 too big message with an MTU less than 1280?

> No, because there may be other things similar to SIIT (either already
> invented or to-be-invented), that require the same originator behavior.

> The spec is clear what to do when you get a Packet Too Big message
> reporting an MTU less than 1280, and I think it would be unwise for
> nodes to employ heuristics to determine whether or not to comply.

I agree with the last sentence ("it would be unwise..."), but please
let me ask a question from a practical point of view, just out of
curiosity:

Is there an existing translation router (other than an SIIT
translator) that may return an ICMPv6 too big message with an MTU less
than 1280?

Is there an implementation that does not support the SIIT client
function but is compliant to the exceptional case of RFC 1981?

Thanks,

                                        JINMEI, Tatuya
                                        Communication Platform Lab.
                                        Corporate R&D Center, Toshiba Corp.
                                        [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to