On Nov 3, 2003, at 5:12 PM, Christian Huitema wrote:
In the case in point, there is a significant constituency who believes
that they need a replacement for site local addresses, and that
"draft-hinden" is a reasonable way to obtain this replacement. You are
indeed free to not use such addresses an
We don't have precedence exactly. Usually same author does recycle. As
I walk-the-walk and don't just talk-the-talk. For RFC 3493 we had
multiple editor for years. But we never changed the original inventor
of that API Robert Gilligan. ALso I have seen no significant technical
value add except
Hesham
> > And I think the prefix with L=0 and A=1 may cause unnoticed address
> > duplication.
>
> => If you advertise L =0 and want to assign the same prefix
> to multiple links, then you must be able to handle DAD, NS ...etc
> across links. This is what the ND proxy proposal does.
> In ot
James Kempf wrote:
Jim,
Are there any precedents? What has IETF done in other cases where specs have
been rev-ed?
The only case I personally know of is Mobile IPv4, in which the
author/editor name was not changed when a new revision was put out, but
perhaps there are others where different procedu
> If the purpose of prefixes with L=0 is to inform hosts to
> send traffic
> to the default router, why not omit those prefixes altogether from
> RAs. Host will send the packets destined to unknown prefixes to a
> default router anyway.
=> Because you want the host receiving the RA
to
I've gone through the threads that Rich Draves sent me to extract
the issues raised with draft-ietf-ipv6-router-selection-02.txt.
There were a number of relatively minor editorial suggestions to
which Rich had responded with an okay. These I am already
incorporating into the document.
Beside
> On Fri, 24 Oct 2003 11:24:08 +0900,
> Soohong Daniel Park <[EMAIL PROTECTED]> said:
> I agreed with your mention and this issue is work in progress
> at the DNA BOF. A second BOF will be scheduled during
> this meeting.
> For more reference, please look into this draft.
> http://www.ie
Brian,
My concern is really to get this in place reasonably quickly, and I think that
means setting relatively clear guidelines for IANA rather than leaving the
field open for endless debate.
I believe that you and I are in agreement here Brian in a general sense,
but we possibly differ on what
> On Thu, 23 Oct 2003 18:11:55 -0700,
> Vijay Devarapalli <[EMAIL PROTECTED]> said:
> here is another issue. it involves both 2461 and 2462.
> RFC 2461 says
> Before a host sends an initial solicitation, it SHOULD delay the
> transmission for a random amount of time between 0 an
Whoa, sorry if this got that far out of context!I very expressly
believe that a local scheme in general, and the one in draft-hinden in
particular, is needed for a number of scenarios!
--On Monday, November 03, 2003 17:12 -0800 Christian Huitema
<[EMAIL PROTECTED]> wrote:
Hans,
You have c
Dear Jinmei-san,
JINMEI Tatuya / wrote:
On Fri, 31 Oct 2003 12:52:14 +1100,
Greg Daley <[EMAIL PROTECTED]> said:
The difficulty comes when an RS comes from a global
source address which is not directly connected to
a router.
Based on RS processing rules, the host which sent
the RS is wit
> On Mon, 03 Nov 2003 16:22:52 -0800,
> Fred Templin <[EMAIL PROTECTED]> said:
> Don't you mean rfc246[12]bis? (Or, are you planning to
> revise rfc2460 as well?)
Oops, sorry, of course I meant rfc246[12]bis.
JINMEI, Tatuya
> OK, this is going to go around endlessly, so please re-read my
original
> message where I said that there are some who simply do not agree that
> local
> addressing is needed -- I know that is your position and I respect it.
I
> also said that I firmly disagree and suggest that we have plenty of
OK, this is going to go around endlessly, so please re-read my original
message where I said that there are some who simply do not agree that local
addressing is needed -- I know that is your position and I respect it. I
also said that I firmly disagree and suggest that we have plenty of
scena
Don't you mean rfc246[12]bis? (Or, are you planning to
revise rfc2460 as well?)
Fred
[EMAIL PROTECTED]
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
---
> On Fri, 31 Oct 2003 12:52:14 +1100,
> Greg Daley <[EMAIL PROTECTED]> said:
> The difficulty comes when an RS comes from a global
> source address which is not directly connected to
> a router.
> Based on RS processing rules, the host which sent
> the RS is within a hop of the router, b
> On Fri, 24 Oct 2003 09:41:35 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
> My initial thought is also that we should not make RFC 2461bis (or
> 2462bis) include every extension specified since 1998. Those can stay
> very well in separate drafts. Of course, we should still c
I'll combine two answers in message..
[me:]
> > Why exactly should we care if party X's internal applications break
> > because it hijacks a prefix?
On Mon, 3 Nov 2003, Hans Kruse wrote:
> We don't, and that is my point. The draft in question improves on that
> situation by creating a prefix th
On Mon, Nov 03, 2003 at 04:22:55PM -0500, Keith Moore wrote:
> > On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote:
> > > I don't think that we should be defining getaddrinfo() in terms of
> > > "whatever lookup service happens to be around" because it's very
> > > difficult to get reliab
We don't, and that is my point. The draft in question improves on that
situation by creating a prefix that the rest of the network can easily deal
with. Internal apps may still break, although I would argue that the local
addressing prefix opens some options to make that a little less likely..
Pekka Savola wrote:
On Mon, 3 Nov 2003, Hans Kruse wrote:
Please explain to me how the job of applications gets any easier if the
local addressing is done with a hijacked prefix
Why exactly should we care if party X's internal applications break
because it hijacks a prefix?
Because si
On Mon, 3 Nov 2003, Mario Goebbels wrote:
Hi Mario,
This is theoretically allowed. Check out section 2 of RFC3513
"In IPv6, all zeros and all ones are legal values for any field,
unless specifically excluded. Specifically, prefixes may contain, or
end with, zero-valued fields."
I really
> On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote:
> > I don't think that we should be defining getaddrinfo() in terms of
> > "whatever lookup service happens to be around" because it's very
> > difficult to get reliable and repeatable behavior that way.
>
> Isn't the DNS a lookup se
On Mon, 3 Nov 2003, Hans Kruse wrote:
> Please explain to me how the job of applications gets any easier if the
> local addressing is done with a hijacked prefix
Why exactly should we care if party X's internal applications break
because it hijacks a prefix?
--
Pekka Savola
Soliman Hesham wrote:
> I wish we clarify the above. The prefixes with L=0 makes DNA work
> complicated. Though they are troublesome, I am afriad that,
> in wireless
> environment, we can't avoid them.
=> If it is found that in some deployment cases the L=0
causes problems, the network admi
My question regarding "need anything else" referred only to the registry
requirements. And I think we really need to delineate those requirements.
I do not appreciate your personal attack; reading either this specific
message or the archive should make it clear that I did not "miss this major
Jim,
Are there any precedents? What has IETF done in other cases where specs have
been rev-ed?
The only case I personally know of is Mobile IPv4, in which the
author/editor name was not changed when a new revision was put out, but
perhaps there are others where different procedures were followed.
On Mon, Nov 03, 2003 at 10:42:02AM -0500, Keith Moore wrote:
> I don't think that we should be defining getaddrinfo() in terms of
> "whatever lookup service happens to be around" because it's very
> difficult to get reliable and repeatable behavior that way.
Isn't the DNS a lookup service that h
> Do we need anything else from a technical perspective?
I think I and Keith Moore commented on the application impact,
and to the extent that the current document doesn't state
the application impact very accurately.
Once that application impact is better known one could and should discuss
the
> [...]
> > - IMHO, getaddrinfo()'s job should be to report what is in DNS, not
> > to try to
> > coerce apps into behaving well. So even though apps shouldn't be
> > using link-local addresses, and even though people shouldn't list
> > link-local addresses in DNS, getaddrinfo() should not t
[...]
> - IMHO, getaddrinfo()'s job should be to report what is in DNS, not to try to
> coerce apps into behaving well. So even though apps shouldn't be using
> link-local addresses, and even though people shouldn't list link-local
> addresses in DNS, getaddrinfo() should not try to hide suc
Having looked at this again, I'm firmly convinced that:
- if address family is set to AF_UNSPEC, getaddrinfo() should by default
attempt both IPv4 and IPv6 lookups - even if the local system is not
capable of communicating on both IPv4 and IPv6. it can be useful to do A
lookups even if t
Dear Hesiam
Thanks for your prompt reply.
> => Actually, I think the L flag is a really powerful feature.
> Basically when it indicates that a prefix is not on-link
> it is informing hosts that they should send their traffic
> to the default router. This is useful for the case you mentioned
If
> Something about prefixes with L=0 are confusing to me. Kindly see
> below.
>
> 1. The prefixes with L bit off.
> - The meaning/ purpose of prefixes with L=0 is not exactly clear
>to me. What's the use of non-on-link prefixes for a node?
>
> 2. The prefixes assigned to more th
Dear Hesham
Something about prefixes with L=0 are confusing to me. Kindly see
below.
1. The prefixes with L bit off.
- The meaning/ purpose of prefixes with L=0 is not exactly clear
to me. What's the use of non-on-link prefixes for a node?
2. The prefixes assigned to more than one links.
Hi!
I need a clarification on the question if I can use the very first subnet in a network.
Means if I would get assigned 2001:1234:5678::/48 from a RIR, if I can use
2001:1234:5678:0::/64 within my own network, or if the same rules as in IPv4
subnetting apply (first and last one aren't usable)
I agree with Juergen's suggestion as well. The scoped addr arch
should mandate the use of 0 as the default zone ID.
Brian
Juergen Schoenwaelder wrote:
On Mon, Nov 03, 2003 at 03:37:47PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
I am not sure why this is helpful. Is there a particul
On Mon, Nov 03, 2003 at 03:37:47PM +0900, JINMEI Tatuya / [EMAIL PROTECTED]@C#:H wrote:
>
> >I am not sure why this is helpful. Is there a particular reason why
> >we can not just say that the default zone is indicated by a zone
> >index which MUST (or SHOULD if we have to compromise)
Clarifying two comments (maybe I should have proof-read them more
carefully)..
On Mon, 3 Nov 2003, Pekka Savola wrote:
> 7) In the section 9, "Forwarding", the second rule about sending an ICMP DU
> is specified. Has it already been considered whether this applies to
> multicast destination addre
Minor comment on comments..
> From: Pekka Savola <[EMAIL PROTECTED]>
> 4) I'm not sure whether I see the immediate need for the unique subnet
> multicast scope assignment, as below:
>
>Furthermore, to avoid the need to perform manual configuration in
>most cases, an implementation should
Hi,
Below are my LC comments on the scoping-arch document.
In general, I think the document is in a pretty good shape, but can be
improved slightly. I think it should be possible to send the document to
the IESG after a revision.
Two major points to note:
- the ICMPv6-bis document is stalled a
41 matches
Mail list logo
