is the largest scope that is automatically
> configured, i.e., automatically derived from physical
> connectivity or other, non-multicast-related configuration.
--
JINMEI, Tatuya
Infoblox Inc.
IETF IPv6 working group m
itself is generic while the MPL
case seems too specific. And, as long as the 6man-multicast-scopes
document shows a specific example (so the definition won't be too
vague) and states future cases should be defined in separate RFCs (as
it does in the first sentence of Secti
nition it can
be used for any other usage as long as it meets other architectural
constraints".
But I wouldn't strongly argue for that. It's just a suggestion.
--
JINMEI, Tatuya
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
this particular
relationship, but since the Network-Specific scope (seems) dynamic
and self defined while Admin/Site/Organization-Local scopes are
always defined manually, I guess it'll be more likely to cause
accidental vi
gt; unintentionally created a link-local anycast address, whether it's
> MAC collision or otherwise. Surely there is no way forward?
See above. Surely there's no way of using that link-local address any
more (I believe RFC 4862 is very clear about that). But there can be
other reasonable
the sense of the RFC.
So, unless that (updating RFC 4862 in addition 4291) is the point of
this paragraph(s), my first suggestion is simply remove it.
If the intent is to update RFC 4862, I think the draft needs to
explicitly say so. And, at least the description should be clearer
(at least to me it w
ved from the RFC4862 text as an
out-of-scope item for that particular RFC (and the assumption was they
should be standardized in other documents).
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing
logic by configuring
* a sysctl variable, so that privacy conscious users can
* always prefer temporary addresses.
*/
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 w
rm,
such as an network interface name that can uniquely identify the
corresponding zone in the context of %.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
9a5c%en0 if=en0, flags=, pref=medium, expire=23m7s
(note the "pref" field)
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
"If the incoming interface is equal...")
As commented, we wanted to separate an inevitable loop with a valid
configuration from loops due to
configuration/operational/implementation errors (most typically a
temporary routing loop). We'd rather catch the latter type of error
easily
ally) adopting this draft as a wg document. But it may
be better to begin with a clear problem statement without including
any specific solution. And, as a result of that, the appropriate wg
may be an O&M one (most likely v6ops in that case) rather than this
wg.
---
JINMEI, Tatuya
Internet Systems C
hough I've heard there used to be an implementation
that tries neighbor discovery on all possible links when the outgoing
link is ambiguous from the destination address.
I'd also like to note that RFC4007 suggests the implementation have
the notion of "default sc
. Remember, DAD is
not a 100% reliable protocol, and in some cases it can result in a
suboptimal state. But in this specific case, the result is not as bad
as the case where two or more nodes keep using a duplicate address
(e.g., due to DAD NSes being dropped); at least one of the conflictin
ven
> see system configuration parameters (e.g. in init scripts) which would
> change this.
I won't try to win the debate of the definition of implementation.
It was not my point that the KAME/BSD may implement it. The point is
that the or
raft, which is available at
> http://www.ietf.org/id/draft-ietf-6man-ipv6-subnet-model-05.txt
Ah, my bad...I referred to a very old version (00) of the document
by simply retrieving it from the subject line of the last call.
So, please just forget my comments (and support) completely. Sorry
for the co
quot;
Although I can understand what this means, "addresses as longer
than 32 bits" sounds awkward to me (because an IPv6 address is
always "128 bits" in length). I'd suggest rephrasing this, e.g.,
as follows:
"By nature
IPv6 addresses are
if their destination address matches a subnet that belongs to
the link itself.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
tter
router to reach an address, in which case the address is normally
off-link.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
entence as follows:
Note that Redirect Messages can also designate an alternate better
router to reach an address, in which case the address is normally
off-link.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv
g.) as follows:
1) A rule described in ICMPv6 [RFC4443] indicates [...]
if their destination address matches a subnet that belongs to
the link itself.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF I
ing the current restriction.
The lack of IP layer checksum and its implication are one reason for
that.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
or vote to move forward.
p.s. I'll be mostly offline until May 20 for vacation (officially I'm
already off). I'm sorry for not being able to be so responsive. I
hope we can make progress without me (hopefully toward the way I
wish:-).
---
JINMEI, Tatuya
Internet Systems Consort
ditorial suggestions can be sent to the document editor. This last
> call will end on May 18, 2009.
I've sent my comments on the draft to the list. In short, I don't
think it's ready for publication yet.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
-
ress
from the L2 header and uses it to send the NA? And if so, are you
arguing that the responding node in question must behave that way to
keep this rule?
: A host only performs address resolution for IPv6 addresses that are
: on-link.
---
JINMEI, Tatuya
Internet Systems Consortium,
layer address of Y is available to X when X
receives the unicast NUD message." Why is this ensured? For example,
X may have just been rebooted and its neighbor cache may be empty.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--
P::Y.
But since X doesn't know the link-layer address of P::Y, it first
needs to perform address resolution. On the other hand, according
to the revised "on-link" definition, P::Y is not considered
"on-link" (for X).
---
JINMEI, Tatuya
Internet Systems Consortiu
bullet 6 here.
> - Section 3, bullet 7: this rule isn't enforceable. I thought I
> already pointed it out before (please google it).
I meant Section 2, bullet 7 here.
> - Section 4, last para:
I meant Section 3 here.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
and (ND, RA, etc)
- there are some redundant white spaces, e.g. "on- link" (should be
on-link)
- Section 3, bullet 4, there seems to be an indentation problem:
Similarly, the following text from section 6.2.5 of [RFC4861]
I suspect it's not part of citation.
---
JINMEI,
some walled-garden,
non-IETF protocol (except that HbH options are relatively scarce
resource - but it doesn't matter much anyway, because we wouldn't
expect so many options to be defined). However, I want that option to
conform to the standard
I'm not sure if we're on the same page. I've never
suggested the use of /48 with L=1 in this usage example. The context
I mentioned this tricky setting is as follows:
At Wed, 18 Feb 2009 12:30:31 -0800,
JINMEI Tatuya wrote:
> > Why should I put a /64 in the RA when that lin
> on link.
In this case A (or B) normally only advertises 2001:db8:::/64 with
L=1 and A=1, and everything works just fine. The example I gave was
to show that one of your suggested justification for the "hypothetical
extension" doesn't work in some cases.
---
JINMEI, Tatuya
ow can host Y send a packet destined to
2001:db8::cc00::2 via router B, instead of directly trying
neighbor discovery (which will fail)? Since Y is told
2001:db8:::/48 (which covers 2001:db8::cc00::2) as an on-link
prefix, the destination address should be a neighbor of Y.
---
JINMEI, Tat
you have a real world problem that can only be solved by such a new
rule, please go ahead writing a draft with detailing the problem and
explaining why the new rule is inevitable. I don't think continuing
the hypothetical argument here will lead us to anywhere constructive.
---
JINMEI, Ta
configuring an address with the prefix and the IID,
filling in the remaining bits with 0". My whole point is that it's
not worth the time and process overhead to consider introducing such
an additional extension at this stage without a strong reason, and 'we
could do it, why not
autoconfiguration, you can do it without changing the
standard by advertising:
- prefix P::/56 with L=1, A=0, and
- prefix P::/64 with L=0, A=1
if the receiving host is fully compliant with RFC4861 and 4862.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
-
h the same length
of IID, that's fine. But my question would then be: what's the
implementation that uses a shorter prefix? For what does it use the
remaining space between the prefix and the IID?
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
face
identifier), and for what does it use the larger IFID space?
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
that
sense it rather diligently follows the model that Suresh explained.
It adopts the "shortcut" behavior as a compromise for existing
operators who are very familiar with IPv4 operations and would expect
the same side effect.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
-
'd rather
avoid the situation where configuration fails simply because the M/O
bits are off)
- 802.11 airtime issue is not convincing enough, at least without
concrete numbers to prove its severity, to discourage such tendency
of implementors.
---
JINMEI, Tatuya
Internet Systems Consortium
server (as
a node) is configured with that information, so it's just a matter of
which function is implemented in that node.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
's wrong with 'invalidate', but I don't insist on a
specific wording. I'm fine as long as the new document clearly warns
that a RFC4861-compliant implementation may need to be modified due to
that document.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
is is probably a compromise after a political war, however, so I
won't object to that conclusion.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
y message is received from the address.
the conceptual sending algorithm doesn't mention bullets 3 or 4 at
all.
If the original intent of the spec authors was to ignore these
additional conditions in the conceptual sending algorithm, I'll
tly couples the ARP/ND tables with
the forwarding table, so if a bogus entry is inserted in the former,
it will affect forwarding behavior. As mentioned in the first
paragraph, a PC router using a vanilla FreeBSD kernel behaves that
way. I won't surprised even other commercial routers that u
ived".
In fact, *BSDs correctly "scope" ND messages per-link, and it doesn't
confuse the same link-local addresses received on different links wrt
ND processing. It still believes an unknown address as on-link if it
receives an ND message from that address, based on the literal RFC
definition of on-link.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
d bullet
may be a redundant as part of definition, so I don't oppose to
removing it this time. But doing so in the context of a security
concern may be misleading.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
cation".
Aside from the possibly inappropriate comment wording, does that
address your concern?
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
implement it). So, IMO, if this
document wants to kill on-link caching, it should at least note that
it also kills address caching in effect. If implementors of address
caching still think it's acceptable, then I have no objection to that
(I have no stake in that area, anyway).
I hope I'
happen:
- if the node has already a neighbor cache entry for P::x on interface
I1, it does nothing about the source address of that NS
- if the node does not have any neighbor cache entry for P::x on any
interface, it will create a new neighbor cache entry on inte
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 Syst
when it returns, it may lead to a problem
described in Section 3 below.
that would make sense to me. I'd then be wondering whether this is
really something to be noted explicitly since it may sound something
pretty obvious.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
--
on' like
this, it should be described outside this listing, somewhere more
appropriate in the entire context.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
chanism.
>
> Please let us know if the new text works for you?
This text works for me (although I guess these new sentences would be
a very good target for the IESG to make a "discuss" comment - good
luck:-).
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
---
n, of course, and so do I.
I would not like this document to set new rules (note, again, that I'm
not objecting to discussing new changes to RFC4861/4862. I'm simply
objecting to doing that in this document).
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
cation". Of course, I
don't oppose to that discussion per se, which will eventually be
necessary anyway, but that should be performed more explicitly and
with seeking consensus among implementors that might be affected by
that action. I'd like this document to concentrate on its
&qu
the related 6man and v6ops threads before sending my comments.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
kely that some implementors naively implement the would-be-obsolete
rule by simply referring to the "subnet model" document. I also
believe this approach is generally desirable because this document
just tries to clarify some subtle points of RFC4861, rather than
making a substantial change to it.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
of "Further details on this kind of extension are beyond the
scope of this document."
As stated above, I'd rather suggest remove this bullet, in which case
this concern will be resolved automatically. But if we keep it, I'd
like the wording to reflect the original intent o
find any subsequent discussion.
Thanks,
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
Date: Sun, 3 Aug 1997 15:20:03 -0700 (PDT)
From: Mukesh Kacker <[EMAIL PROTECTED]>
Subject: (IPng 4241) msg_controllen and "padding at end" issue:
draft-stevens-advanced-api-04.txt
To: [EMAIL PR
both valid scenarios and (if there aren't major
> drawbacks) common misconfigurations.
In general, I don't disagree. My point is that there are several
levels of the problems, from one that is inevitable within the current
protocol to one that could be avoided by properly implemen
y
pointed out) v6:{ULA,global} vs v4:{site-local(RFC1918),global}.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
fically responded
the quoted (below) part of your previous response to Suresh, where I
don't see any relevance to the inspection by an intermediate node.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
=from here ===
Suresh,
I thought my
he IPv6 header. But I didn't think the
following bullet of draft-krishnan-ipv6-exthdr-01
o Extension headers must be processed in any order they appear
intended to amend the restriction. My interpretation was it meant
headers except the hop-by-hop options header.
---
JINMEI, Tatuya
Inte
clear.
Yours is much better than mine in clarity.
> We could in addition say
> The fact that Global Unicast addresses other than those that
> start with binary 000 have a 64-bit interface ID field [RFC4291]
> does not imply that the 64 bit prefix should be considered
&
t any
prefix is on- link. This means the address should initially be
considered the one having no internal structure as shown in
[RFC4291]. A host is explicitly told that prefixes or
addresses are on-link through the means specified in [RFC4861].
---
JINMEI, Tatuya
I
nt of the draft, I
think it's better to note that explicitly.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
that have often been
misunderstood. The Security Considerations section mention that (for
a different purpose), but I think it's better to state it earlier,
probably in the Introduction.
---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
-
At Thu, 10 Jan 2008 18:36:06 -0800,
JINMEI Tatuya wrote:
> > I have a question about RFC 4862 Section 5.4.5.
> > Please let me confirm about it.
> >
> > It says,
> >
> > 909If the address is a link-local address formed from an interface
> >
ng the conflicted
MAC address. Whether it's a "real" hardware address or not doesn't
matter in this sense.
So,
> When DAD fails for IP address based on software-based MAC address,
> should the system disable IP operation on also that interface?
9042943.pdf
He generated 250,000 prefixes based on some moderate assumption on
prefix allocation/usage policies.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&a
fully occupied for some personal matters, and
I'm afraid I won't have time for any IETF related work at least until
later next week. Basically, I'm just an individual reviewer who
happen to review these drafts without any authority, so please go
ahead if you think the updated version i
r for other
obvious bugs, and I think this is one such trivial case.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
ination host, the source host MUST NOT issue
an NS to resolve the destination contained within the Redirect.
This doesn't make sense (see comment about Section 2.1).
JINMEI, Tatuya
Communi
esn't stop at Rule 5? If so: since both
of {dst=2001::1, src=2001::2} and {dst=10.1.2.3, src=10.1.2.4} have
matching labels (1 and 4 respectively), Rule 5 doesn't make a tie
break. Hence Rule 6 applies.
JINMEI, Tatuya
would
not properly react to the router-flag change or detected unreachable
router either). That's why you MUST delete the destination cache in
this case.
> If I do so, will it be a non-compliance to the RFC?
I don't think so. The RFC says "the entries *need not be* dele
se definitions can be consistent. But we could not find a better
way to explain the seeming discrepancy at that time; hence this text.
JINMEI, Tatuya
Communication Platform Lab.
r all unicast addresses, except those that start with the binary
value 000, Interface IDs are required to be 64 bits long and to be
constructed in Modified EUI-64 format.
(section 2.5.1)
JINMEI, Tatuya
st some of these
cases, but as far as I know no specification explicitly requires that.
JINMEI, Tatuya
Communication Platform Lab.
Corpor
for me as a
compromise if that makes a quicker decision.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
ot a rhetorical
question; I'm just asking).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
it's reasonable per se (it might), but whether we
should do this while RA already has this provision and would actually
be better than DHCPv6-based approach. A new draft from the dhc group
will reportedly (hopefully?) answer this main question, so, again, I
think we should hold off for a wh
overs this topic. So I think it's better to hold off for
now and wait for the document, rather than continue this thread
with keeping possible misunderstanding or confusing about the base
protocol principles.
JINMEI, Tatuya
o write a short I-D that clarifies this point. In
this case I believe it should be a generic note on point-to-point link
that doesn't have the notion of L2 address (and thus doesn't require
L2 address resolution) rather than a part of a document for a specific
link type such as ipv6-ov
replaced.
I'm not sure what you are going to suggest with this, but it doesn't
matter in any case if we agree on the "silent" version of the text.
JINMEI, Tatuya
Communication Platform Lab.
Corpor
As very often in the first place, whether it
would indicate a duplicate address or an attack. We can safely leave
it to implementations without a fear of disruption in practice. So,
I'll stop here on this matter until, someday, we need to discuss h
d the scope of this document.
This is probably enough since this bullet is clearly separated from
bullet #3. Does this work for you (and others)?
JINMEI, Tatuya
Communication Platform Lab.
that the advertisement will not affect the
normal Neighbor Discovery [RFC4861] processing.
3. Otherwise, the advertisement is processed as described in
[RFC4861].
JINMEI, Tatuya
Communication Platfo
12 hours or so, unless I see a clear wg consensus on the change by
then. (For that matter, I'd disagree on introducing this change to
this document at this stage)
JINMEI, Tatuya
Communication
At Sat, 07 Jul 2007 03:09:23 +0900,
JINMEI Tatuya <[EMAIL PROTECTED]> wrote:
> I tend to agree (I also thought this as an option myself). Thanks for
> the suggestion.
I've updated the AUTH48 version of rfc2462bis with this fix. Other
(major) changes since the latest version o
detected by the Duplicate Address
> > Detection procedure, which should be manually handled by the
> > system administrator.
> > 3. Otherwise, the advertisement is processed as described
> > in [I-D.ietf-ipv6-2461bis].
I tend to agree (I also though
procedure, which should be manually handled by the
system administrator. The advertisement is processed as described
in [I-D.ietf-ipv6-2461bis] for all other cases.
(the additional note "this case would indicate..." may sound too
verbose. If so, I'm willing to remove
prefixlen 64
(while receiving RAs with the prefix information for 2001:db8:1234::/0
and L=0)
the administrator is not "overriding" the information advertised by
the RA; they are simply "specifying" the information which has not
been provided.
ministrator. If the target address is tentative, the
tentative address is not unique.
(the additional note "this case would indicate..." may sound too
verbose. If so, I'm willing to remove it.)
Does this make sense?
JINMEI, Tatuy
scenarios. I've not done that recently, but
I'm pretty sure that BSDs would still show the conforming behavior in
both of the test cases (i.e., send the packet to the default router in
the first scenario; send NS in the second scenario).
JINMEI, Ta
61bis]". Hence my proposed
text. I'm not sure whether you agree with it or not, but I'm still
not convinced that referring to 2461bis is enough. So, I still plan
to keep my proposed change unless I hear otherwise from others.
Thanks,
JINMEI,
But I don't think it's always obvious for
implementors. I usually hate a redundant description, but in this
case I believe we should be specific in 2462bis.
JINMEI, Tatuya
Communi
specifically talking about? You
have repeatedly stated something like "an implementer of a popular
IPv6 host [...] missed this behavior", but I don't think I've heard
which implementation it is. Is there any reason for not being
specific?
l.
Thanks,
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
I guess I found yet another corner c
he categorization in this wg (and possibly with the
ADs).
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
---
1 - 100 of 693 matches
Mail list logo
