Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO

Hi Hesham,all IMHO, its good to have text reflecting chritian's concerns. I does make sense to have the clarifications in place across the sections 6.2.6, 7.2.3, 7.2.4. Regards Radhakrishnan - Original Message - From: Soliman, Hesham [EMAIL PROTECTED] To: [EMAIL PROTECTED]; JINMEI

Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt

Hi Erik, I agree with Jinmei's rephrasing. Both in RFC 2461 and 2461bis the wordings were sounding little bit confused. I would request the changing of 2461bis wording as suggested by Jinmei. Regards Radhakrishnan - Original Message - From: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H (B

Re: IPv6 Address Architecture update question

I too agree with Jim's view. Leaving mapped addresses as it is the best way to go about. changing APIs usage at this stage when they are already deployed is quite difficult. - Original Message - From: Bound, Jim [EMAIL PROTECTED] To: Bob Hinden [EMAIL PROTECTED]; IPv6 WG ipv6@ietf.org

MLDv2 router support in Linux

Hi all, Does anyone have any information about MLDv2 Router support implementation for Linux? regards Radhakrishnan IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests:

IPv4-in-IPv6 protocol value

Hi all, If an IPv4 packet is to be carried over an IPv6 packet then the next header field value should be set to 4 (same as IP-in-IP) RFC 1700 uses the term IP-in-IP which means IPv4-in-IPv4. RFC 2473 makes no mention about the value to be used, though in all fairness its value 4.

Re: further clarifications on M/O flags in rfc2462bis

Hi Jinmei, I am in agreement with your proposed changes. Regards Radhakrishnan - Original Message - From: JINMEI Tatuya / [EMAIL PROTECTED]@C#:H (B [EMAIL PROTECTED]) To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 04, 2004 6:13 AM Subject: Re: further clarifications

Re: mech-v2-05pre

Hi pekka, I need some clarification on this: 3.2. Tunnel MTU and Fragmentation Naively the encapsulator could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes extra are needed for the encapsulating IPv4 header -- Why

Re: ICMPv6: Rate Limiting Configuration Per-Node or Per-Interfaces

Choice is : 1) MAY - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, August 19, 2004 1:21 AM Subject: ICMPv6: Rate Limiting Configuration Per-Node or Per-Interfaces I think the discussion about the ICMPv6 rate limiting is going in all directions and we