Fernando Gont wrote:
Folks,
RFC 2460 states that every link in an internet have an MTU of 1280
octets or greater, and that any link that cannot convey a 1280-octet
packet in one piece must provide fragmentation and reassembly at a layer
bellow IPv6.
However, while talking about the specs wi
Thomas,
2nd ping. If you could please reply, that'd be great. I don't think the
ship will return back to port to discuss anything related to on-link
definition bullets three and four in our draft - that ship has sailed.
So now that we have agreed to removing the line mentioned in the email
chain b
Folks,
RFC 2460 states that every link in an internet have an MTU of 1280
octets or greater, and that any link that cannot convey a 1280-octet
packet in one piece must provide fragmentation and reassembly at a
layer bellow IPv6.
However, while talking about the specs with a few folks (who
p
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 I experience the type of outage
described in our draft.
Furthermore, I occasionally go
Jinmei,
Thanks for the comment.
For this comment from you:
"Aside from this essential point, the new bullet does also not make
sense in the context of 'A correctly implemented IPv6 host MUST adhere
to the following rules'. If we find any valid 'justification' like
this, it should be described
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 normative requirements but clearly says why it is
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : IPv6 Subnet Model: the Relationship between Links and
Subnet Prefixes
Author(s) : H. Singh, et al.
http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-01
.txt
Hemant, Wes, and Erik.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
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 of the
on-link definition are being debated and may need further
clarification."
Further, since Tatuya will not let us add any text that suggests new
rules
We're against blind caching and re-use of unverified (and possibly
bogus) information. If that information is deprecated and later
verified (as it is in DNA) - then the information can be re-used without
a problem.
Tatuya -
In the new text, we have eliminated any normative language. Therefore,
Tatuya,
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 normative requirements but clearly says why it is a bad idea to
cache on-link determination. Also, our draft is about on-link
determina
Hi Thomas,
Thomas Narten wrote:
Note also, that DNA approaches essentially "cache" information about
the configuration of an interface across interfaces going up and down
-- which is very similar to the type of caching you are proposing to
disallow.
Ack. This is exactly what simple dna does.
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
Thomas,
You say: " bullets 3 & 4 MUST NOT be taken to indicate an address is
on-link."
But the Terminology section and the on-link definition clearly say
either of bullets 3 and 4 signify that the address is on-link. I have
snipped the text of the definition below.
on-link - an address that
"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
15 matches
Mail list logo
