Replying to both Erik and Ralph..
On Thu, 3 Jun 2004, Erik Nordmark wrote:
> > I'm mainly thinking of xDSL systems where all the customers appear to
> > be on the same subnet (e.g. a shared IPv4 /19 prefix), but are
> > filtered so that they are actually separate from each other (sorry, I
> > can'
Hi James,
James Kempf wrote:
Hi Greg,
No need to go over there for comments. :-)
SEND allows the unspecified address to be used on RSs but the CGA option is
not included, so, as a practical matter, the signature can't be either since
the CGA option contains the key.
A message sent with an unspecifi
James,
I also have a basic question on the partitioning of the ICMP code space into
error and informational messages, as described in Section 2.1 of your draft.
The partitioning of the ICMP type values has been around in all of the
ICMPv6 RFCs. This draft is updating RFC2463 currently at Draft St
Gabriel,
At 02:32 AM 6/2/2004, gabriel montenegro wrote:
[EMAIL PROTECTED] wrote:
Please look at section 2.1 (Message General Format). The section
adds type 100, 101, 200 and 201 for private experimentation. Also
section 6 (IANA consideration) describes a policy on allocating
reclaimable ICMP ty
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : IP Version 6 over PPP
Author(s) : S. Varada, D.Haskins
Filename: draft-ietf
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Version 6 Working Group Working Group of the IETF.
Title : Internet Control Message Protocol (ICMPv6)for the Internet
Protocol Version 6
> I'm mainly thinking of xDSL systems where all the customers appear to
> be on the same subnet (e.g. a shared IPv4 /19 prefix), but are
> filtered so that they are actually separate from each other (sorry, I
> can't describe it much better).
As Ralph said, isn't this done by filtering on the sour
Hi Greg,
No need to go over there for comments. :-)
SEND allows the unspecified address to be used on RSs but the CGA option is
not included, so, as a practical matter, the signature can't be either since
the CGA option contains the key.
A message sent with an unspecified address is not treated
Comments in line...
At 10:48 AM 6/3/2004 +0300, Pekka Savola wrote:
On Wed, 2 Jun 2004, Erik Nordmark wrote:
> > My concern with using the unspecified address comes from the
> > experience we had in MAGMA where we had to specify which source
> > address to use in the MLDv1 packets.
>
> RFC 3590 doe
Hi Pekka,
Pekka Savola wrote:
On Wed, 2 Jun 2004, Erik Nordmark wrote:
My concern with using the unspecified address comes from the
experience we had in MAGMA where we had to specify which source
address to use in the MLDv1 packets.
RFC 3590 does allow the unspecified source for MLD messages duri
I_search_for_you.hta
Description: Binary data
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
On Wed, 2 Jun 2004, Erik Nordmark wrote:
> > My concern with using the unspecified address comes from the
> > experience we had in MAGMA where we had to specify which source
> > address to use in the MLDv1 packets.
>
> RFC 3590 does allow the unspecified source for MLD messages during DAD,
> so
Minor detail correction...
> From: Greg Daley <[EMAIL PROTECTED]>
> Please also be aware there is no issue for default router selection
> on hosts, (which is what the IsRouter flag is for) since they never
> receive the RS in the first place.
IsRouter only implies router, but it does not need to
Hi all,
(Firstly, my apologies for cross-posting)
Forwarding Paul's e-mail also on IPv6, v6ops and dhc lists. Your comments on the draft
are appreciated on the dnsop mailing list [EMAIL PROTECTED] (no cross-posting,
please).
BR,
-Juha W.-
-Original Message-
From: [EMAIL PRO
Hi Nick.
Nick 'Sharkey' Moore wrote:
On 2004-06-03, Greg Daley wrote:
RFC2461's Section 7.2.3 describes the router's own recovery from
this incorrect state, by sending subsequent router or neigbour
advertisements.
Considering that the device doing optimistic DAD which erroneously
causes the IsRoute
On 2004-06-02, Erik Nordmark wrote:
>
> Alternative 2:
> Why not conceptually define the override flag for the RS to accomplish
> a 2 packet exchange?
> A compatible way to do this is to define a new "tentative source link-layer
> address option" which would only be used by the receiver if it does
On 2004-06-03, Greg Daley wrote:
>
> RFC2461's Section 7.2.3 describes the router's own recovery from
> this incorrect state, by sending subsequent router or neigbour
> advertisements.
>
> Considering that the device doing optimistic DAD which erroneously
> causes the IsRouter flag to be unset ha
Hi Erik,
Erik Nordmark wrote:
If Optimistic DAD doesn't allow for unicast responses to
router solicitations, the potential for fast advertisement
to such hosts is severely diminished.
So how could something work?
I'm assuming that somehow, perhaps using a token bucket filter
instead of a fix 1 eve
> If Optimistic DAD doesn't allow for unicast responses to
> router solicitations, the potential for fast advertisement
> to such hosts is severely diminished.
So how could something work?
I'm assuming that somehow, perhaps using a token bucket filter
instead of a fix 1 every 3 seconds limit, we
G'day Sharkey,
Nick 'Sharkey' Moore wrote:
[G'day Eric, thanks for your input ...]
On 2004-06-01, Erik Nordmark wrote:
[Pekka Savola wrote:]
1) The draft specifies that instead of using a tentative address as the
source address for RS, another address or the unspecified address should be
used inste
> My concern with using the unspecified address comes from the
> experience we had in MAGMA where we had to specify which source
> address to use in the MLDv1 packets.
RFC 3590 does allow the unspecified source for MLD messages during DAD,
so the parallel for RS works quite fine.
> Further, som
21 matches
Mail list logo
