> On Mon, 18 Aug 2003 21:00:36 -0400,
> "Bound, Jim" <[EMAIL PROTECTED]> said:
> The solution that will work for now is make a statement in the
> IETF and in industry IPv6 implementation documentation
> That link-local addresses SHOULD not be
> included in the DNS.
I agree with this.
> On Thu, 14 Aug 2003 07:35:57 -0400,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Another potential advantage for IPv6 that is a little harder to quantify is
> the notion of "graceful" renumbering - the ability to have a transition
> state in which both the old and new prefixes are in use s
> On Thu, 07 Aug 2003 13:58:22 +0200,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> So I don't believe that a scope field as part of the address format
> is a meaningful idea, because I don't think scope is a single-
> valued function in the first place.
(I'm just wondering) What exact
> On Mon, 04 Aug 2003 11:06:55 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
> I would like to hear from the working group on how we should proceed. I
> think the choices are:
I prefer this one:
> A) Deprecate Site-Local addresses independently from having an alternative
> solution a
> On Thu, 17 Jul 2003 14:21:41 -0400,
> Vladislav Yasevich <[EMAIL PROTECTED]> said:
>>> The reason is that
>>> most Mobile IPv6 implementation are supported in the "kernel" and
>>> already do checksumming.
>>
>> What exactly do you imagine about the implementation that supports
>> mobil
> On Fri, 11 Jul 2003 14:08:12 -0400,
> Vladislav Yasevich <[EMAIL PROTECTED]> said:
> In Section 4.1, the draft describes how to use the IPV6_CHECKSUM
> option on mobility headers. The draft seems to turn off "kernel"
> checksumming by default on the IPPROTO_MH socket. I belive
> that
> On Tue, 15 Jul 2003 17:59:51 +0900,
> [EMAIL PROTECTED] said:
> PS: KAME folks, any clarifications/corrections are requested.
The description basically looks correct. A minor point:
I'm not sure if we provide the client side of "noop (Qtype=0)" and
"supported query types (Qtype=1)."
> On Thu, 24 Apr 2003 08:41:53 +1000,
> [EMAIL PROTECTED] said:
> Is the following a legal IPv6 literal? The RFC's are unclear
> about whether leading zeros are allowed or not if they would
> make a segment more than 4 character wide.
> 1234:1234:1234:123
> On Wed, 02 Apr 2003 14:36:19 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> What was the consensus, if any, on alternatives to site-locals when SL
> is deprecated? In particular, which prefixes will we use for
> disconnected or intermittently connected "site"s? I've checked the
>
Before responding to the consensus call on site-local addresses, I'd
like to ask one question for clarification. (As required, I changed
the subject line).
What was the consensus, if any, on alternatives to site-locals when SL
is deprecated? In particular, which prefixes will we use for
disconne
(In this reply, I'm very specific to the BSD kernel, which may not be
appropriate in this list. If the discussion continues on this
particular topic, I'll change the place.)
> On Sun, 23 Mar 2003 22:46:51 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>> => I have a major concer
I have some comments on draft-chakrabarti-ipv6-addrselect-api-00.txt,
in addition to those already raised in this list (I'd apologize in
advance if there's any duplication).
1. Introduction
Currently IPv6 socket API extensions does not provide a
mechanism to choose a particular source addr
> On Fri, 21 Mar 2003 00:39:12 +0100,
> Francis Dupont <[EMAIL PROTECTED]> said:
>A draft has been submitted to address source address selection at
>the per-socket (and per apps) basis. Currently it discusses preferences
>of source address selection by the application for priv
(oops, sorry, the message was incomplete)
> On Thu, 20 Mar 2003 03:31:22 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> As for other configuration (e.g. DHCPv6) by DHCPv6:
> I would vote for SHOULD, with one condition that
... that the other configuration specification is clearly s
Since I won't be able to join the decision making about the
requirement level of DHCPv6, I'd like to present my opinion in an
off-site manner. I'll separate the requirement for stateful address
autoconfigurataion (the M bit) part and other configuration (the O
bit) part, as suggested by Dave.
As
> On 16 Mar 2003 12:07:57 +0200,
> Mika Liljeberg <[EMAIL PROTECTED]> said:
> No. It's a very specific case of "how to implement the following bit of
> next-hop determination" in a host with multiple network interfaces and
> how it relates to RFC3484 and destination address selection:
>
> On Sat, 15 Mar 2003 18:15:25 +0200,
> Markku Savela <[EMAIL PROTECTED]> said:
>> to be clear: for outgoing packet, that should be enough. for incoming
>> packet, you will need to have a mapping table of
>> interface id -> link id
>> and translate id accordingly and use "fe80::1%linkX"
> On 15 Mar 2003 16:24:00 +0200,
> Mika Liljeberg <[EMAIL PROTECTED]> said:
>> > For example, this mechanism would not work properly when a local
>> > caching resolver is used. In this common configuration, ...
>> >
>> >What exactly do you mean by "a local caching resolver"? Do
> On Sat, 15 Mar 2003 07:40:45 -0500,
> Margaret Wasserman <[EMAIL PROTECTED]> said:
>> 3.1.2.1 Problems for All Site-Border Nodes
>>
>> Some people have commented that the same problems exist for link-
>> local addresses, but this is not entirely true. Link-local
>> addresses can use a
I've finally read draft-wasserman-ipv6-sl-impact-02.txt. (I admit I
should have done it much earlier...)
(Just to make my position clear)
First of all, I'm not a fun of site-local (SL) addresses, and agree on
limiting the use of SLs *to some extent*. So, I'm not intending to
criticize the draft.
> On Sat, 08 Mar 2003 23:16:31 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>> Since this is a MAY, the delegating router (i.e. server) MAY NOT send
>> a Reply message, which will cause a bad effect (that the invalid
>> prefix is going to be used). For the case of address assignment, thi
> On Sat, 08 Mar 2003 23:27:42 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>> I know (and agree), but I'm saying the PD specification should be
>> clear wherever a difference between address assignment and prefix
>> delegation exist. We should be rather redundant than leave the
>> diffe
> On Sun, 23 Feb 2003 07:25:37 -0800,
> "Richard Draves" <[EMAIL PROTECTED]> said:
>> > You do not generate link-local addresses for the new IIDs. And not
>> > site-local either. Just global addresses.
>>
>> Why not for site-local addresses?
> There's no technical reason you couldn't g
> On Thu, 27 Feb 2003 09:35:52 +0200 (EET),
> Pekka Savola <[EMAIL PROTECTED]> said:
>> > cover even all the theoretical cases. I'd much rather see a very simple
>> > basic version of prefix delegation which can be used to get started.
>> > There's no way we could anticipate what will
(I'm posting this since I was asked about the changes in the new
revision privately.)
As you may have noticed, I submitted a new revision of the advanced
API draft, draft-ietf-ipngwg-rfc2292bis-09.txt. This is a very minor
revise to be sent to the IESG, and should not require any changes to
imple
> On Fri, 28 Feb 2003 00:46:37 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>> 4. The PD draft should reflect some parts of
>> draft-ietf-dhc-dhcpv6-interop-00.txt. With a quick look, Sections
>> 1, 2, 3, 4, 5, 6, 9, 10, and 11 should also apply to the PD draft.
> I have made the change
> On Fri, 28 Feb 2003 00:46:37 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>> 3. Section 10.2 contains the following sentence (newly added in the
>> latest revision):
>>
>> If the delegating router cannot delegate any prefixes to an IA_PD in
>> the message from the requesting router, th
> On Fri, 28 Feb 2003 00:46:37 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>> 2. Section 11.1 now specifies the requesting router to use
>> Rebind/Reply exchanges to verify an existing binding (instead of
>> Renew/Reply exchanges). According to the very recent
>> clarifications on the b
Sorry for not responding sooner.
From this message, I'll separate the thread for each particular issue.
> On Fri, 28 Feb 2003 00:46:37 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>> 1. Issues about the preferred and valid lifetimes were not fully
>> addressed. I've not seen consensus
> On Fri, 28 Feb 2003 11:13:32 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> We did some interoperability testing thof independent DHCPv6 implementations
> at the recent TAHI interoperability testing event. I've published a list
> of issues, draft-ietf-dhc-dhcpv6-interop-00.txt, ide
> On Mon, 24 Feb 2003 08:00:00 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Please review draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt and
> reply with comments. If you recommend the document for advancement without
> revision, please respond with a quick acknowledgment. No
> On Mon, 24 Feb 2003 08:51:01 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Please ignore the first sentence of this reminder - it was queued for
> transmission before the round of discussion that began at the end of last
> week...
>> Reminder and note: there has been not response
> On Thu, 20 Feb 2003 13:56:59 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> Reminder and note: there have been a few responses to this WG last call,
> but no explicit positive recommendations for advancement. Please review
> draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with
> On Tue, 18 Feb 2003 13:56:36 -0800,
> "Fred L. Templin" <[EMAIL PROTECTED]> said:
>> I have myself been confused by the L bit in the past but I don't think
>> there is anywhere near as much ambiguity here as you. And, if there is
>> the node requirements document isn't the place to fix
> On Mon, 10 Feb 2003 10:34:56 -0800,
> "Fred L. Templin" <[EMAIL PROTECTED]> said:
> I wonder if the setting of the "L" bit in Prefix Information options
> also bears some mention in this section. RFC 2461, section 4.6.2 says:
>"When (the L bit is) not set, the advertisment makes no
> On Fri, 14 Feb 2003 09:34:41 -0800,
> "Richard Draves" <[EMAIL PROTECTED]> said:
>> Also, it wasn't clear to me whether link-local addresses are
>> generated for every new IID or not. If they are, RFC 2462
>> rules in Section 5.4 apply and the collision problem may be
>> solved that
> On Mon, 10 Feb 2003 11:23:07 -0500,
> Ralph Droms <[EMAIL PROTECTED]> said:
> And - for other members of the dhc, dnsext and ipv6 WGS: please
> respond to this last call notice with comments or an explicit
> ack to indicate you accept the draft as published. Thanks...
I'm okay to publ
> On Wed, 22 Jan 2003 14:26:50 -0800,
> Michael Hunter <[EMAIL PROTECTED]> said:
> Section 11.2 of draft-ietf-ipngwg-rfc2292bis-08.txt contains a slight
> error:
>int on = 1;
>setsockopt(fd, IPPROTO_IPV6, IPV6_DONTFRAG, &on, sizeof(&on));
> s/sizeof(&on)/sizeof(on)/
Tha
Thanks for the response, and sorry for my delayed reaction.
> On Fri, 03 Jan 2003 12:54:19 -0500,
> Thomas Narten <[EMAIL PROTECTED]> said:
>> However, there seems to be no description about the case in RFC 2461.
>> This is perhaps intentional, because the preferred lifetime does not
>>
> On Tue, 07 Jan 2003 16:42:18 -0800,
> "Fred L. Templin" <[EMAIL PROTECTED]> said:
> I believe the text you are referring to is the following:
> "When the application is sending packets too big for the path MTU
> recvmsg() will return zero (indicating no data) but there will be a
Hello,
I have a question about a corner case of IPv6 Neighbor Discovery; what
should a host do if a received RA contains a prefix whose preferred
lifetime is larger than valid lifetime?
In terms stateless address autoconfiguration, the specification
clearly says that such a prefix must be ignored
> On Wed, 27 Nov 2002 22:14:28 +,
> Ole Troan <[EMAIL PROTECTED]> said:
>>> but how on earth did we end up in this discussion? From what I
>>> remember of the voting in Atlanta we had consensus for a limited
>>> version of site-locals...not creating a separate address structure?
>
> On Mon, 25 Nov 2002 19:42:53 +0200 (EET),
> Pekka Savola <[EMAIL PROTECTED]> said:
> There seems to be an assumption that provably unique SL addresses would be
> needed.
Perhaps this is a silly comment, but excuse me, I remember a very
similar proposal by Paul Francis at an IETF meeti
Unless I've missed something, I've not received any responses to the
attached message. I interpreted the silence as a sign that there is
no need to update 2292bis wrt the issues in this thread. Otherwise,
please let me know.
Thanks,
JINMEI, Tatuya
> On Wed, 13 Nov 2002 23:48:54 -0500,
> Keith Moore <[EMAIL PROTECTED]> said:
>> I would say, hoping this does not cause another flame, that the issues
>> of site-local are not crucial for the deployment of IPv6.
> I respectfully disagree. I think it's critical that we solve this
> is
> On Wed, 13 Nov 2002 09:30:23 -0800,
> Bob Hinden <[EMAIL PROTECTED]> said:
> I don't think it is wise to ask the IESG to reconsider the address
> architecture (this is more than an editorial change to the RFC-editor). I
> also think the issues regarding the usage of site-local are mo
> On Tue, 12 Nov 2002 13:53:00 +0100,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> Unfortunately it's too late to catch the addressing architecture
> document unless we recall it from the RFC Editor and cycle it
> through the IESG again. But I propose that we do exactly that,
> in orde
> On Wed, 06 Nov 2002 13:44:49 -0500,
> Thomas Narten <[EMAIL PROTECTED]> said:
> With regards to the basic API:
> - Will we want the basic API to ever allow a way to specify the
> Traffic Class? If so, will it be better to define a new extension or
> to overload the Flow Label?
> -
> On Mon, 04 Nov 2002 17:35:03 +0900,
> Soohong Daniel Park <[EMAIL PROTECTED]> said:
> I'd like to get all hosts addresses in small network, can i get these
> addresses usign multicast ?
> Otherwise, do i reserve specific multicast address for this purpose ?
If the "small network" is a
> On Thu, 31 Oct 2002 19:38:46 -0500,
> Margaret Wasserman <[EMAIL PROTECTED]> said:
>> A BCP that discourages uses of SLs except
>> in certain narrow cases and explains why is probably more useful than a
>> BCP that tries to explain exactly when SLs cause problems and when they don't.
>>
> On Thu, 31 Oct 2002 20:43:14 +0200 (EET),
> Pekka Savola <[EMAIL PROTECTED]> said:
>> > Now the attacker can send packets with a fec0::/10 source
>> > address to the customer -- no one will block them unless
>> > they're explicitly configured as site borders -- before the
>> > custom
> On Thu, 31 Oct 2002 09:51:17 -0500,
> Margaret Wasserman <[EMAIL PROTECTED]> said:
> Are there any commercial routers today that include SBR support?
If I remember correctly, NEC has a product that supports SBR.
JINMEI, Tatuya
(Note: this message is not directly related to the main point of this
thread.)
> On Tue, 29 Oct 2002 08:51:12 +0200 (EET),
> Pekka Savola <[EMAIL PROTECTED]> said:
> I'm not even sure if we could get addrarch to draft standard, have folks
> implemented these two:
> --8<--
>Routers
> On Thu, 17 Oct 2002 07:34:17 -0400,
> [EMAIL PROTECTED] said:
> Title : Advanced Sockets API for IPv6
> Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei
> Filename: draft-ietf-ipngwg-rfc2292bis-08.txt
> Pages : 83
>
> On Thu, 17 Oct 2002 23:42:20 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Just FYI, below I've attached the change list, and briefly explained
> that I addressed your comments citing your original message.
Oops, sorry, I forgot one more point:
>> Re: references to RFC 2553; shou
> On Thu, 17 Oct 2002 10:00:18 +0900,
> [EMAIL PROTECTED] said:
>> I don't get the sense that we have consensus on this, because some
>> people seem to think that scoped addresses are appropriate for use by
>> general-purpose apps.
>>
>> for instance, there's really no way that an appli
> On Fri, 11 Oct 2002 16:15:29 +0100,
> Arun Prasad <[EMAIL PROTECTED]> said:
> Some doubts on the socket api for Ipv6.
> * When a IPV6 packet is received throught the interface "recvmsg", how to get the
> "zone_id" or "scope_id" for the received Ipv6 Addr. When the "recvmsg"
>
> On Wed, 16 Oct 2002 09:49:30 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
> The problems are likely to be seen with high use of UDP/ICMP, e.g.
> sending a Gigabit/FastEthernet full of UDP and checking how much that
> affects performance.
(if you're not requiring to add cac
> On Fri, 11 Oct 2002 09:54:55 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
> Perhaps we should have been more careful when discussing "how/when" to use
> caching.
> But well, 'htsearch' on RFC's for "cache" at http://rfc.eunet.fi (for
> example) returns 520 RFC's.
> I think
> On Mon, 14 Oct 2002 15:46:33 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
> As Jack has completed his updates to RFC 2553, I've put it back on the
> IESG for consideration for publication. That prompted the following
> comment from Bill Fenner.
> Thoughts on how to proceed?
This
Hello,
I'm about to submit a new revision of the advanced API (rfc2292bis)
draft, mainly in response to comments from you two (thanks, again, for
the comments). Most of the changes are trivial or based on consensus
in this list. However, I'd like to make an explicit response to some
of the comm
> On Wed, 2 Oct 2002 16:29:50 -0400 (EDT),
> Jack McCann <[EMAIL PROTECTED]> said:
> So I took a look at 2292bis-07.
Hello, thanks for the valuable comments.
> Some comments for alignment with the latest POSIX standard:
> - I suggest you update the Posix references, using the same
>
> On Fri, 04 Oct 2002 22:40:58 +0700,
> Robert Elz <[EMAIL PROTECTED]> said:
> | Then the "other documents" should be considered as an implementation
> | requirement?
> I'm not sure what you are meaning there?
I meant to refer to the following part
>> It is a
>> principle that is
> On Wed, 02 Oct 2002 10:33:56 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
> You seem to be saying that the addr arch document (in order to go to
> Draft) requires that there exist at least 2 implementations that
> enforce the requirement that IIDs are exactly 64 bits. That is, they
> On Wed, 2 Oct 2002 14:10:35 -0700,
> Michael Hunter <[EMAIL PROTECTED]> said:
>> Additionally, I suspect the removal actually breaks user code so much.
>> As I said before, user applications are usually expected to use
>> library functions for source routing and to not use the ip6r0_ad
> On Thu, 26 Sep 2002 13:03:53 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> Additionally, I suspect the removal actually breaks user code so much.
> As I said before, user applications are usually expected to use
> library functions for source routing and to not use the ip6r0_addr
> On Wed, 25 Sep 2002 13:52:58 -0700,
> Michael Hunter <[EMAIL PROTECTED]> said:
> [...]
>> I didn't remember the reason why the member name was removed, so I
>> found it from the web. You'll get the answer from the discussion
>> starting at the following URL:
>>
>> http://www.wcug.wwu
> On Mon, 23 Sep 2002 13:01:21 -0700,
> Michael Hunter <[EMAIL PROTECTED]> said:
>> Sorry, but I don't think we should incorporate this to the
>> specification. If an application writer assumes the existence of
>> ip6r0_addr, the source code will not compile with a compiler that
>> does
> On Sun, 22 Sep 2002 17:34:32 -0700,
> Michael Hunter <[EMAIL PROTECTED]> said:
> In 2292bis (rev 7) there are two errors:
> 1) ND_OPT_PI_FLAG_ROUTER only shows up in section 15 (summary of new
> definitions).
> 2) ip6_ext shows up in section 15 (summary of new definitions) but it
> is
(Sorry for the delayed response)
> On Wed, 11 Sep 2002 15:29:42 -0700,
> Michael Hunter <[EMAIL PROTECTED]> said:
> It would be easier to use if a c99 flexible array member was the last
> element:
>/* Type 0 Routing header */
>struct ip6_rthdr0 {
> uint8_t ip6
> On Wed, 21 Aug 2002 10:32:12 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
>> I agree. How about this (which is a total rewrite of abstract):
(snip)
> Works for me!
Okay, I'll replace abstract with the proposed one.
>> Are you suggesting to add the POSIX standard in References
> On Mon, 19 Aug 2002 18:16:49 +0200 (CEST),
> Erik Nordmark <[EMAIL PROTECTED]> said:
>> > why are there appendices? seems like at least some of these are part of
>> > the spec itself. Putting them in the appendices would imply that they
>> > perhaps aren't important.
>>
>> Hmm, the ap
(Since implementors' comments are required, I'll talk about a
particular network stack; the one in BSDs.)
> On Thu, 25 Jul 2002 08:43:49 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
>> 3.3. Destination Cache Management
>>
>> When host C processes a Router Advertisement and updates
> On Fri, 02 Aug 2002 15:16:11 -0700,
> Bob Hinden <[EMAIL PROTECTED]> said:
>> we might have the following choices (I can't think of other combinations that
>> make sense to me):
>> 1. all are optional
>> 2. load sharing is mandatory; others are optional
>> 3. load sharing and router pr
> On Thu, 15 Aug 2002 20:37:16 -0700,
> "Brian Zill" <[EMAIL PROTECTED]> said:
> My take: given that it appears the majority of implementations currently
> do "DAD", and that "DAD" provides for a cleaner multi-link subnet
> architecture, I think "DAD" is the better choice.
(Aside from t
(I'm explicitly ccing to Erik, because he may have some answers to a
comment.)
> On Tue, 06 Aug 2002 16:05:34 -0400,
> Thomas Narten <[EMAIL PROTECTED]> said:
> Here is my long overdue review of this document. Note that since this
> is document is intended to be published as Information
> On Tue, 30 Jul 2002 14:29:25 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> This may rather be an implementation issue, so I don't think we need a
> major revise of the draft just due to this. But I also think it would
> be good to add some note about the dependency in Section 8 b
> On Mon, 29 Jul 2002 14:11:00 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
>Apparently, KAME is not able to configure multiple plain IDs to be
>combined freely with all announced prefixes? Or can it?
> => I believe KAME has a notion of "the" id of the interface.
No, KA
draft-ietf-ipv6-default-addr-select-08.txt mentions two per-connection
configuration switches for source address selection. One is for home
vs care-of addresses, and the other is for temporary vs public
addresses.
The value of the switches may affect destination address selection,
because it dep
> On Wed, 24 Jul 2002 20:06:51 -0700,
> Ted Lemon <[EMAIL PROTECTED]> said:
>> Returning to your idea, it sounds attractive. However, I'm not sure
>> if this approach is applicable widely. In particular, I'm not sure if
>> "edge devices" such as personal laptops, PDAs, cell phones...,
> On Wed, 24 Jul 2002 18:38:45 -0700,
> Ted Lemon <[EMAIL PROTECTED]> said:
>> So more accurately, you meant like this?
>>
>>NI query
>> nodeinfo client --> the target
>> with some private key
>> <---
> On Wed, 24 Jul 2002 10:21:39 -0700,
> Ted Lemon <[EMAIL PROTECTED]> said:
>> to mean the diagram like this:
>>
>> NI query
>> nodeinfo client --> the target
>> with named (authorizing the name)
>> and private key
>> <--
>> NI response signed
>> by the p
> On Wed, 24 Jul 2002 22:56:04 +0900,
> [EMAIL PROTECTED] said:
>>> no, the device answering ICMPv6 request is not named.
>> ??? I'm a bit confused. Are you saying that we can *not always*
>> assume the device answering ICMPv6 request runs a name server?
> the thread of email ass
> On Mon, 22 Jul 2002 07:24:14 +0900,
> [EMAIL PROTECTED] said:
>>> i may be asking a stupid question, but where do you get that private
>>> key from? for instance, if a node responds with "www.ietf.org",
>>> we could get a public key for www.ietf.org by KEY RR query, but
>>> not the pr
> On Wed, 24 Jul 2002 10:37:28 +0900 (JST),
> Keiichi SHIMA <[EMAIL PROTECTED]> said:
>> thanks Phil. this approach sounds good.
> I agree, too.
I basically agree, too. A few points:
>> When MIP sends the spec up to the IESG for approval, we'll let the NG
>> working
>> group know
> On Mon, 15 Jul 2002 01:10:44 +0200,
> Brad Knowles <[EMAIL PROTECTED]> said:
>> the co-existence of ip6.int and ip6.arpa tree will require us to:
>> query ip6.arpa;
>> if (no record)
>> query ip6.int;
>> for backward compatibility. was it taken into account, or did you
>> test just "i
> On Thu, 18 Jul 2002 17:57:26 +0100,
> Ole Troan <[EMAIL PROTECTED]> said:
> if you don't mind, please let's try to focus on prefix delegation on
> this thread. griefs with DHCP based address assignment can be taken on
> the DHC list. I don't think we need to do the 'H' in DHCP means ho
> On Fri, 19 Jul 2002 12:51:58 +0900,
> JINMEI Tatuya <[EMAIL PROTECTED]> said:
> On Thu, 18 Jul 2002 17:57:26 +0100,
> Ole Troan <[EMAIL PROTECTED]> said:
>> if you don't mind, please let's try to focus on prefix delegation on
>> this thread. griefs with DHCP based address ass
> On Wed, 03 Jul 2002 02:37:01 +0900,
> [EMAIL PROTECTED] said:
>> A per-node switch probably doesn't make sense because it would have an affect
>> on both the "server-like" applications as well as the "client-like"
>> applications. However, an environmental switch could make more sens
> On Mon, 01 Jul 2002 13:51:37 -0400,
> Keith Moore <[EMAIL PROTECTED]> said:
>> > - limit in6_matchlen() to 64 for address selection.
>>
>> I agree that full-128bit comparison does usually not make much sense,
>> but I'm not sure if the assumption of the fixed prefix length is a
>> go
> On Mon, 01 Jul 2002 09:17:16 -0700,
> Alain Durand <[EMAIL PROTECTED]> said:
>>> => again this is inadequate and stresses the previous issue.
>>> This MUST must not move to the standard track part.
>>> Note my environment suggestion works well for this case because
>>> daemons (which w
> On Sun, 30 Jun 2002 19:28:59 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
>Rule 7: Prefer public addresses.
>If SA is a public address and SB is a temporary address, then prefer
>SA. Similarly, if SB is a public address and SA is a temporary
>address, then prefe
> On Sat, 29 Jun 2002 18:17:47 +0200,
> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote:
>=> Francis Dupont wrote:
>=> I strongly encourage items about prefix delegation for
>=> home sites because these are *urgent* for IPv6 deployment.
>I
> On Fri, 28 Jun 2002 10:31:34 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
>> The point, IMO, is that even DNS PTR responses are not reliable enough
>> for access control purposes, as described in
>> draft-ietf-dnsop-inaddr-required-03.txt.
> The draft does not descibe that
> On Wed, 26 Jun 2002 22:11:11 +0300 (EEST),
> Pekka Savola <[EMAIL PROTECTED]> said:
>> In my understanding, the threat imposed by malicious responses to
>> ICMPv6 node information query (Qtype = node name) is equal to
>> setting up DNS PTR records without forward zone administrators'
>
> On Thu, 13 Jun 2002 15:45:17 +0200,
> Brian E Carpenter <[EMAIL PROTECTED]> said:
> But in fact that isn't a correct assumption. It's only a certain class of
> systems (today's pure-client style PCs or their equivalents) for which the
> privacy aspect of temporary addresses makes any s
> On Wed, 12 Jun 2002 10:38:24 -0400,
> Margaret Wasserman <[EMAIL PROTECTED]> said:
>> The proposed text is trying to say that temporary addresses are preferable
>> but that there might be issues (such as applications having problems)
>> which consistitute a good enough reason to not fo
> On Wed, 12 Jun 2002 08:51:02 -0400,
> Keith Moore <[EMAIL PROTECTED]> said:
>> This rule may be sometimes controversial, but I personally think it is
>> reasonable, because we can (in theory) expect better reachability for
>> a smaller scope of destinations. This is especially true fo
> On Wed, 12 Jun 2002 09:06:37 -0400,
> Keith Moore <[EMAIL PROTECTED]> said:
>> As for the impacts on the applications' behavior, I don't worry so
>> much. I've configured my laptop to prefer temporary addresses over a
>> year (for experiences - I'm not a privacy-conscious guy), and I'
> On Tue, 11 Jun 2002 10:43:13 -0700,
> "Dave Thaler" <[EMAIL PROTECTED]> said:
> Personally I think DNS reverse lookups should go away, not
> site-locals. In my opinion, using ICMP name lookups to the
> node itself is a much better solution to making reverse
> lookups work, and they
1 - 100 of 370 matches
Mail list logo
