At Tue, 27 Oct 2009 06:24:47 -0400,
Brian Haberman br...@innovationslab.net wrote:
Title : IPv6 Subnet Model: the Relationship between
Links and Subnet Prefixes
Author(s) : H. Singh, et al.
Filename : draft-ietf-6man-ipv6-subnet-model-05.txt
[mailto:ipv6-boun...@ietf.org] On Behalf Of JINMEI
Tatuya /
Sent: Sunday, November 08, 2009 7:33 PM
To: Brian Haberman
Cc: Bob Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Tue, 27 Oct 2009 06:24:47 -0400,
Brian Haberman br...@innovationslab.net wrote
(resending as I seem to have submitted the original one from the wrong
address)
At Tue, 27 Oct 2009 06:24:47 -0400,
Brian Haberman br...@innovationslab.net wrote:
Title : IPv6 Subnet Model: the Relationship between
Links and Subnet Prefixes
Author(s) : H.
Supported.
Thanks!
Two comments, however.
1. An Updates: 4861 header is required
Agreed!
2. Why does it contain the pre-5378 disclaimer (This document may
contain material...)?
If the only issue is that material conributed by Thomas Narten is
included, Thomas could give
us the OK to
Supported.
Two comments, however.
1. An Updates: 4861 header is required
2. Why does it contain the pre-5378 disclaimer
(This document may contain material...)?
If the only issue is that material conributed by Thomas Narten
is included, Thomas could give us the OK to use standard
boilerplate
All,
This message starts a 2-week 6MAN Working Group Last Call on
advancing:
Title : IPv6 Subnet Model: the Relationship between
Links and Subnet Prefixes
Author(s) : H. Singh, et al.
Filename : draft-ietf-6man-ipv6-subnet-model-05.txt
Pages :
The Last Call will end on November 14th, not October 14th.
Regards,
Brian
Brian Haberman wrote:
All,
This message starts a 2-week 6MAN Working Group Last Call on
advancing:
Title : IPv6 Subnet Model: the Relationship between
Links and Subnet Prefixes
Of Wes Beebee
(wbeebee)
Sent: Friday, July 25, 2008 6:45 AM
To: Hemant Singh (shemant); [EMAIL PROTECTED]
Cc: Thomas Narten; ipv6@ietf.org; Brian Haberman; Bob Hinden; Suresh Krishnan
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Sounds good to me... We mainly want to say
: RE: 6MAN WG Last
Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Tatuya,
Thanks for all your email. Please see in line between hs and /hs.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 9:44 PM
To: Wes Beebee (wbeebee)
Cc
.]
Hemant
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, July 17, 2008 10:28 PM
To: Erik Nordmark
Cc: Thomas Narten; Bob Hinden; ipv6@ietf.org; Brian Haberman
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Thu, 10 Jul 2008 16:21:35 -0400,
Wes Beebee (wbeebee) [EMAIL PROTECTED] wrote:
The problem is that one problem is FAR more likely to happen than the
other.
I shutdown my machine every night
To: [EMAIL PROTECTED]
Cc: Thomas Narten; ipv6@ietf.org; Suresh Krishnan; Bob Hinden; Brian
Haberman
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Jinmei,
Thanks for the comment.
For this comment from you:
Aside from this essential point, the new bullet does also not make
sense
At Thu, 10 Jul 2008 16:21:35 -0400,
Wes Beebee (wbeebee) [EMAIL PROTECTED] wrote:
The problem is that one problem is FAR more likely to happen than the other.
I shutdown my machine every night and power it on again in the
morning when I come to work. Therefore, every night of every
workday
At Thu, 17 Jul 2008 14:06:11 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Another ping on this one.
Sorry for the long delay. I just sent to a reply to the response from
Wes. I believe it also covers your point.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
At Mon, 14 Jul 2008 03:22:44 -0700,
Erik Nordmark [EMAIL PROTECTED] wrote:
BSD variants have in fact supported this behavior for years: I've just
tested this with a FreeBSD 7.0 box and confirmed it (that is, if that
host receives an NS from an address that is not covered by on-link
At Mon, 14 Jul 2008 03:30:50 -0700,
Erik Nordmark [EMAIL PROTECTED] wrote:
there are currently two places where we treat autoconfigured addresses
differently than on-link prefixes.
One is the text about storing the address and associated lifetime in RFC
4862 that we are debating here.
The
) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 2 July 2008 12:44 AM
To: MILES DAVID; Wes Beebee (wbeebee); ipv6@ietf.org
Cc: Thomas Narten; [EMAIL PROTECTED]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
David,
Please see in line below between hs and /hs.
-Original
JINMEI Tatuya / 神明達哉 wrote:
First off, I believe we should be more careful before deprecating
this rule:
- any Neighbor Discovery message is received from
the address.
As an implementor, I've been aware of the non-trivial flavor of this
on-link
Thomas Narten wrote:
It is clear to me that bullet four in RFC 4861:
on-link - an address that is assigned to an interface on a
specified link. A node considers an address to be on-
link if:
- it is covered by one of the link's
JINMEI Tatuya / 神明達哉 wrote:
Anyway, I'm not convinced with this logic. As I pointed out, killing
on-link information caching effectively kills address caching, too, by
making the cached address of almost no use. Again, I'm personally not
a fan of this caching trick, but effectively killing
Thomas Narten wrote:
When NodeA issues a NS for NodeB, that usually means that NodeA has
traffic to send to NodeB, and NodeB will shortly thereafter send a
response packet back to/through NodeA. In IPv4, that requires both
sides issue ARPs independently. I.e., NodeA has to ARP for NodeB, and
Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Wes,
There are implementations that update their routing table on the receipt
of a Neighbour Advertisement which we should consider. One example is
the code developed in the KAME project, which can be found in many
BSD-based distros. On receipt of a valid NS
Wes,
There are implementations that update their routing table on the receipt
of a Neighbour Advertisement which we should consider. One example is
the code developed in the KAME project, which can be found in many
BSD-based distros. On receipt of a valid NS, the neighbour cache is
updated with a
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Hemant Singh (shemant)
Sent: Thursday, July 10, 2008 5:12 PM
To: Hemant Singh (shemant); Thomas Narten
Cc: ipv6@ietf.org; Brian Haberman; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thomas,
2nd ping. If you could
Hemant Singh (shemant) [EMAIL PROTECTED] writes:
Tatuya,
Erik suggested some new text to us related to bullets 3 and 4 of on-link
definition in the Terminology section of RFC4861. He is busy this week -
we are sending this on his behalf. As you know bullet 4 is being debated
in 6man. Erik
-
From: Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 10, 2008 9:52 AM
To: Hemant Singh (shemant)
Cc: [EMAIL PROTECTED]; Bob Hinden; Brian Haberman; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Hemant Singh (shemant) [EMAIL PROTECTED] writes
Hi Tatuya,
JINMEI Tatuya / wrote:
At Wed, 9 Jul 2008 20:54:04 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Thanks for the reply. Let's see if we can meet common ground with you.
Our justification for prohibiting on-link caching is only in emails to
6man as follows:
What if
PROTECTED]
Sent: Thursday, July 10, 2008 1:15 AM
To: Hemant Singh (shemant)
Cc: Wes Beebee (wbeebee); Thomas Narten; Brian Haberman; Bob Hinden;
ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Wed, 9 Jul 2008 20:54:04 -0400,
Hemant Singh (shemant) [EMAIL
PROTECTED]; Bob Hinden; Brian Haberman; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Hemant Singh (shemant) [EMAIL PROTECTED] writes:
Tatuya,
Erik suggested some new text to us related to bullets 3 and 4 of
on-link definition in the Terminology section
WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Thu, 10 Jul 2008 12:09:01 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Since you don't want any new rules added by our draft, we changed
bullet
3 related to caching on-link determination. The new bullet text does
not add any
Narten; Brian Haberman; Bob
Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Thu, 10 Jul 2008 12:09:01 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Since you don't want any new rules added by our draft, we changed
bullet
3 related
10, 2008 2:28 PM
To: Thomas Narten
Cc: Brian Haberman; Bob Hinden; ipv6@ietf.org
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Thomas,
Are you ok with the new paragraph if we removed this sentence from it:
As of the writing of this document, bullets three and four
WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Thu, 3 Jul 2008 17:07:34 -0400,
Wes Beebee (wbeebee) [EMAIL PROTECTED] wrote:
3. On-link determination SHOULD NOT persist across IPv6 interface
initializations. Note that section 5.7 of [RFC4862] describes
the use
PROTECTED] On Behalf Of Hemant Singh
(shemant)
Sent: Monday, June 30, 2008 10:37 AM
To: MILES DAVID; Wes Beebee (wbeebee); Wojciech Dec (wdec); Brian Haberman;
ipv6@ietf.org
Cc: Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
David,
We will explain where we think
, July 08, 2008 10:32 PM
To: Hemant Singh (shemant)
Cc: Thomas Narten; ipv6@ietf.org; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Thu, 3 Jul 2008 17:35:56 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Will something like this work
PM
To: Hemant Singh (shemant)
Cc: Thomas Narten; ipv6@ietf.org; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Thu, 3 Jul 2008 17:35:56 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Will something like this work for you - we have
At Wed, 9 Jul 2008 10:18:11 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Maybe you have not read all the emails in 6man or v6ops related to
the src-address of ND messages rule.
At the risk of saying this with missing something, I've read all of
the related 6man and v6ops threads
At Wed, 9 Jul 2008 10:08:02 -0400,
Wes Beebee (wbeebee) [EMAIL PROTECTED] wrote:
wb
What if there are cache-inconsistency problems, prefix renumbering, or
stale information? I think it's better just to get rid of caching
on-link information in stable storage and get such information
:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 8:35 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Wed, 9 Jul 2008 10:08:02 -0400,
Wes Beebee (wbeebee) [EMAIL
PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 8:35 PM
To: Wes Beebee (wbeebee)
Cc: Hemant Singh (shemant); Thomas Narten; Brian Haberman; Bob Hinden;
ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
At Wed, 9 Jul 2008 10:08:02 -0400,
Wes Beebee
Note: replying to a number of separate messages here...
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
[EMAIL PROTECTED] writes:
At Thu, 3 Jul 2008 17:07:34 -0400,
Wes Beebee (wbeebee) [EMAIL PROTECTED] wrote:
wb
What if there are cache-inconsistency problems, prefix renumbering,
Jinmei,
Thanks for teasing this discussion apart further. You've tweaked an
old memory to the surface. :-)
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
[EMAIL PROTECTED] writes:
First off, I believe we should be more careful before deprecating
this rule:
- any
Singh (shemant); Brian Haberman; Bob
Hinden; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Note: replying to a number of separate messages here...
JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
[EMAIL PROTECTED] writes:
At Thu, 3 Jul 2008 17:07
Message-
From: Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 09, 2008 9:43 PM
To: JINMEI Tatuya /
Cc: Hemant Singh (shemant); ipv6@ietf.org; Brian Haberman; Bob Hinden
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Jinmei,
Thanks for teasing
At Wed, 9 Jul 2008 20:54:04 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Thanks for the reply. Let's see if we can meet common ground with you.
Our justification for prohibiting on-link caching is only in emails to
6man as follows:
What if there are cache-inconsistency
At Wed, 9 Jul 2008 12:21:06 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Erik suggested some new text to us related to bullets 3 and 4 of on-link
definition in the Terminology section of RFC4861. He is busy this week -
we are sending this on his behalf. As you know bullet 4 is being
At Thu, 3 Jul 2008 17:07:34 -0400,
Wes Beebee (wbeebee) [EMAIL PROTECTED] wrote:
3. On-link determination SHOULD NOT persist across IPv6 interface
initializations. Note that section 5.7 of [RFC4862] describes
the use of stable storage for addresses acquired with stateless
At Thu, 3 Jul 2008 17:35:56 -0400,
Hemant Singh (shemant) [EMAIL PROTECTED] wrote:
Will something like this work for you - we have replaced change with
clarification.
[The source of an ND message is no longer used for on-link
determination, which is a clarification of bullet four of on-link
: Hemant Singh (shemant); Wes Beebee (wbeebee); ipv6@ietf.org;
[EMAIL PROTECTED]
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
MILES DAVID [EMAIL PROTECTED] writes:
Hemant,
Thanks for your patience.
Given we are now very clear that a receiver should drop any ND message
My. $.02.
Close to ready to ship.
Substantive:
In addition to the Prefix List, individual addresses are on-link if
they are the target of a Redirect Message indicating on-link, or the
source of a valid Neighbor Solicitation or Neighbor Advertisement
message.
Per list
: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
My. $.02.
Close to ready to ship.
Substantive:
In addition to the Prefix List, individual addresses are on-link if
they are the target of a Redirect Message indicating on-link, or
the
source of a valid Neighbor Solicitation
: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
My. $.02.
Close to ready to ship.
Substantive:
In addition to the Prefix List, individual addresses are on-link if
they are the target of a Redirect Message indicating on-link, or
the
source of a valid Neighbor Solicitation
; ipv6@ietf.org
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
My. $.02.
Close to ready to ship.
Substantive:
In addition to the Prefix List, individual addresses are on-link if
they are the target of a Redirect Message indicating on-link, or
the
source
Sorry, I forgot one item that Wes just reminded me of. Earlier in the
day I had emailed out our new text for bullet 2 that has this new line:
The source of an ND message is no longer used for on-link
determination, which is a change from [RFC4861].
I object, because I do not believe 4861
Subject: Re: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Sorry, I forgot one item that Wes just reminded me of. Earlier in the
day I had emailed out our new text for bullet 2 that has this new
line:
The source of an ND message is no longer used for on-link
determination, which
: Hemant Singh (shemant) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 2 July 2008 12:44 AM
To: MILES DAVID; Wes Beebee (wbeebee); ipv6@ietf.org
Cc: Thomas Narten; [EMAIL PROTECTED]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
David,
Please see in line below between hs
: Wednesday, July 02, 2008 8:23 PM
To: Hemant Singh (shemant); Wes Beebee (wbeebee); ipv6@ietf.org
Cc: Thomas Narten; [EMAIL PROTECTED]
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Hemant,
Thanks for your patience.
Given we are now very clear that a receiver should drop any
); Brian
Haberman; ipv6@ietf.org
Cc: Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
David,
We will explain where we think RFC4861 came from with the 4th bullet in
on-link definition in Terminology section of RFC4861. We will explain
why that bullet is needed
Haberman;
ipv6@ietf.org
Cc: Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Wes Hemant,
Can we walk through the situation of hosts without routers where you
suggest a possible issue?
HostA (link) HostB
HostA:
2002:db8:100::1234/64
2002:db8:200::1234/64
Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
David,
We will explain where we think RFC4861 came from with the 4th bullet in
on-link definition in Terminology section of RFC4861. We will explain
why that bullet is needed and why the bullet does not change. Further,
we
All,
This message starts a 3-week 6MAN Working Group Last Call on
advancing:
Title : IPv6 Subnet Model: the Relationship between
Links and Subnet Prefixes
Author(s) : H. Singh, et al.
Filename : draft-ietf-6man-ipv6-subnet-model-00.txt
Pages :
] [mailto:[EMAIL PROTECTED] On
Behalf Of Brian Haberman
Sent: 26 June 2008 14:17
To: ipv6@ietf.org
Cc: Bob Hinden
Subject: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
All,
This message starts a 3-week 6MAN Working Group Last Call on
advancing:
Title : IPv6
Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Based on a recent thread
(http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00896.html) the
following paragraph from the draft appears to warrant some more thought
if not outright a revision
In addition to the Prefix
@ietf.org
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last
Call:draft-ietf-6man-ipv6-subnet-model-00.txt
Based on a recent thread
(http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg00896.html)
the following paragraph from the draft appears to warrant
some more thought if not outright
To: Wojciech Dec (wdec); Brian Haberman; ipv6@ietf.org
Cc: MILES DAVID; Bob Hinden
Subject: RE: 6MAN WG Last Call:draft-ietf-6man-ipv6-subnet-model-00.txt
This rule derives directly from the Terminology section of RFC 4861
(definition of on-link).
Note that the presence of a bogus entry causes no harm
65 matches
Mail list logo
