Subject: Weekly posting summary for [email-masked]

From: Rob Austein <[email-masked]>
Date: Sun, 02 Oct 2005 00:00:13 -0400

Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 13.89% |    5 | 12.74% |    27341 | [email-masked]
 13.89% |    5 |  9.78% |    20982 | [email-masked]
 11.11% |    4 |  9.46% |    20314 | [email-masked]
 11.11% |    4 |  6.66% |    14293 | [email-masked]
  2.78% |    1 |  9.34% |    20054 | [email-masked]
  2.78% |    1 |  8.47% |    18188 | [email-masked]
  5.56% |    2 |  5.05% |    10847 | [email-masked]
  2.78% |    1 |  4.34% |     9319 | [email-masked]
  2.78% |    1 |  4.10% |     8809 | [email-masked]
  2.78% |    1 |  3.90% |     8363 | [email-masked]
  2.78% |    1 |  3.74% |     8022 | [email-masked]
  2.78% |    1 |  3.49% |     7480 | [email-masked]
  2.78% |    1 |  2.95% |     6326 | [email-masked]
  2.78% |    1 |  2.58% |     5532 | [email-masked]
  2.78% |    1 |  2.31% |     4958 | [email-masked]
  2.78% |    1 |  2.16% |     4629 | [email-masked]
  2.78% |    1 |  2.04% |     4383 | [email-masked]
  2.78% |    1 |  1.90% |     4077 | [email-masked]
  2.78% |    1 |  1.73% |     3711 | [email-masked]
  2.78% |    1 |  1.68% |     3615 | [email-masked]
  2.78% |    1 |  1.58% |     3390 | [email-masked]
--------+------+--------+----------+------------------------
100.00% |   36 |100.00% |   214633 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the IPv6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Suraj <[email-masked]>
Date: Wed, 05 Oct 2005 12:26:01 +0800

Hi All,

RFC 2894 ' Router Renumbering for IPv6'describes the Renumbering of
Prefixes using RR commands to multicast addresses. (Site local OR Link
local).

Since the site local addresses are now deprecated (RFC 3879), we can
assume that RR is now supported only for Link local addresses (unicast
and multicast).

What is the relevance of the 'S'(site specific) flag now in the command
message. Should the 'S' flag be evaluated even if the scope of
destination address is Link local (unicast or multicast)?

Since RFC 2894 says that the 'S' flag should be ignored unless the
router treats interfaces as belonging to different "sites", in this case
should the RR command messages be limited only to the interfaces on that
link OR to all interfaces on the router?

Thanks and Regards,
Suraj.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 05 Oct 2005 08:24:55 +0100

>assume that RR is now supported only for Link local addresses (unicast
No:  The deprecation only affects site-local unicast addresses.  
Site-scope multicast is still available.

>destination address is Link local (unicast or multicast)?
Yes:  The relevance is unchanged.  If a router is at a site border and 
is configured with some interfaces (set A) associated with one site and 
others (set B)  associated with other site(s), then a renumbering 
message arriving on any interface in set A (whatever the destination 
address in the base IPv6 header) with the S flag set will be applied 
exclusively to the interfaces in set A - those in set B will be unaffected.

>link OR to all interfaces on the router?
Again the type of the command message destination address has no effect. 
Combining the words in s1, s3.1 and s4.3, the intention is that any RR 
command with the S flag clear applies to *all* interfaces apart from 
those that might be ruled out because they are currently shut down 
depending on the setting of the A flag - nothing is said about altering 
the processing depending on the type of destination address.

Regards,
Elwyn

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Oct 2005 14:03:34 +0100

Hi Suraj,

May I ask if you are implementing this, or are you looking from a theoretical
perspective?

Tim

-- 
Tim/::1