From owner-ipng@sunroof.eng.sun.com Fri Jun 1 05:17:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51CGZ914383 for ipng-dist; Fri, 1 Jun 2001 05:16:35 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51CGVe14376; Fri, 1 Jun 2001 05:16:31 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29930; Fri, 1 Jun 2001 05:16:38 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16032; Fri, 1 Jun 2001 05:16:38 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id 951BFF59; Fri, 1 Jun 2001 05:19:46 -0700 (PDT) Received: from exctay-gh03.tay.cpqcorp.net (exctay-gh03.tay.cpqcorp.net [16.103.129.53]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 23623D4A; Fri, 1 Jun 2001 05:19:46 -0700 (PDT) Received: by exctay-gh03.tay.cpqcorp.net with Internet Mail Service (5.5.2652.78) id ; Fri, 1 Jun 2001 08:16:37 -0400 Message-ID: <88BD5A70CA8BFA4CA15D0ED053E49D6950961A@tayexc14.americas.cpqcorp.net> From: "Powell, Ken" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] MN's packet reception Date: Fri, 1 Jun 2001 08:16:37 -0400 X-Mailer: Internet Mail Service (5.5.2652.78) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I disagree. The "as if" clause applies only to processing done "by upper-layer protocols within the mobile node", such as TCP and above. The processing described in [2] happens below TCP. Ken > -----Original Message----- > From: Jiwoong Lee [mailto:porce@ktf.co.kr] > Sent: Wednesday, May 30, 2001 2:06 AM > To: mobile-ip@sunroof.eng.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: [mobile-ip] MN's packet reception > > > All > > In addtion to the original mail, I suggest to remove the last > subordinate > clause (*) starting with "as if.." of the below paragraph in > MobileIPv6-13, > because > > [1] Generic Packet Tunneling in IPv6 spec does not state that kind of > statement and > [2] the MN's BU condition (#) seems to be outof accord with > (*), perhaps > from the view point of implementation. > > comment please. > > Jiwoong > > > > > For packets received by either the first or last of these three > methods, the mobile node SHOULD send a Binding Update to > the original > sender of the packet, as described in Section 10.8, subject to the > rate limiting defined in Section 10.11. The mobile node SHOULD > also process the received packet in the manner defined for IPv6 > encapsulation [4], which will result in the encapsulated (inner) > packet being processed normally by upper-layer protocols within the > mobile node, (*)as if it had been addressed (only) to the > mobile node's > home address. > > and > > In addition, when a mobile node receives a packet for which the > mobile node can deduce that the original sender of the packet has > no Binding Cache entry for the mobile node, or for which the mobile > node can deduce that the original sender of the packet has an > out-of-date care-of address for the mobile node in its > Binding Cache, > the mobile node SHOULD return a Binding Update to the sender giving > its current care-of address (subject to the rate limiting defined > in Section 10.11). In particular, the mobile node SHOULD return a > Binding Update in response to receiving a packet that meets all of > the following tests: > > (#) - The packet was tunneled using IPv6 encapsulation. > ... > > > > > ----- Original Message ----- > From: "Jiwoong Lee" > To: > Sent: Tuesday, May 29, 2001 9:44 AM > Subject: [mobile-ip] MN's packet reception > > > > All, > > > > Becasue CN's requirement to use Binding Cache when it sends > > a packet to MN is "SHOULD", the corresponding possibilities > > in which a MN receives a packet while away from home also > > should be described legitimately. > > > > A MN MAY receive a packet > > addressed to its home address, which is sent by a CN that DOES > > have a Binding Cache entry for the MN, if the CN does NOT like > > to use Routing Header. > > > > Jiwoong > > -- > > > > > > 8.9. Sending Packets to a Mobile Node > > > > Before sending any packet, the sending node SHOULD examine its > > Binding Cache for an entry for the destination address > to which the > > packet is being sent. If the sending node has a Binding > Cache entry > > for this address, the sending node SHOULD use a Routing header to > > route the packet to this mobile node (the destination > node) by way > > of the care-of address in the binding recorded in that > Binding Cache > > entry. ... > > > > > > 10.3. Receiving Packets While Away from Home > > > > While away from home, a mobile node will receive packets > addressed to > > its home address, by one of three methods: > > > > - Packets sent by a correspondent node that does not have a > > Binding Cache entry for the mobile node, will be sent by the > > correspondent node in the same way as any normal IP > packet. Such > > packets will then be intercepted by the mobile > node's home agent, > > encapsulated using IPv6 encapsulation [4], and > tunneled to the > > mobile node's primary care-of address. ... > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 05:58:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51CwOf14497 for ipng-dist; Fri, 1 Jun 2001 05:58:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51Cvle14482; Fri, 1 Jun 2001 05:57:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26746; Fri, 1 Jun 2001 05:57:55 -0700 (PDT) Received: from mail.n016.co.kr ([203.229.169.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00254; Fri, 1 Jun 2001 06:57:53 -0600 (MDT) Received: from freenet.ktf.co.kr (freenet.ktf.co.kr [203.229.169.83]) by mail.n016.co.kr (v3smtp 8.11.3 Copyright (c) 1998-2001 Sendmail, Inc. All rights reserved. Copyright (c) 1988, 1993 The Regents of the University of California. All rights reserved./8.11.1) with ESMTP id f51CsWP25751; Fri, 1 Jun 2001 21:54:32 +0900 (KST) Received: from words ([10.6.10.174]) by freenet.ktf.co.kr (8.9.3/8.9.3) with SMTP id VAA15743; Fri, 1 Jun 2001 21:55:30 +0900 (KST) Message-ID: <006001c0ea9a$133b2400$ae0a060a@words> From: "Jiwoong Lee" To: Cc: , References: <88BD5A70CA8BFA4CA15D0ED053E49D6950961A@tayexc14.americas.cpqco> Subject: Re: [mobile-ip] MN's packet reception Date: Fri, 1 Jun 2001 21:55:03 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ken, I re-reviewed the questionable statement in MIPv6-13 and I think your point was right. And now I think that sentence was quite perplexingly tricky,- because there are two subjects for a predicate verb 'process' in one sentence. The first half part in the sentence is saying the node's IPv6 encap/decap module processing, while the latter is saying the node's transport layer processing - trickily with two commas. Sooo amusing! :> Big thanks, Jiwoong ----- Original Message ----- From: "Powell, Ken" To: Cc: Sent: Friday, June 01, 2001 9:16 PM Subject: RE: [mobile-ip] MN's packet reception > I disagree. The "as if" clause applies only to processing > done "by upper-layer protocols within the mobile node", such > as TCP and above. The processing described in [2] happens > below TCP. > > Ken > > > -----Original Message----- > > From: Jiwoong Lee [mailto:porce@ktf.co.kr] > > Sent: Wednesday, May 30, 2001 2:06 AM > > To: mobile-ip@sunroof.eng.sun.com > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] MN's packet reception > > > > > > All > > > > In addtion to the original mail, I suggest to remove the last > > subordinate > > clause (*) starting with "as if.." of the below paragraph in > > MobileIPv6-13, > > because > > > > [1] Generic Packet Tunneling in IPv6 spec does not state that kind of > > statement and > > [2] the MN's BU condition (#) seems to be outof accord with > > (*), perhaps > > from the view point of implementation. > > > > comment please. > > > > Jiwoong > > > > > > > > > > For packets received by either the first or last of these three > > methods, the mobile node SHOULD send a Binding Update to > > the original > > sender of the packet, as described in Section 10.8, subject to the > > rate limiting defined in Section 10.11. The mobile node SHOULD > > also process the received packet in the manner defined for IPv6 > > encapsulation [4], which will result in the encapsulated (inner) > > packet being processed normally by upper-layer protocols within the > > mobile node, (*)as if it had been addressed (only) to the > > mobile node's > > home address. > > > > and > > > > In addition, when a mobile node receives a packet for which the > > mobile node can deduce that the original sender of the packet has > > no Binding Cache entry for the mobile node, or for which the mobile > > node can deduce that the original sender of the packet has an > > out-of-date care-of address for the mobile node in its > > Binding Cache, > > the mobile node SHOULD return a Binding Update to the sender giving > > its current care-of address (subject to the rate limiting defined > > in Section 10.11). In particular, the mobile node SHOULD return a > > Binding Update in response to receiving a packet that meets all of > > the following tests: > > > > (#) - The packet was tunneled using IPv6 encapsulation. > > ... > > > > > > > > > > ----- Original Message ----- > > From: "Jiwoong Lee" > > To: > > Sent: Tuesday, May 29, 2001 9:44 AM > > Subject: [mobile-ip] MN's packet reception > > > > > > > All, > > > > > > Becasue CN's requirement to use Binding Cache when it sends > > > a packet to MN is "SHOULD", the corresponding possibilities > > > in which a MN receives a packet while away from home also > > > should be described legitimately. > > > > > > A MN MAY receive a packet > > > addressed to its home address, which is sent by a CN that DOES > > > have a Binding Cache entry for the MN, if the CN does NOT like > > > to use Routing Header. > > > > > > Jiwoong > > > -- > > > > > > > > > 8.9. Sending Packets to a Mobile Node > > > > > > Before sending any packet, the sending node SHOULD examine its > > > Binding Cache for an entry for the destination address > > to which the > > > packet is being sent. If the sending node has a Binding > > Cache entry > > > for this address, the sending node SHOULD use a Routing header to > > > route the packet to this mobile node (the destination > > node) by way > > > of the care-of address in the binding recorded in that > > Binding Cache > > > entry. ... > > > > > > > > > 10.3. Receiving Packets While Away from Home > > > > > > While away from home, a mobile node will receive packets > > addressed to > > > its home address, by one of three methods: > > > > > > - Packets sent by a correspondent node that does not have a > > > Binding Cache entry for the mobile node, will be sent by the > > > correspondent node in the same way as any normal IP > > packet. Such > > > packets will then be intercepted by the mobile > > node's home agent, > > > encapsulated using IPv6 encapsulation [4], and > > tunneled to the > > > mobile node's primary care-of address. ... > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 09:02:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51G1Pv14821 for ipng-dist; Fri, 1 Jun 2001 09:01:26 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51G1Me14814 for ; Fri, 1 Jun 2001 09:01:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02829 for ; Fri, 1 Jun 2001 09:01:29 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA20755 for ; Fri, 1 Jun 2001 10:01:28 -0600 (MDT) Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Jun 2001 09:00:26 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 1 Jun 2001 09:00:38 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 1 Jun 2001 09:00:05 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Jun 2001 08:59:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Date: Fri, 1 Jun 2001 08:59:13 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "Default Address Selection for IPv6" Thread-Index: AcDqMsXK+MuuqcirSwKp3X9HM81uLgAgGkFg From: "Christian Huitema" To: "Francis Dupont" , "Bob Hinden" Cc: X-OriginalArrivalTime: 01 Jun 2001 15:59:14.0242 (UTC) FILETIME=[CDFE6220:01C0EAB3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f51G1Me14815 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe that Francis has a point when it comes to must vs. should or may. The current document is based on theoretical analysis rather than field experience, and there is no telling what we will learn in the next two years. As a rule, I believe that this document should never use the clause "must", and restrict itself to the milder should. In short, if there is any use for such a document, it should be some kind of a safe harbor approach, as in, "if you do this, we believe you won't cause much problems to the network, but if you know better feel free to innovate." Note that the fledging nature of IPv6 is actually an argument for standard track, since it will automatically trigger a revision mechanism in 6 month to 2 years, when we have to progress the status of this document. If we have a choice, it is not between proposed standard and informational, but rather between proposed standard and experimental. The latter would suit me just fine. -- Christian Huitema > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Thursday, May 31, 2001 5:33 PM > To: Bob Hinden > Cc: ipng@sunroof.eng.sun.com > Subject: Re: W.G. Last Call on "Default Address Selection for IPv6" > > I strongly object against the standard track status for this document > because this will close the door: > - research won't be done in order to find alternate/better solution > - implementors will have to implement exactly the mechasnims described > in the document or they won't be conformant. > The first point is a known drawback for standards. My concern is more > the second point, I understand we have to restraint freedom for getting > more interoperability but in this case we are going too far! > Some choices are still arguable, in particular in defaults, and these > will become standards so even we believe they are not good we will be > stuck with them. > These concerns have already slowed down the document and can become > critical when it will go further in the standard track. Common sense > rules ("MUSTs") should be in a different document than some detailed > mechanisms ("SHOULD/MAYs"). > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 09:14:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51GDVr14867 for ipng-dist; Fri, 1 Jun 2001 09:13:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51GDRe14860 for ; Fri, 1 Jun 2001 09:13:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06048 for ; Fri, 1 Jun 2001 09:13:35 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20772 for ; Fri, 1 Jun 2001 10:13:56 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 93FFD4B10 for ; Sat, 2 Jun 2001 01:13:25 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: DAD From: itojun@iijlab.net Date: Sat, 02 Jun 2001 01:13:25 +0900 Message-ID: <21931.991412005@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk at the interim meeting, there was a discussion on DAD (whether it is mandatory for all address, or we can do it just for link-local and omit for globals that share the same interface id). the original text is in the second bullet. i believe it is a bit confusing at best. the first sentence recommends (SHOULD) running DAD on every address you have, and then the following sentences say that you MAY omit it in certain conditions. my suggestion is to keep the first sentence and remove the exception sentences. it still leaves me a bit fuzzy feeling as DAD works only if everyone does it - so MUST sounds necessary to me for DAD to be useful. DAD does not always work anyways, due to network partition or ethernet chip initialization delays. so i'm okay with SHOULD on the first line. in was mentioned that TAHI test files "FAILED" if people omits DAD. first of all I would like to comment that we cannot take test result in binary form - when we see "FAILED", we need to diagnose result carefully. it may be an implementation choice, it may be TAHI's interpretation, whatever. when TAHI guys run their test on KAME stack, they give detailed interpretation on why they marked some test "FAIL" (if they have enough time). i guess the result "FAILED" for the DAD test is based on the following interpretation on "SHOULD" the first sentence. RFC2119 >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. itojun 5.4. Duplicate Address Detection Duplicate Address Detection is performed on unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases: - Duplicate Address Detection MUST NOT be performed on anycast addresses. - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. (snip) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 09:37:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51Gb5e14899 for ipng-dist; Fri, 1 Jun 2001 09:37:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51Gb1e14892 for ; Fri, 1 Jun 2001 09:37:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02912 for ; Fri, 1 Jun 2001 09:37:07 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04240 for ; Fri, 1 Jun 2001 10:37:34 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f51Gb3x10564 for ; Fri, 1 Jun 2001 19:37:03 +0300 Date: Fri, 1 Jun 2001 19:37:03 +0300 (EEST) From: Pekka Savola To: Subject: Re: DAD (in case of partitioning) In-Reply-To: <21931.991412005@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 2 Jun 2001 itojun@iijlab.net wrote: > at the interim meeting, there was a discussion on DAD (whether > it is mandatory for all address, or we can do it just for link-local > and omit for globals that share the same interface id). > > the original text is in the second bullet. i believe it is a bit > confusing at best. the first sentence recommends (SHOULD) > running DAD on every address you have, and then the following sentences > say that you MAY omit it in certain conditions. my suggestion is to > keep the first sentence and remove the exception sentences. > > it still leaves me a bit fuzzy feeling as DAD works only if everyone > does it - so MUST sounds necessary to me for DAD to be useful. > DAD does not always work anyways, due to network partition or ethernet > chip initialization delays. so i'm okay with SHOULD on the first line. [snip rest] The partitioning reminds me of a fact I've been meaning to ask opinions about. If a link was partitioned when two hosts did DAD, and the network heals up, what happens? Is there any way to recover from the situation? Are the both nodes screwed until either interface is brought up and down, enabling DAD? Which brings me to an idea: some implementations (routers, usually) have knowledge of link status (cable is/is not plugged in, is broken etc.). For these, would it make sense to defer DAD until link goes up and keep the address tentative until then? If a lot of implementations did this, the consequences of broken linkcould be smaller. Nodes have no way of knowing if network was partitioned upstream, of course. Also, it could be possible to redo DAD after link status cycled, but this could add too much traffic to the network and might open a door for easier address stealing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 10:03:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51H1kB14931 for ipng-dist; Fri, 1 Jun 2001 10:01:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51H1fe14924 for ; Fri, 1 Jun 2001 10:01:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09307 for ; Fri, 1 Jun 2001 10:01:49 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11029 for ; Fri, 1 Jun 2001 11:01:47 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f51H1eF15682; Fri, 1 Jun 2001 19:01:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA22692; Fri, 1 Jun 2001 19:01:40 +0200 (MET DST) Received: from localhost (localhost [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.1/8.11.1) with ESMTP id f51H1dA73496; Fri, 1 Jun 2001 19:01:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106011701.f51H1dA73496@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: DAD (in case of partitioning) In-reply-to: Your message of Fri, 01 Jun 2001 19:37:03 +0300. Date: Fri, 01 Jun 2001 19:01:39 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If a link was partitioned when two hosts did DAD, and the network heals up, what happens? Is there any way to recover from the situation? Are the both nodes screwed until either interface is brought up and down, enabling DAD? => the situation is not so simple because a common case (in wireless networks) is partial connectivity (and of course this can be highly dynamic). Regards Francis.Dupont@enst-bretagne.fr PS: as I have said yesterday I believe that DID (ie. your proposal) is both better (ie. catch more cases) and simpler than current DAD. But DAD is a DS so it will be hard to change/improve it... PPS: in the real word DID/DAD will detect only mistakes in manual router configurations (this is what the past has shown, of course we don't (yet :-) know the future and privacy stuff can change this). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 10:28:22 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51HRNG14992 for ipng-dist; Fri, 1 Jun 2001 10:27:23 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51HRLe14985 for ; Fri, 1 Jun 2001 10:27:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f51HNa402387 for ipng@sunroof.eng.sun.com; Fri, 1 Jun 2001 10:23:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f4VHAte13085 for ; Thu, 31 May 2001 10:10:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05323 for ; Thu, 31 May 2001 10:11:03 -0700 (PDT) Received: from mansoun.ipv6.inrialpes.fr (mansoun.inrialpes.fr [194.199.31.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15948 for ; Thu, 31 May 2001 10:11:02 -0700 (PDT) Received: from wells by mansoun.ipv6.inrialpes.fr with local (Exim 3.22 #1 (Debian)) id 155Vy1-0002Eh-00 for ; Thu, 31 May 2001 19:10:37 +0200 Date: Thu, 31 May 2001 19:10:37 +0200 From: John Wells To: ipng@sunroof.eng.sun.com Subject: Address proximity gauging Message-ID: <20010531191037.B8497@mansoun.ipv6.inrialpes.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4zI0WCX1RcnW9Hbu" Content-Disposition: inline User-Agent: Mutt/1.3.15i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --4zI0WCX1RcnW9Hbu Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello all, I'm in a bit of a quandary. Given an correspondant address, and an array of servers, how do I choose the server the closest to the correspondant ? = All of this is with IPv6. The only thing I can think of is longest prefix matching, and this is sure to work for prefixes of /48 and /64 (i.e. given matches at those lengths, one would be sure that the server is within the s= ame site and subnet respectively), but less than that it seems it's anything go= es. For example, at INRIA we have a /41 shared between sites scattered about France: near Paris, at Grenoble, and near Nice for example. Does anyone have any ideas about how to determine the proximity of two addresses? Any ideas are welcome. Thanks, John Wells --=20 John WELLS INRIA Rh=F4ne-Alpes, Plan=E8te Project - ENSIMAG 3A/T=E9l=E9comm et R=E9sea= ux Virginia Tech Networking and Visualization Lab PGP Public key: http://www.inrialpes.fr/planete/people/wells/pgpkey.txt --4zI0WCX1RcnW9Hbu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: Per informazioni si veda http://www.gnupg.org iD8DBQE7FnsNtvPFKAfa3SIRAladAJ9MFMiJKd9sEmWLFiUo5TWwF/AX1ACZAa2u 4XuNHaBtiEwjiFr4khro+qo= =kzlF -----END PGP SIGNATURE----- --4zI0WCX1RcnW9Hbu-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 10:28:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51HS3Y15001 for ipng-dist; Fri, 1 Jun 2001 10:28:03 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51HS1e14994 for ; Fri, 1 Jun 2001 10:28:01 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f51HOGW02417 for ipng@sunroof.eng.sun.com; Fri, 1 Jun 2001 10:24:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51CvAe14470 for ; Fri, 1 Jun 2001 05:57:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03817 for ; Fri, 1 Jun 2001 05:57:17 -0700 (PDT) Received: from relay.de.kpnqwest.net (relay.de.kpnqwest.net [193.141.40.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29021 for ; Fri, 1 Jun 2001 05:57:16 -0700 (PDT) Received: from mailcheck.de.kpnqwest.net (mailcheck.de.kpnqwest.net [193.141.42.213]) by relay.de.kpnqwest.net (Postfix) with ESMTP id 385CA91A9; Fri, 1 Jun 2001 14:57:15 +0200 (MET DST) Received: from relayi.xlink.net (localhost [127.0.0.1]) by mailcheck.de.kpnqwest.net (Postfix) with ESMTP id 637AA24606; Fri, 1 Jun 2001 14:57:13 +0200 (MEST) Received: from user6.xlink.rfc1918 (user6.xlink.rfc1918 [172.23.252.102]) by relayi.xlink.net (Postfix) with ESMTP id E71CE9F256; Fri, 1 Jun 2001 14:57:11 +0200 (MET DST) Received: (from zeidler@localhost) by user6.xlink.rfc1918 (8.9.3+Sun/8.8.5) id OAA11959; Fri, 1 Jun 2001 14:57:08 +0200 (MEST) Message-ID: <20010601145708.A11822@kpnqwest.de> Date: Fri, 1 Jun 2001 14:57:08 +0200 From: Petra Zeidler To: JIM FLEMING Cc: Emanuel Moreira , ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org Subject: Re: DNS Server Mail-Followup-To: JIM FLEMING , Emanuel Moreira , ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org References: <20010531183329.4137.qmail@purina.chek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from JIM FLEMING on Thu, May 31, 2001 at 02:29:05PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Thus wrote JIM FLEMING (jfleming@anet.com): > AAAA Records in DNS > > 2002::0000: ? Is that config for something doing v4-to-v6-translation? Thus wrote Emanuel Moreira (emanramor@portugalmail.com): >> >> >> I want to configure a DNS server in a IPv6 network and I want to make >> query's from my Windows 2000 host. How can I configure a route to the DNS >> Server in this host or is not like in IPv4? >> Or else should the DNS send some advertisements to the hosts? Maybe I'm entirely missing the point, but DNS servers usually get entered in the corresponding section of a hosts' network config, e.g. resolv.conf on a Unix host. If the Windows 2000 does IPv6 its DNS panel should take the nameservers' address in v6 in the 'servers' list. And that's usually nothing at all to do with routing. [*] ;-) kind regards, Petra Zeidler [*] though it helps performance a lot if the client can actually reach the nameserver it wants to use ;-)) -- [A] KPNQwest Germany * Emmy-Noether-Strasse 9 * D-76131 Karlsruhe [T] +49 721 9652 215 [F] +49 721 9652 171 [E] petra.zeidler@kpnqwest.com [I] www.kpnqwest.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 10:29:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51HSag15019 for ipng-dist; Fri, 1 Jun 2001 10:28:36 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51HSYe15012 for ; Fri, 1 Jun 2001 10:28:34 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f51HOnv02447 for ipng@sunroof.eng.sun.com; Fri, 1 Jun 2001 10:24:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51D5Ve14574 for ; Fri, 1 Jun 2001 06:05:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04907 for ; Fri, 1 Jun 2001 06:05:39 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA28891 for ; Fri, 1 Jun 2001 07:06:06 -0600 (MDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA00947 for ; Fri, 1 Jun 2001 06:05:33 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA10343 for ; Fri, 1 Jun 2001 06:05:32 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r3.mot.com with ESMTP for ipng@sunroof.eng.sun.com; Fri, 1 Jun 2001 08:05:29 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id PAA08793 for ipng@sunroof.eng.sun.com.DELIVER; Fri, 1 Jun 2001 15:05:27 +0200 (METDST) Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id PAA08763 for ; Fri, 1 Jun 2001 15:05:23 +0200 (METDST) To: ipng@sunroof.eng.sun.com Subject: Q: minutes of joint 3GPP/IETF ipng From: Alexandru Petrescu Date: 01 Jun 2001 15:05:22 +0200 Message-Id: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.103 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'm looking for minutes of the discussions that took place during the May 30th joint meeting. I have the agenda and a bunch of slides but I wish I had minutes specifically on answers to previously circulated questions from the IPv6 Directorate (by voice of T. Narten). Thanks in advance, Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 10:35:52 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51HZLB15154 for ipng-dist; Fri, 1 Jun 2001 10:35:21 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51HZGe15147 for ; Fri, 1 Jun 2001 10:35:17 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id TAA16367; Fri, 1 Jun 2001 19:35:16 +0200 (MET DST) Date: Fri, 1 Jun 2001 19:34:40 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" To: Christian Huitema Cc: Francis Dupont , Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, Which MUST in the spec do you feel is inappropriate? There are only 6 MUST/MUST NOT and as far as I can tell they specify constraints that effect interoperability or the protocols actually working (e.g. not letting a link local addresses for link A be used on as a source address for packets sent on link B). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 11:00:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51Hxhb15235 for ipng-dist; Fri, 1 Jun 2001 10:59:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51Hxde15228 for ; Fri, 1 Jun 2001 10:59:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24565 for ; Fri, 1 Jun 2001 10:59:41 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19481 for ; Fri, 1 Jun 2001 12:00:03 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0E3844B0B for ; Sat, 2 Jun 2001 02:59:26 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: DNS query over anycast From: itojun@iijlab.net Date: Sat, 02 Jun 2001 02:59:26 +0900 Message-ID: <22932.991418366@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk there was a question regarding to DNS response against this kind of query: (src=x dst=anycast) needs to have anycast source address or not. from RFC2181, it is legal to use non-anycast address for response. and for the resolver side (implementation issue): - BIND8 resolver checks source address match by default, but can easily turned off by RES_INSECURE2 flag bit on res.options. - MS windows DNS resolver does not (correct me if I'm wrong about this). itojun --- 4.1. UDP Source Address Selection To avoid these problems, servers when responding to queries using UDP must cause the reply to be sent with the source address field in the IP header set to the address that was in the destination address field of the IP header of the packet containing the query causing the response. If this would cause the response to be sent from an IP <- address that is not permitted for this purpose, then the response may <- be sent from any legal IP address allocated to the server. That <- address should be chosen to maximise the possibility that the client will be able to use it for further queries. Servers configured in such a way that not all their addresses are equally reachable from all potential clients need take particular care when responding to queries sent to anycast, multicast, or similar, addresses. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 11:04:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51I3fj15279 for ipng-dist; Fri, 1 Jun 2001 11:03:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51I3Ce15259; Fri, 1 Jun 2001 11:03:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25699; Fri, 1 Jun 2001 11:03:19 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21570; Fri, 1 Jun 2001 12:03:44 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f51I38j10963; Fri, 1 Jun 2001 21:03:08 +0300 Date: Fri, 1 Jun 2001 21:03:07 +0300 (EEST) From: Pekka Savola To: JIM FLEMING cc: , Subject: Re: (ngtrans) RE: IPv6 @ interim meeting In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 30 May 2001, JIM FLEMING wrote: > Anyone with access to the IPv4 Internet > has an IPv8-compatible prefix for FREE. > > 2002::0000: Would someone please ban Jim Fleming from the lists? I've yet to see a message from him that isn't pure and complete _crap_ or a troll. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 11:22:31 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51ILh515382 for ipng-dist; Fri, 1 Jun 2001 11:21:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51ILae15366; Fri, 1 Jun 2001 11:21:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10483; Fri, 1 Jun 2001 11:21:43 -0700 (PDT) Received: from hypnos.cps.intel.com (hypnos.cps.intel.com [192.198.165.17]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06128; Fri, 1 Jun 2001 11:21:39 -0700 (PDT) Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201]) by hypnos.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id SAA15746; Fri, 1 Jun 2001 18:21:14 GMT Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 01 Jun 2001 18:21:08 0000 (GMT) Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Jun 2001 11:21:06 -0700 Message-ID: <7DAA70BEB463D211AC3E00A0C96B7AB2073D7932@orsmsx41.jf.intel.com> From: "Strahm, Bill" To: "'Pekka Savola'" , JIM FLEMING Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: RE: (ngtrans) RE: IPv6 @ interim meeting Date: Fri, 1 Jun 2001 11:20:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So you are suggesting that the IETF goes to a closed model where people have to be "approved" to join mailing list discussions ??? I DO NOT believe this is the IETF way and I hope nothing is done, if you don't like this persons posts, feel free to create a procmail et.al. rule to automatically delete his messages, but DO NOT do that for me. Bill -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Friday, June 01, 2001 11:03 AM To: JIM FLEMING Cc: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) RE: IPv6 @ interim meeting On Wed, 30 May 2001, JIM FLEMING wrote: > Anyone with access to the IPv4 Internet > has an IPv8-compatible prefix for FREE. > > 2002::0000: Would someone please ban Jim Fleming from the lists? I've yet to see a message from him that isn't pure and complete _crap_ or a troll. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 11:24:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51IO5V15400 for ipng-dist; Fri, 1 Jun 2001 11:24:05 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51IO0e15393 for ; Fri, 1 Jun 2001 11:24:00 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id UAA19601; Fri, 1 Jun 2001 20:23:57 +0200 (MET DST) Date: Fri, 1 Jun 2001 20:23:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: DAD (in case of partitioning) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If a link was partitioned when two hosts did DAD, and the network heals > up, what happens? Is there any way to recover from the situation? > Are the both nodes screwed until either interface is brought up and down, > enabling DAD? Yes, and you can't easily tell that you're hosed. At some point in time we might have discussed having 3rd parties doing address resolution detect when a multicast NS results in two NAs containing different addresses and sound the alarm. But I think the use fo proxy NAs (e.g. for mobile IP on the home link) makes this type of 3rd party discovery tricky. > Which brings me to an idea: some implementations (routers, usually) have > knowledge of link status (cable is/is not plugged in, is broken etc.). > For these, would it make sense to defer DAD until link goes up and keep > the address tentative until then? If a lot of implementations did this, > the consequences of broken linkcould be smaller. Nodes have no way of > knowing if network was partitioned upstream, of course. That only helps at the attachment to the link - doesn't help e.g. if two Ethernet hubs/switches loose the link between them. > Also, it could be possible to redo DAD after link status cycled, but this > could add too much traffic to the network and might open a door for easier > address stealing. Sure, an implementation can do DAD once the link is up for links that have a notion of being up vs. down. But that doesn't help with internal partitions on the link. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 11:37:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51IaL615500 for ipng-dist; Fri, 1 Jun 2001 11:36:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51IZke15476; Fri, 1 Jun 2001 11:35:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12859; Fri, 1 Jun 2001 11:35:53 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09789; Fri, 1 Jun 2001 12:36:19 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f51IZap11169; Fri, 1 Jun 2001 21:35:36 +0300 Date: Fri, 1 Jun 2001 21:35:36 +0300 (EEST) From: Pekka Savola To: "Strahm, Bill" cc: JIM FLEMING , , Subject: RE: (ngtrans) RE: IPv6 @ interim meeting In-Reply-To: <7DAA70BEB463D211AC3E00A0C96B7AB2073D7932@orsmsx41.jf.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Jun 2001, Strahm, Bill wrote: > So you are suggesting that the IETF goes to a closed model where people have > to be "approved" to join mailing list discussions ??? > > I DO NOT believe this is the IETF way and I hope nothing is done, if you > don't like this persons posts, feel free to create a procmail et.al. rule to > automatically delete his messages, but DO NOT do that for me. No; what I'm suggesting is that posting by this one person who seems to get odd pleasure from trolling the lists and spewing crap can be disapproved. Approval by default unless _clearly_ shown otherwise is of course a MUST. I'm not the only one disturbed about this, but I can live with this if need be; this would save all the other people the bother. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 11:50:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51InDp15555 for ipng-dist; Fri, 1 Jun 2001 11:49:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51In9e15548 for ; Fri, 1 Jun 2001 11:49:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16654 for ; Fri, 1 Jun 2001 11:49:16 -0700 (PDT) Received: from hygro.adsl.duke.edu ([131.107.37.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08521 for ; Fri, 1 Jun 2001 12:49:15 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f51Ikdm01430; Fri, 1 Jun 2001 14:46:39 -0400 Message-Id: <200106011846.f51Ikdm01430@hygro.adsl.duke.edu> To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: DAD In-Reply-To: Message from itojun@iijlab.net of "Sat, 02 Jun 2001 01:13:25 +0900." <21931.991412005@itojun.org> Date: Fri, 01 Jun 2001 14:46:39 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is a suggestion for how to plug the main vulnerabilities that were discussed in the meeting. Problem (as I understand it): the main issue is that there are some (non-link local scope) addresses that may be assigned to an interface (e.g., manually configured, temporary addresses, DHCP assigned, etc.), but for which there is no corresponding link-local address using the same interface identifier. The stateless addrconf document (RFC 2462) says that a node can skip DAD for global (and site local) scope addresses generated from the same interface ID as the link-local address. This opens up a potential hole where a node (doing normal addrconf) has run DAD on the link-local address, but has not yet configured a global-scope address using the same interface identifier. Then, some other node (e.g., via DHCP, a temporary address etc.) chooses the same interface identifier and creates such an address, runs DAD successfully (since no other node is currently using that address), and then assigns the address to its interface. Later, the first node (which is running normal addrconf) also generates the address, but skips DAD, and now there are two nodes using the same address. Oops. Proposal: update specs to require that nodes MUST run DAD on all addresses for which the interface identifier is NOT globally unique (per the setting of the 'u' bit in interface identifier). DAD can be skipped on addresses that contain IEEE EUI-64-derived interface identifiers (and for which DAD has already been run on the corresponding link-local address). This means: still no need to run DAD on global addresses when doing normal addrconf, provided the interface identifier comes from an IEEE identifier. But one would have to run DAD for links with randomly generated identifiers (e.g., some PPP links). One would also still need to run DAD for temporary addresses. For DHCP addresses, we'd need to make sure that the server sets the 'u' bit properly, and clients would need to run DAD if the 'u' bit indicated locally unique only. Does this solve the underlying problem in an acceptable fashion? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 15:17:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f51MH7415776 for ipng-dist; Fri, 1 Jun 2001 15:17:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f51MH3e15769 for ; Fri, 1 Jun 2001 15:17:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03305 for ; Fri, 1 Jun 2001 15:17:10 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA29484 for ; Fri, 1 Jun 2001 16:17:09 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 01 Jun 2001 14:53:13 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 1 Jun 2001 14:53:25 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 1 Jun 2001 14:53:23 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 1 Jun 2001 14:52:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Date: Fri, 1 Jun 2001 14:52:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "Default Address Selection for IPv6" Thread-Index: AcDqwTPGjZ3ipOoRRAie8wQ6xysriwAIzH+A From: "Christian Huitema" To: "Erik Nordmark" Cc: "Francis Dupont" , "Bob Hinden" , X-OriginalArrivalTime: 01 Jun 2001 21:52:31.0254 (UTC) FILETIME=[2865BB60:01C0EAE5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f51MH4e15770 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In fact, there is only one debatable MUST that remains -- at the end of section 4, the reference to "Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability." Rule 2 essentially states that one should pick the lowest scope that it still higher or equal than the destination. There are plenty of reasons to override that, e.g. different performance of different interfaces, etc. A SHOULD would be in order. -- Christian Huitema > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Friday, June 01, 2001 10:35 AM > To: Christian Huitema > Cc: Francis Dupont; Bob Hinden; ipng@sunroof.eng.sun.com > Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" > > Christian, > > Which MUST in the spec do you feel is inappropriate? > > There are only 6 MUST/MUST NOT and as far as I can tell > they specify constraints that effect interoperability or the protocols > actually working (e.g. not letting a link local addresses for > link A be used on as a source address for packets sent on link B). > > Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 18:29:04 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f521SPb16034 for ipng-dist; Fri, 1 Jun 2001 18:28:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f521SLe16027 for ; Fri, 1 Jun 2001 18:28:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12472 for ; Fri, 1 Jun 2001 18:28:29 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA00095 for ; Fri, 1 Jun 2001 19:28:57 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id EAA22580; Sat, 2 Jun 2001 04:44:38 +0300 Date: Sat, 2 Jun 2001 04:44:38 +0300 Message-Id: <200106020144.EAA22580@burp.tkv.asdf.org> From: Markku Savela To: narten@raleigh.ibm.com CC: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-reply-to: <200106011846.f51Ikdm01430@hygro.adsl.duke.edu> (message from Thomas Narten on Fri, 01 Jun 2001 14:46:39 -0400) Subject: Re: DAD References: <200106011846.f51Ikdm01430@hygro.adsl.duke.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Proposal: update specs to require that nodes MUST run DAD on all > addresses for which the interface identifier is NOT globally unique > (per the setting of the 'u' bit in interface identifier). DAD can be > skipped on addresses that contain IEEE EUI-64-derived interface > identifiers (and for which DAD has already been run on the > corresponding link-local address). I would prefer the IPv6 address architecture leaves it open for future address formats which do not use IEEE EUI-64 ID-format, and still have all the machinery of Neighbor Discovery and ADDRCONF available. Designs which force the stack to dig into insides of any id part are very unappealing to me. Address is n-bit prefix 128-n bit id, and as far as my current implementation goes, the link layer may specify *any* n (0..128) to be used [to prevent obvious replies, I do admit that the kinky values of n=0 or n=128 may not quite work]. ..although, one might consider a point-to-point link without link layer addresses as "n=128". -- Markku Savela -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 1 18:30:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f521Tvv16052 for ipng-dist; Fri, 1 Jun 2001 18:29:57 -0700 (PDT) Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f521Tre16045 for ; Fri, 1 Jun 2001 18:29:54 -0700 (PDT) Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.176.81]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12524 for ; Fri, 1 Jun 2001 21:30:01 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.11.3+Sun/8.11.3) id f521U1J22319 for ipng@sunroof.eng; Fri, 1 Jun 2001 21:30:01 -0400 (EDT) Message-Id: <200106020130.f521U1J22319@kebe.east.sun.com> Subject: Test To: ipng@sunroof.eng.sun.com Date: Fri, 1 Jun 2001 21:30:01 -0400 (EDT) From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pardon my bandwidth, folks... Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 2 10:50:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f52Hnj416549 for ipng-dist; Sat, 2 Jun 2001 10:49:45 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f52Hnee16542 for ; Sat, 2 Jun 2001 10:49:41 -0700 (PDT) Received: from rouget.sun.com (dsl197-48.Eng.Sun.COM [129.146.197.48]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f52HnpQ390334 for ; Sat, 2 Jun 2001 10:49:51 -0700 (PDT) Message-Id: <5.1.0.14.0.20010602102922.03b65950@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Jun 2001 10:54:58 -0700 To: From: Alain Durand Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a comment on the "last resort" rule, that say, everything being equal, perform longest prefix match an all bits from 1 to 128. I would like to suggest to limit the match to the first 64 bits. The danger of doing match on all the bits is to have unpredictable behavior and difficult to diagnose problem. Let say that you have to hosts A & B on the same IPv6 subnet, and both host have another direct connection (e.g. serial link or another ethernet link at a lower speed) for back-up Let say that all addresses have global -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 2 11:08:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f52I7n916582 for ipng-dist; Sat, 2 Jun 2001 11:07:49 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f52I7je16575 for ; Sat, 2 Jun 2001 11:07:45 -0700 (PDT) Received: from rouget.sun.com (dsl197-48.Eng.Sun.COM [129.146.197.48]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f52I7rQ391329 for ; Sat, 2 Jun 2001 11:07:53 -0700 (PDT) Message-Id: <5.1.0.14.0.20010602105533.00af6430@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Jun 2001 11:13:02 -0700 To: ipng@sunroof.eng.sun.com From: Alain Durand Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Sorry for the previous incomplete message) I have a comment on the "last resort" rule, that say, everything being equal, perform longest prefix match an all bits from 1 to 128. I would like to suggest to limit the match to the first 64 bits. The danger of doing match on all the bits is to have unpredictable behavior and difficult to diagnose problem. Let say that you have to hosts A & B on the same IPv6 subnet, and both host have another direct connection (e.g. serial link or another ethernet link at a lower speed) for back-up Let say that all addresses have global scope. All things being equal, A and B will resort to longest prefix match. Both prefix being /64, the algorithm will try to match the other bits. and then... the choice of the selected link is unpredictable. So depending on the brand and date of make of the ethernet NIC, communication between A and B will either take the normal link or the backup link. My take is that this unpredictability will lead to very difficult to diagnose problem. I would like to suggest to restrict longest prefix match to /64 and,if all things are still equal, apply a predictable algorithm to choose which address to select. example: always take the prefix with the highest value. Or best, apply local knowledge when available, like route metric, interface bandwidth,... Then, all machines on the same subnet will behave the same way and network administrator will have less trouble with this. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 2 11:18:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f52IIJ316608 for ipng-dist; Sat, 2 Jun 2001 11:18:19 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f52IIFe16601 for ; Sat, 2 Jun 2001 11:18:15 -0700 (PDT) Received: from rouget.sun.com (dsl197-48.Eng.Sun.COM [129.146.197.48]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f52IINQ392016; Sat, 2 Jun 2001 11:18:23 -0700 (PDT) Message-Id: <5.1.0.14.0.20010602111404.03c9d950@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 02 Jun 2001 11:23:32 -0700 To: From: Alain Durand Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:59 AM 6/1/2001 -0700, Christian Huitema wrote: >I believe that Francis has a point when it comes to must vs. should or >may. The current document is based on theoretical analysis rather than >field experience, and there is no telling what we will learn in the next >two years. I have some sympathy for this argument. This is not so much a problem now to go to PS, but can be an issue to go to DS. I have a suggestion here. Split the document in two parts. One describe the different rules and algorithms, explain how to compare addresses based on values taken from various tables, and is published on the standard track. The other one give the actual values in those tables. This second document is published as a BCP. This way, it will be much easier to change the expected behavior if we realized, two years from now, that some of the choices should be reversed. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 00:22:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f537LQJ17033 for ipng-dist; Sun, 3 Jun 2001 00:21:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f537LMe17026 for ; Sun, 3 Jun 2001 00:21:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19281 for ; Sun, 3 Jun 2001 00:21:29 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09947 for ; Sun, 3 Jun 2001 01:21:56 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f537Jav63818; Sun, 3 Jun 2001 17:19:41 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200106030719.f537Jav63818@drugs.dv.isc.org> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: DNS query over anycast In-reply-to: Your message of "Sat, 02 Jun 2001 02:59:26 +0900." <22932.991418366@itojun.org> Date: Sun, 03 Jun 2001 17:19:36 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > there was a question regarding to DNS response against this kind of > query: > (src=x dst=anycast) > needs to have anycast source address or not. I would be setting the anycast address as the source address of the reply. > > from RFC2181, it is legal to use non-anycast address for response. This part was written for broadcast and multicast addresses. > > and for the resolver side (implementation issue): > - BIND8 resolver checks source address match by default, but can easily > turned off by RES_INSECURE2 flag bit on res.options. > - MS windows DNS resolver does not (correct me if I'm wrong about this) > . > > itojun > > > --- > 4.1. UDP Source Address Selection > > To avoid these problems, servers when responding to queries using UDP > must cause the reply to be sent with the source address field in the > IP header set to the address that was in the destination address > field of the IP header of the packet containing the query causing the > response. If this would cause the response to be sent from an IP <- > address that is not permitted for this purpose, then the response may <- > be sent from any legal IP address allocated to the server. That <- > address should be chosen to maximise the possibility that the client > will be able to use it for further queries. Servers configured in > such a way that not all their addresses are equally reachable from > all potential clients need take particular care when responding to > queries sent to anycast, multicast, or similar, addresses. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 00:24:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f537OIw17055 for ipng-dist; Sun, 3 Jun 2001 00:24:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f537ODe17048 for ; Sun, 3 Jun 2001 00:24:13 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06252 for ; Sun, 3 Jun 2001 00:24:21 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26159 for ; Sun, 3 Jun 2001 00:24:20 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id D9F104B10; Sun, 3 Jun 2001 16:24:16 +0900 (JST) To: Mark.Andrews@nominum.com Cc: ipng@sunroof.eng.sun.com In-reply-to: Mark.Andrews's message of Sun, 03 Jun 2001 17:19:36 +1000. <200106030719.f537Jav63818@drugs.dv.isc.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DNS query over anycast From: itojun@iijlab.net Date: Sun, 03 Jun 2001 16:24:16 +0900 Message-ID: <6713.991553056@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> there was a question regarding to DNS response against this kind of >> query: >> (src=x dst=anycast) >> needs to have anycast source address or not. > I would be setting the anycast address as the source address of the > reply. under limitation declared in RFC2373, we cannot. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 03:05:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f53A59K17165 for ipng-dist; Sun, 3 Jun 2001 03:05:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f53A55e17158 for ; Sun, 3 Jun 2001 03:05:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12876 for ; Sun, 3 Jun 2001 03:05:07 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15886 for ; Sun, 3 Jun 2001 04:05:05 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f53A4iM02380; Sun, 3 Jun 2001 17:04:44 +0700 (ICT) From: Robert Elz To: Mark.Andrews@nominum.com cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast In-Reply-To: <200106030719.f537Jav63818@drugs.dv.isc.org> References: <200106030719.f537Jav63818@drugs.dv.isc.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 03 Jun 2001 17:04:44 +0700 Message-ID: <2378.991562684@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 03 Jun 2001 17:19:36 +1000 From: Mark.Andrews@nominum.com Message-ID: <200106030719.f537Jav63818@drugs.dv.isc.org> | This part was written for broadcast and multicast addresses. It was written for any address from which it was not legal to send a reply (including 0.0.0.0 etc). If that includes anycast addresses, then it includes anycast addresses... It is simply pointless to have a spec requiring something to be done which some other spec says one must not do - all that leads to is duelling RFCs. So, when it is legal DNS servers must respond from the address to which the packet was sent - any other time, they have to use some address that is in fact legal to use. And I know, that since an anycast address looks syntactically just like a unicast address, this can be tricky at times... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 15:50:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f53Mna017933 for ipng-dist; Sun, 3 Jun 2001 15:49:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f53MnXe17926 for ; Sun, 3 Jun 2001 15:49:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28076 for ; Sun, 3 Jun 2001 15:49:40 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA24948 for ; Sun, 3 Jun 2001 16:50:10 -0600 (MDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 03 Jun 2001 15:49:20 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Sun, 3 Jun 2001 15:49:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: Lose an AC adapter at Interim Meeting? Date: Sun, 3 Jun 2001 15:49:34 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Lose an AC adapter at Interim Meeting? thread-index: AcDsf3WSaGvOx/eQRyaq58bDTKlfXA== From: "Brian Zill" To: , X-OriginalArrivalTime: 03 Jun 2001 22:49:38.0469 (UTC) FILETIME=[7800BD50:01C0EC7F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f53MnXe17927 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I found an AC adapter while cleaning up the room after the meeting ended on Friday. If it is yours, please send me a detailed description of it to claim it. Hope everyone had a safe trip home, --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 17:50:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f540o1618103 for ipng-dist; Sun, 3 Jun 2001 17:50:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f540nve18096 for ; Sun, 3 Jun 2001 17:49:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05846 for ; Sun, 3 Jun 2001 17:50:05 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA03313 for ; Sun, 3 Jun 2001 18:50:32 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f540l4v67142; Mon, 4 Jun 2001 10:47:04 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200106040047.f540l4v67142@drugs.dv.isc.org> To: itojun@iijlab.net Cc: Mark.Andrews@nominum.com, ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: DNS query over anycast In-reply-to: Your message of "Sun, 03 Jun 2001 16:24:16 +0900." <6713.991553056@itojun.org> Date: Mon, 04 Jun 2001 10:47:04 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > >> there was a question regarding to DNS response against this kind of > >> query: > >> (src=x dst=anycast) > >> needs to have anycast source address or not. > > I would be setting the anycast address as the source address of the > > reply. > > under limitation declared in RFC2373, we cannot. Well this is all moot as anycast addresses are not allowed to be assigned to hosts and DNS service is host functionality. "There is little experience with widespread, arbitrary use of internet anycast addresses, and some known complications and hazards when using them in their full generality [ANYCST]. Until more experience has been gained and solutions agreed upon for those problems, the following restrictions are imposed on IPv6 anycast addresses: o An anycast address must not be used as the source address of an IPv6 packet. o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only." In the IPv4 world we are expecting the source address of the DNS reply to match the destination address in the anycast case. The restiction on source address is primarily driven by TCP and load balancing causing multiple anycast hosts to receive one TCP stream. Also how do you get experience that would break the above restiction without breaking the above restiction. Classic catch 22. To get around the truncation and tcp fallback we could have a EDNS option that specified a unicast address to use that is sent back with the truncated response. Or do we just send this EDNS response and force a switch to unicast regardless of TC. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 18:11:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f541B8f18145 for ipng-dist; Sun, 3 Jun 2001 18:11:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f541B3e18138 for ; Sun, 3 Jun 2001 18:11:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05111 for ; Sun, 3 Jun 2001 18:11:12 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA10400 for ; Sun, 3 Jun 2001 19:11:39 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 570357BB; Mon, 4 Jun 2001 10:10:54 +0900 (JST) To: Mark.Andrews@nominum.com Cc: ipng@sunroof.eng.sun.com In-reply-to: Mark.Andrews's message of Mon, 04 Jun 2001 10:47:04 +1000. <200106040047.f540l4v67142@drugs.dv.isc.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DNS query over anycast From: Jun-ichiro itojun Hagino Date: Mon, 04 Jun 2001 10:10:54 +0900 Message-Id: <20010604011054.570357BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well this is all moot as anycast addresses are not allowed to > be assigned to hosts and DNS service is host functionality. the condition "host cannot have anycast address" was introduced because, when RFC2373 was written, there seem to be no way for hosts to inject /128 routes to the site routing system. actually it is very easy to solve: - hosts with anycast address speak RIPng, OSPFv3 or whatever, and inject /128 route to the site routing system. - extension to MLD, draft-haberman-ipngwg-host-anycast-00.txt - configure a static route for anycast address (/128) onto the router adjacent to the anycast host. - run DNS server on a router (you can make a UNIX box a router, you know) the first bullet is very easy and can be tested with no protocol change. we have been using it quite a while. the condition "don't put anycast into source" was introduced because of tcp issues, as you've described. draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt describes it in full. > To get around the truncation and tcp fallback we could have > a EDNS option that specified a unicast address to use that > is sent back with the truncated response. Or do we just send > this EDNS response and force a switch to unicast regardless of > TC. yes, truncation and the fallback to TCP is a problem. here are a list of solutions i can think of on truncation/fallback issue: - clients should use EDNS0 and avoid most of the truncation cases. - TCP query should pick the destination address from the UDP reply. (possibility of hijack, of course) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 18:48:15 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f541l6s18192 for ipng-dist; Sun, 3 Jun 2001 18:47:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f541l2e18185 for ; Sun, 3 Jun 2001 18:47:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA07376 for ; Sun, 3 Jun 2001 18:47:10 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14583 for ; Sun, 3 Jun 2001 18:47:08 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156jSS-000FFq-00; Sun, 03 Jun 2001 18:47:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mark.Andrews@nominum.com Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast References: <6713.991553056@itojun.org> <200106040047.f540l4v67142@drugs.dv.isc.org> Message-Id: Date: Sun, 03 Jun 2001 18:47:04 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > "There is little experience with widespread, arbitrary use of internet > anycast addresses actually, there is a fair bit of experience with it. as far as i can tell, the base problem here is that folk who have had no experience with v4 anycast service deployment know in theory or in vitro that there can be problems in some circumstances, namely non-ephemeral tcp sessions finding themselves connected to the wrong host due to routing changes [0]. unfortunately, the result has been outlawing a whole bunch of stuff which can not exhibit this kind of problem, namely udp based anycast services, and outlawing tcp services which may not be as susceptable to the problem about which they seem to be worried. this is unfortunate as we have real services widely deployed in v4 anycast which will now be a pain in v6. yet another thorn we ourselves place in the side of real v6 deployment. randy --- [0] - in fact, in real deployment, long lived tcp to a v4 anycast seems more stable than even optimism would seem to warrant. research continues. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 18:54:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f541rlU18221 for ipng-dist; Sun, 3 Jun 2001 18:53:47 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f541rie18214 for ; Sun, 3 Jun 2001 18:53:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09467 for ; Sun, 3 Jun 2001 18:53:50 -0700 (PDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA23632 for ; Sun, 3 Jun 2001 19:54:21 -0600 (MDT) Received: from jim (ip-111-152-5.chicago-n.navipath.net [64.111.152.5]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id f541rfE251872; Sun, 3 Jun 2001 21:53:42 -0400 From: "JIM FLEMING" To: "Randy Bush" , Cc: , Subject: RE: DNS query over anycast Date: Sun, 3 Jun 2001 20:54:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What is "real v6 deployment" ? Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Randy Bush Sent: Sunday, June 03, 2001 8:47 PM To: Mark.Andrews@nominum.com Cc: itojun@iijlab.net; ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast > "There is little experience with widespread, arbitrary use of internet > anycast addresses actually, there is a fair bit of experience with it. as far as i can tell, the base problem here is that folk who have had no experience with v4 anycast service deployment know in theory or in vitro that there can be problems in some circumstances, namely non-ephemeral tcp sessions finding themselves connected to the wrong host due to routing changes [0]. unfortunately, the result has been outlawing a whole bunch of stuff which can not exhibit this kind of problem, namely udp based anycast services, and outlawing tcp services which may not be as susceptable to the problem about which they seem to be worried. this is unfortunate as we have real services widely deployed in v4 anycast which will now be a pain in v6. yet another thorn we ourselves place in the side of real v6 deployment. randy --- [0] - in fact, in real deployment, long lived tcp to a v4 anycast seems more stable than even optimism would seem to warrant. research continues. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 19:18:39 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f542I4f18279 for ipng-dist; Sun, 3 Jun 2001 19:18:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f542I0e18272 for ; Sun, 3 Jun 2001 19:18:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03169 for ; Sun, 3 Jun 2001 19:18:07 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA01991 for ; Sun, 3 Jun 2001 20:18:33 -0600 (MDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f542GAv67862; Mon, 4 Jun 2001 12:16:17 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200106040216.f542GAv67862@drugs.dv.isc.org> To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: DNS query over anycast In-reply-to: Your message of "Mon, 04 Jun 2001 10:10:54 +0900." <20010604011054.570357BB@starfruit.itojun.org> Date: Mon, 04 Jun 2001 12:16:10 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Well this is all moot as anycast addresses are not allowed to > > be assigned to hosts and DNS service is host functionality. > > the condition "host cannot have anycast address" was introduced > because, when RFC2373 was written, there seem to be no way for > hosts to inject /128 routes to the site routing system. actually it is > very easy to solve: > - hosts with anycast address speak RIPng, OSPFv3 or whatever, and > inject /128 route to the site routing system. > - extension to MLD, draft-haberman-ipngwg-host-anycast-00.txt > - configure a static route for anycast address (/128) onto the router > adjacent to the anycast host. > - run DNS server on a router (you can make a UNIX box a router, > you know) > the first bullet is very easy and can be tested with no protocol change > . > we have been using it quite a while. > > the condition "don't put anycast into source" was introduced because > of tcp issues, as you've described. > > draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt describes it in full. > > > To get around the truncation and tcp fallback we could have > > a EDNS option that specified a unicast address to use that > > is sent back with the truncated response. Or do we just send > > this EDNS response and force a switch to unicast regardless of > > TC. > > yes, truncation and the fallback to TCP is a problem. > here are a list of solutions i can think of on truncation/fallback > issue: > - clients should use EDNS0 and avoid most of the truncation cases. > - TCP query should pick the destination address from the UDP reply. > (possibility of hijack, of course) > I stand by my original answer as to the source address is the anycast address for DNS. RFC 2373 clearly expects this section to be potentially overridden. You don't get dueling RFCs when the overriding RFC acknowledges the one being overridden. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 19:30:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f542TeP18315 for ipng-dist; Sun, 3 Jun 2001 19:29:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f542Tbe18308 for ; Sun, 3 Jun 2001 19:29:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11222 for ; Sun, 3 Jun 2001 19:29:44 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA26904 for ; Sun, 3 Jun 2001 19:29:44 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f542TpU11923; Sun, 3 Jun 2001 19:29:51 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAR65476; Sun, 3 Jun 2001 19:29:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <20010604011054.570357BB@starfruit.itojun.org> References: <20010604011054.570357BB@starfruit.itojun.org> Date: Sun, 3 Jun 2001 19:29:28 -0700 To: Jun-ichiro itojun Hagino From: Steve Deering Subject: Re: DNS query over anycast Cc: Mark.Andrews@nominum.com, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:10 AM +0900 6/4/01, Jun-ichiro itojun Hagino wrote: > the condition "don't put anycast into source" was introduced because > of tcp issues, as you've described. Itojun, TCP is not the only reason for the restriction against using an anycast address as a source address. I can think of at least two other reasons, and there may well be more: (1) This restriction avoids the hazard of an ICMP error message being sent, regarding an erroneous packet, to a node that did not originate that packet. (2) For a packet whose destination is a multicast address, this restriction ensures that those multicast routing algorithms that use reverse-path forwarding will continue to work correctly. Basically, there are a number of places in the current architecture that assume that the source address of an IP packet identifies a single node; the restriction against using an anycast address as a source address ensures that we don't break anything that makes that assumption. The resulting requirement -- that request-response-style applications not simply swap the two addresses when sending a response message -- is needed anyway for responding to multicast requests, and has been satisfied long ago in most implementations of common UDP-based or ICMP based applications (such as ping), so ought not to be that hard to comply with. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 19:39:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f542cqY18362 for ipng-dist; Sun, 3 Jun 2001 19:38:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f542cme18355 for ; Sun, 3 Jun 2001 19:38:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04259 for ; Sun, 3 Jun 2001 19:38:55 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10067 for ; Sun, 3 Jun 2001 19:38:55 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f542d2U13696; Sun, 3 Jun 2001 19:39:02 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAR65490; Sun, 3 Jun 2001 19:38:51 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <2378.991562684@brandenburg.cs.mu.OZ.AU> References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Date: Sun, 3 Jun 2001 19:38:46 -0700 To: Robert Elz From: Steve Deering Subject: Re: DNS query over anycast Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:04 PM +0700 6/3/01, Robert Elz wrote: >And I know, that since an anycast address looks syntactically just like >a unicast address, this can be tricky at times... Part of the job of assigning an anycast address to a node is informing that node that that address is an anycast address, i.e., an address that is potentially shared with other nodes. That ensures that the node responsible for choosing the source address has the info needed to distinguish its own unicast addresses from its own anycast addresses, despite the lack of any syntactic indication in the addresses themselves. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 19:56:51 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f542uGK18421 for ipng-dist; Sun, 3 Jun 2001 19:56:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f542uCe18414 for ; Sun, 3 Jun 2001 19:56:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11104 for ; Sun, 3 Jun 2001 19:56:20 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14114 for ; Sun, 3 Jun 2001 20:56:19 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f542uJ918357; Sun, 3 Jun 2001 19:56:19 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAR65553; Sun, 3 Jun 2001 19:56:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: <6713.991553056@itojun.org> <200106040047.f540l4v67142@drugs.dv.isc.org> Date: Sun, 3 Jun 2001 19:56:17 -0700 To: Randy Bush From: Steve Deering Subject: Re: DNS query over anycast Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:47 PM -0700 6/3/01, Randy Bush wrote: > > "There is little experience with widespread, arbitrary use of internet > > anycast addresses > >actually, there is a fair bit of experience with it. Randy, There wasn't when that sentence was written. (That's the hazard of including such sentences in a long-lived document -- another thing for the RFC editor to watch for?) >as far as i can tell, the base problem here is that folk who have had no >experience with v4 anycast service deployment know in theory or in vitro >that there can be problems in some circumstances This is a case where we don't need to run the program to demonstrate that there's a bug in it. >... > >unfortunately, the result has been outlawing a whole bunch of stuff which >can not exhibit this kind of problem, namely udp based anycast services, >and outlawing tcp services which may not be as susceptable to the problem >about which they seem to be worried. The restriction doesn't outlaw such services; it just requires that those services satisfy the restriction, which may require a simple change to the service in some cases (those that weren't fixed years ago to accommodate multicast queries). >[0] - in fact, in real deployment, long lived tcp to a v4 anycast seems > more stable than even optimism would seem to warrant. So the bug doesn't show up often in practice. That doesn't mean the bug doesn't exist and won't have harmful consequences in those rare occasions when it is triggered. >research continues. Research in finding and understanding the corner cases? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 20:03:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5433Re18450 for ipng-dist; Sun, 3 Jun 2001 20:03:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5433Ne18443 for ; Sun, 3 Jun 2001 20:03:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA11746 for ; Sun, 3 Jun 2001 20:03:31 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA06781 for ; Sun, 3 Jun 2001 20:03:30 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156kcm-000B1B-00; Sun, 03 Jun 2001 20:01:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Steve Deering Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Sun, 03 Jun 2001 20:01:48 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Part of the job of assigning an anycast address to a node is informing > that node that that address is an anycast address, i.e., an address > that is potentially shared with other nodes. then the mis-behavior is a configuration option operators can ignore? randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 20:04:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5434Qi18471 for ipng-dist; Sun, 3 Jun 2001 20:04:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5434Me18464 for ; Sun, 3 Jun 2001 20:04:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27547 for ; Sun, 3 Jun 2001 20:04:30 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16846 for ; Sun, 3 Jun 2001 21:04:29 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156kfL-000C3O-00; Sun, 03 Jun 2001 20:04:27 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast References: <6713.991553056@itojun.org> <200106040047.f540l4v67142@drugs.dv.isc.org> Message-Id: Date: Sun, 03 Jun 2001 20:04:27 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> research continues. > Research in finding and understanding the corner cases? to try to explain why bumblebees fly, despite that their inability to do so is "a case where we don't need to run the program to demonstrate that there's a bug in it." randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 20:10:53 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f543AF018509 for ipng-dist; Sun, 3 Jun 2001 20:10:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f543ABe18502 for ; Sun, 3 Jun 2001 20:10:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13529 for ; Sun, 3 Jun 2001 20:10:19 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18744 for ; Sun, 3 Jun 2001 21:10:18 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f543AKU22472; Sun, 3 Jun 2001 20:10:20 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAR65603; Sun, 3 Jun 2001 20:10:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Date: Sun, 3 Jun 2001 20:10:15 -0700 To: Randy Bush From: Steve Deering Subject: Re: DNS query over anycast Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:01 PM -0700 6/3/01, Randy Bush wrote: > > Part of the job of assigning an anycast address to a node is informing > > that node that that address is an anycast address, i.e., an address > > that is potentially shared with other nodes. > >then the mis-behavior is a configuration option operators can ignore? Yes, there are many ways for operators to misconfigure their nodes and networks, and this offers one more. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 20:19:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f543IrQ18558 for ipng-dist; Sun, 3 Jun 2001 20:18:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f543Ine18551 for ; Sun, 3 Jun 2001 20:18:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA12769 for ; Sun, 3 Jun 2001 20:18:57 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17475 for ; Sun, 3 Jun 2001 20:18:57 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156ktL-000Diu-00; Sun, 03 Jun 2001 20:18:55 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Sun, 03 Jun 2001 20:18:55 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>> Part of the job of assigning an anycast address to a node is informing >>> that node that that address is an anycast address, i.e., an address >>> that is pot>red with other nodes. >> then the mis-behavior is a configuration option operators can ignore? > Yes, there are many ways for operators to misconfigure their nodes and > networks, and this offers one more. we poor stupid operators have to do something to overcome the mis-designs of the oh so brilliant but reality-challenged. while one can not measure all dns transactions, a significant number of them use just such a 'misconfiguration'. please excuse our stupidity in wishing to continue to offer our customers better service. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 22:50:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f545nxK18714 for ipng-dist; Sun, 3 Jun 2001 22:49:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f545nte18707 for ; Sun, 3 Jun 2001 22:49:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA08664 for ; Sun, 3 Jun 2001 22:50:03 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA02776 for ; Sun, 3 Jun 2001 22:50:01 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f545n8K01148; Mon, 4 Jun 2001 12:49:08 +0700 (ICT) From: Robert Elz To: Randy Bush , Steve Deering cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast In-Reply-To: References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Jun 2001 12:49:08 +0700 Message-ID: <1146.991633748@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 03 Jun 2001 20:18:55 -0700 From: Randy Bush Message-ID: | while one can not measure all dns transactions, a significant number of | them use just such a 'misconfiguration'. please excuse our stupidity in | wishing to continue to offer our customers better service. For v4 there is probably no other way. For v6 we're still early enough in the grand scheme of things that we could easily change the DNS spec (actually just the DNS clarifications - 2181) and require that v6 based resolvers ignore the source address of a reply, and match the reply to the query using the query ID and question alone. Using the IP address doesn't gain much really - it certainly doesn't offer any protection against bogus replies - in reality it is little more than one extra field to check. The requirement in 2181 is there not because the DNS protocol requires it, but because the vast majority of resolvers deployed happened to be implemented to expect it - that is, servers must send their answers that way, or they will be ignored. For v6, there are essentially no deployed resolvers yet (almost all v6 name resolution that is currently done is done using the v4 DNS), so changing the v6 resolvers to simply omit that check on the replies they receive (via v6), and process anything would not be a very difficult change to make. Aside from allowing replies to anycast queries to be sent from a unicast address (as could replies to multicast addresses, even broadcast) this would also vastly simplify the average DNS server, which would no longer need to care which particular address received the query, but could just send the reply using any convenient source address. For v6 nodes that are expected to have more addresses than your average v4 node, this is probably a win (even given the better v6 API that allows the dest addr of the query to be determined without having to bind a socket to every possible address, something that is a real challenge for v4 DNS servers in environments where addresses come and go frequently - like a server on the "dialing" end of a PPP connection, or anyone using v6 temporary addresses). For v4 there's probably not a lot to be done now - and so simply sending the reply from an anycast address is probably the only way that can work, there are simply too many deployed resolvers for it to be changed. Fortunately, most of the bugs that can be caused by sending from an anycast (UDP) address don't matter to the DNS (the only way to be sending to a multicast address from an anycast would be if the query originated from a multicast address - so that one we can ignore - and DNS servers typically get so many meaningless ICMP reports anyway, and have absolutely no state to associate them with anything at all, that getting a few erroneous ones isn't going to bother them at all). The problems that can happen when the node that (without knowing it) sent to an anycast address, and then gets a truncated reply, and tries again with TCP will just have to be suffered. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 22:57:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f545utw18747 for ipng-dist; Sun, 3 Jun 2001 22:56:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f545upe18740 for ; Sun, 3 Jun 2001 22:56:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25482 for ; Sun, 3 Jun 2001 22:56:58 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19530 for ; Sun, 3 Jun 2001 22:56:58 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156nKV-0001Up-00; Sun, 03 Jun 2001 22:55:07 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> <1146.991633748@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Sun, 03 Jun 2001 22:55:07 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For v4 there is probably no other way. For v6 we're still early enough > in the grand scheme of things that we could easily change the DNS > spec there are other deployments which use anycast, not just dns. dns is just the one we can talk about in public and is most obvious. anycast is actually *seriously* deployed and used. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 23:18:32 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f546HsQ18824 for ipng-dist; Sun, 3 Jun 2001 23:17:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f546Hoe18817 for ; Sun, 3 Jun 2001 23:17:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27269 for ; Sun, 3 Jun 2001 23:17:57 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18405 for ; Mon, 4 Jun 2001 00:17:53 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C35847BC; Mon, 4 Jun 2001 15:17:37 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Mon, 04 Jun 2001 12:49:08 +0700. <1146.991633748@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: DNS query over anycast From: Jun-ichiro itojun Hagino Date: Mon, 04 Jun 2001 15:17:37 +0900 Message-Id: <20010604061737.C35847BC@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >For v6, there are essentially no deployed resolvers yet (almost all v6 >name resolution that is currently done is done using the v4 DNS), so >changing the v6 resolvers to simply omit that check on the replies >they receive (via v6), and process anything would not be a very difficult >change to make. just FYI: NetBSD, FreeBSD and OpenBSD has been shipping with IPv6-ready client resolvers quite a while (more than a year). some of them supports EDNS0 (but not the fallback mechanism), some of them does not. yes, you may be able to say that the install base is still small, but "essentially no deployed resolvers" sounds incorrect to me. also, older version of BIND9 responds to multicast/anycast query by mistake:-) anycast responses depend on the OS you run named on. (don't remember the exact versions) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 23:24:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f546OaN18857 for ipng-dist; Sun, 3 Jun 2001 23:24:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f546OWe18850 for ; Sun, 3 Jun 2001 23:24:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA20977 for ; Sun, 3 Jun 2001 23:24:40 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA17198 for ; Sun, 3 Jun 2001 23:24:39 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f546N7517824; Sun, 3 Jun 2001 23:23:07 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAR66305; Sun, 3 Jun 2001 23:24:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Date: Sun, 3 Jun 2001 23:24:37 -0700 To: Randy Bush From: Steve Deering Subject: Re: DNS query over anycast Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:18 PM -0700 6/3/01, Randy Bush wrote: >we poor stupid operators have to do something to overcome the mis-designs >of the oh so brilliant but reality-challenged. > >while one can not measure all dns transactions, a significant number of >them use just such a 'misconfiguration'. please excuse our stupidity in >wishing to continue to offer our customers better service. Sigh. This is the classic tradeoff between the expedient hack and an alternative that accomplishes the same goal in a way that actually fits with the way the system was designed to work, but takes some more work to deploy. If there is an urgent customer need to deploy IPv6 anycast DNS transactions before the IPv6-capable DNS servers can be upgraded to provide a unicast source address in response to an anycast query, go ahead and (mis-)configure the servers to think an anycast address is a unicast address. Sure, this will work fine almost all of the time (or else you wouldn't be advocating it). And if all goes well, it won't result in too many calls to your help desk, reporting unusual failures that are difficult to diagnose because they are difficult to reproduce (being the result of infrequent coincidences). Also, be sure that your support staff makes a note of the non-obvious topological limitations that must be adhered to to make your approach work properly, such as making sure that two such servers are never placed in the same subnet (so that DAD won't prevent the use of the shared address). But can we please also work towards deploying the simple fix in the servers required to support an anycast service that is not susceptible to known potential failure modes and that does not have unexpected topological restrictions? After all, this is the IPv6 effort, which has the quixotic goal of trying to make the Internet less fragile, rather than just not-too-much-more-fragile. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 23:46:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f546jjZ18934 for ipng-dist; Sun, 3 Jun 2001 23:45:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f546jee18927 for ; Sun, 3 Jun 2001 23:45:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29685 for ; Sun, 3 Jun 2001 23:45:48 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA29931 for ; Sun, 3 Jun 2001 23:45:47 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:f57d:73f7:d957:f7bc]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id PAA24596; Mon, 4 Jun 2001 15:42:58 +0900 (JST) Date: Mon, 04 Jun 2001 15:40:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jun-ichiro itojun Hagino Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast In-Reply-To: <20010604061737.C35847BC@starfruit.itojun.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20010604061737.C35847BC@starfruit.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 04 Jun 2001 15:17:37 +0900, >>>>> Jun-ichiro itojun Hagino said: > also, older version of BIND9 responds to multicast/anycast query by > mistake:-) anycast responses depend on the OS you run named on. > (don't remember the exact versions) (although this is probably an off-topic,) even the latest version of BIND9 can respond to IPv4 multicasted queries and IPv6 multicasted/anycasted queries; it does not check the destination address to prevent such queries. Whether or not we see replies to such queries does not depend on the version of bind9, but on the implementation of the underling kernel. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 3 23:55:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f546t5v18970 for ipng-dist; Sun, 3 Jun 2001 23:55:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f546t1e18963 for ; Sun, 3 Jun 2001 23:55:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29769 for ; Sun, 3 Jun 2001 23:55:09 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA16410 for ; Mon, 4 Jun 2001 00:55:38 -0600 (MDT) Received: from endor.eas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id CAA18364 for ; Mon, 4 Jun 2001 02:54:51 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.eas.harvard.edu (8.8.8/8.8.8) id CAA03532 for ipng@sunroof.eng.sun.com; Mon, 4 Jun 2001 02:55:01 -0400 (EDT) Date: Mon, 4 Jun 2001 02:55:01 -0400 (EDT) Message-Id: <200106040655.CAA03532@endor.eas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: | Date: Sun, 03 Jun 2001 20:18:55 -0700 | From: Randy Bush | Message-ID: | | | while one can not measure all dns transactions, a significant number of | | them use just such a 'misconfiguration'. please excuse our stupidity in | | wishing to continue to offer our customers better service. | |For v4 there is probably no other way. For v6 we're still early enough |in the grand scheme of things that we could easily change the DNS |spec (actually just the DNS clarifications - 2181) and require that |v6 based resolvers ignore the source address of a reply, and match the |reply to the query using the query ID and question alone. | |Using the IP address doesn't gain much really - it certainly doesn't |offer any protection against bogus replies - in reality it is little |more than one extra field to check. | |The requirement in 2181 is there not because the DNS protocol requires |it, but because the vast majority of resolvers deployed happened to |be implemented to expect it - that is, servers must send their answers |that way, or they will be ignored. | |For v6, there are essentially no deployed resolvers yet (almost all v6 |name resolution that is currently done is done using the v4 DNS), so |changing the v6 resolvers to simply omit that check on the replies |they receive (via v6), and process anything would not be a very difficult |change to make. One minor clarification. Existing sockets-based resolvers don't check the source address in some futile attempt to avoid bogus replies. In fact, they don't generally check the source address explicitly at all. The check is happening in the kernel as a side effect of the resolver's using a connect()ed socket. The resolver is using a connect()ed socket so that it can get a quick indication that the server is not running via a UDP port unreachable. This is important both in the case of a single server on the loopback address (in order to avoid having to time out during boot when the name server is not yet running) and in the multi-server case to quickly move on to another server in a list if the current one is not running (though the latter might better be accomplished by sending out requests in parallel). The original sockets API offers no other way to accomplish this interaction with UDP port unreachables. Fancy new APIs may allow the same thing to be accomplished by other means, but in any case you are talking about slightly more (structurally) than simply removing a check on the reply. Dan Lanciani ddl@harvard.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 02:08:40 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54982v19267 for ipng-dist; Mon, 4 Jun 2001 02:08:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5497we19260 for ; Mon, 4 Jun 2001 02:07:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10226 for ; Mon, 4 Jun 2001 02:08:07 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18404 for ; Mon, 4 Jun 2001 03:08:04 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:381b:8e53:5659:a3d6]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA25371; Mon, 4 Jun 2001 18:05:58 +0900 (JST) Date: Mon, 04 Jun 2001 18:03:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Steve Deering Cc: Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast In-Reply-To: References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 3 Jun 2001 19:38:46 -0700, >>>>> Steve Deering said: >> And I know, that since an anycast address looks syntactically just like >> a unicast address, this can be tricky at times... > Part of the job of assigning an anycast address to a node is informing > that node that that address is an anycast address, i.e., an address > that is potentially shared with other nodes. That ensures that the > node responsible for choosing the source address has the info needed > to distinguish its own unicast addresses from its own anycast addresses, > despite the lack of any syntactic indication in the addresses themselves. That's correct, but from an implementor's point of view, anycast addresses are more problematic than multicast, because there is no standard API to see if a given address is an anycast address on the node nor to see if a received packet is anycasted. We may have to define a standard (portable) way as a part of the advanced API (bis). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 02:21:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f549Kw819304 for ipng-dist; Mon, 4 Jun 2001 02:20:58 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f549Kse19297 for ; Mon, 4 Jun 2001 02:20:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11025 for ; Mon, 4 Jun 2001 02:21:03 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id DAA19290 for ; Mon, 4 Jun 2001 03:21:33 -0600 (MDT) Received: from 157.54.1.52 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 04 Jun 2001 02:08:52 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 4 Jun 2001 02:09:10 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 4 Jun 2001 02:09:06 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Jun 2001 02:08:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C0ECD5.DF6B5010" Subject: RE: DNS query over anycast Date: Mon, 4 Jun 2001 02:08:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS query over anycast Thread-Index: AcDsv0s6Ru0w+eULQkCdXwvKTw9T9gAFYaG6 From: "Christian Huitema" To: "Steve Deering" , "Randy Bush" Cc: X-OriginalArrivalTime: 04 Jun 2001 09:08:09.0215 (UTC) FILETIME=[DFBB30F0:01C0ECD5] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C0ECD5.DF6B5010 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGFydCBvZiB0aGUgcHJvYmxlbSBpcyB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgSVB2NiBhbnljYXN0 IHNlcnZpY2UuIFdlDQp3b3VsZCByZWFsbHkgd2FudCB0byBoYXZlIGEgc2VydmljZSB0aGF0IHdv cmtzIHdlbGwgZm9yIFVEUCBhcyB3ZWxsIGFzDQpUQ1A7IHVzaW5nIGFuIGFueWNhc3QgYWRkcmVz cyBhcyBhIFRDUCBzb3VyY2UgaXMgcHJvYmxlbWF0aWM7IGluICBmYWN0LA0KZXZlbiB1c2luZyBh biBhbnljYXN0IGFkZHJlc3MgYXMgYW4gVURQIHNvdXJjZSBnZW5lcmF0ZXMgaW50ZXJlc3RpbmcN CmZhaWx1cmUgY2FzZXMgaWYgdGhlIHF1ZXJ5IHBhY2tldCBoYXBwZW5zIHRvIGJlIHJlcGxpY2F0 ZWQgYW5kIHRoZQ0KcmVzcG9uc2UgaGFwcGVuIHRvIGNvbWUgZnJvbSB0d28gc2VydmVycy4NCiAN CkluIHRoZSBzaG9ydCB0ZXJtLCB3ZSBjb3VsZCBpbmRlZWQganVzdCB1c2UgdGhlIGN1cnJlbnQg SVB2NCBzb2x1dGlvbi4NCkluIGZhY3QsIHlvdSBjYW4gcHJvYmFibHkgd2Vhc2VsIHRoYXQgaW50 byB0aGUgY3VycmVudCBJUHY2IGZyYW1ld29yaywNCmV4cGxhaW5pbmcgdGhhdCB0aGUgYWRkcmVz cyBpcyBpbiBmYWN0IGEgdW5pY2FzdCBhZGRyZXNzIHRvIGENCiJkaXN0cmlidXRlZCBpbnRlcmZh Y2UiIHRvIGEgImRpc3RyaWJ1dGVkIHNlcnZlci4iDQogDQpJbiB0aGUgbWlkIHRlcm0sIHdlIHdv dWxkIHdhbnQgdG8gc3R1ZHkgYSAicmVhbCIgc29sdXRpb24uIFRoaXMgc2hvdWxkDQpwcm9iYWJs eSBiZSBiYXNlZCBvbiBzb21lIGtpbmQgb2YgInJlZGlyZWN0IiBzY2VuYXJpbzogdHJ5IHRvIHJl YWNoIHRoZQ0KImxvZ2ljYWwgYWRkcmVzcyBYOlg6WDpYIiwgYW5kIHJlY2VpdmUgYSByZWRpcmVj dCB0byBhIHBoeXNpY2FsDQppbXBsZW1lbnRhdGlvbjsgdGhhdCBjb3VsZCB3b3JrIHdpdGggVENQ IGFzIHdlbGwgYXMgVURQLCBhbmQgYmUgcm9idXN0Lg0KIA0KLS0gQ2hyaXN0aWFuIEh1aXRlbWEN Cg== ------_=_NextPart_001_01C0ECD5.DF6B5010 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IgkJAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADRBwYABAACAAgACAABAPUAASCAAwAOAAAA0QcGAAQAAgAIAAgAAQD1AAEJgAEAIQAAAEFE MkYzMDkyQTQ5NjVDNDRBNjA0MzJFRUZCRjJEQUFFAGQHAQOQBgAQDgAAOQAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAADYAAABSAEUAOgAgAEQATgBTACAA cQB1AGUAcgB5ACAAbwB2AGUAcgAgAGEAbgB5AGMAYQBzAHQAAAAAAEAAOQAQUGvf1ezAAR8APQAB AAAACgAAAFIARQA6ACAAAAAAAAIBRwABAAAAPAAAAGM9VVM7YT13aW5kb3dzO3A9TWljcm9zb2Z0 O2w9V0lOLU1TRy0wMi0wMTA2MDQwOTA4MDhaLTIxNzgyAB8ASQABAAAANgAAAFIAZQA6ACAARABO AFMAIABxAHUAZQByAHkAIABvAHYAZQByACAAYQBuAHkAYwBhAHMAdAAAAAAAQABOAIAAMge/7MAB HwBaAAEAAAAcAAAAUwB0AGUAdgBlACAARABlAGUAcgBpAG4AZwAAAAIBWwABAAAAPQAAAAAAAACB Kx+kvqMQGZ1uAN0BD1QCAAAAAFN0ZXZlIERlZXJpbmcAU01UUABkZWVyaW5nQGNpc2NvLmNvbQAA AAACAVwAAQAAABcAAABTTVRQOkRFRVJJTkdAQ0lTQ08uQ09NAAAfAF0AAQAAABwAAABTAHQAZQB2 AGUAIABEAGUAZQByAGkAbgBnAAAAAgFeAAEAAAA9AAAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAAA U3RldmUgRGVlcmluZwBTTVRQAGRlZXJpbmdAY2lzY28uY29tAAAAAAIBXwABAAAAFwAAAFNNVFA6 REVFUklOR0BDSVNDTy5DT00AAB8AZgABAAAACgAAAFMATQBUAFAAAAAAAB8AZwABAAAAJAAAAGQA ZQBlAHIAaQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQAAAB8AaAABAAAACgAAAFMATQBUAFAAAAAA AB8AaQABAAAAJAAAAGQAZQBlAHIAaQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQAAAB8AcAABAAAA LgAAAEQATgBTACAAcQB1AGUAcgB5ACAAbwB2AGUAcgAgAGEAbgB5AGMAYQBzAHQAAAAAAAIBcQAB AAAAGwAAAAHA7L9LOkbtMPnlC0JAnV8Lyk8PU/YABWGhugAfAHMAAQAAADIAAABpAHAAbgBnAEAA cwB1AG4AcgBvAG8AZgAuAGUAbgBnAC4AcwB1AG4ALgBjAG8AbQAAAAAAHwB0AAEAAAAWAAAAUgBh AG4AZAB5ACAAQgB1AHMAaAAAAAAAHwAaDAEAAAAkAAAAQwBoAHIAaQBzAHQAaQBhAG4AIABIAHUA aQB0AGUAbQBhAAAAHwAdDgEAAAAuAAAARABOAFMAIABxAHUAZQByAHkAIABvAHYAZQByACAAYQBu AHkAYwBhAHMAdAAAAAAAAgEJEAEAAABxBQAAbQUAAN8NAABMWkZ1tvqhOAMACgByY3BnMTI1gjID Q2h0bWwxAzA/AQMB9wqAAqQD4wIAY2jBCsBzZXQwIAcTAoD/EAMAUARWCFUHshHVDlEDAd0Q1zIG AAbDEdUzBEYQ2W8S6xHjCO8J9zsYzw4wNTsR0gxgYwBQCwkBZDM2kxFgC6U0IBACKlwOsr0BkGcU 8AqjEeMd6DQU8AA8IURPQ1RZUABFIEhUTUwgUABVQkxJQyAiLSAvL1czQyGARFQiRCCUMy4yIYBF TpwiPh7tHo8jwTE4H/BvIKIjDyQfJpAzHYAlcEV8QUQlzQ7xJu8pbyT0NkEO8DxNRVRBB7BBMSxg PSJHCfAEkGF0RQWwIhLQT05UItBUEyzwBeFFeBDxbmdlPQZSdhMxL0EAkAIgIDbgLjAuNDcOIDAQ Iv4TKs8lAzc3H/BUSVQUTEUlzjQO8FJlOiggRE4F8HEKUHJ5DCBvL0IAcHljYXPqdCRuNR/wLzNP MX8mRV80kTeAKE8mnztUNRFgPABCT0RZIGRpcvo9O3ByOsA7MwAhAzA90ZxkbwDgPdEKsVxxGLD/ PdEQ8AMwPjURYDrrHPE774hnOTYf8ERJVj4JZwAAQEc7CTY0Q39AklBLCsAFQG8+kHRoLvBw4wNg AmBlbSAEAEdTAQEZC4BpdC/CRzVJUHY7QwA19SARMC8wDeBlLpQgVy7wdwhgbGQdnK8dgEHEGNAH QGw1gHcAcPsFQC1wIBEAL0A14Ep2R1GTLWBLMXJrBCB3ZU0gxiACEAXAVURQNeBPZYFQUVRDUDsg dQCQHy7QNeFLn0HTSgZhZGT/GNAEEVBRTjBRAUpwCGFOoX9IIUelLWAN4FEwC4A66zjBHYAmbmJz cAKAPig8J2EBQEBHT8AA0HQs/CBlL0ADoFFfUm9TfgOg/1ASVMUu4C0zB5ELgF5AU+H/SPBaIVlA AxAIcC7wNiFeUp9HRFqPQeI1RAqwY2sRQLlN0XBwCfBIMU3AYi7w/xjQC1AN4F4xS4AAcEuAR2L9 U+FwAiARMGKlTaIFoAeA/0/AA2FHUEtAYI9B00qCL5H+LjsJAcA+FwqiPhcKcSR8/jAoESHgQ0tq SEDPQd9C7/9D/0UPcOtWX1dvWHpor2m//2rPa99s723/bw9wH3Yvcj/Ne0dJZaFHcXNoGHFHUP0E kG1ZgE+AZeFLYguAAQD9ZBFqWfAFQFnwTrJfoQhw/xjQTYFJsR2AVMAKQEjySvDvgeFm33ziWUR5 CGBfsQOg/0eiAaBNMk0AETADIE7TXoHvTcCErX4AA1BhB4BPIlmB/ngLU1oSho984k7TR2JTtu9I IQuAWTNOIXUDAFwLTbHdTjAiPZA2QAUQYoXgZBH7XoNZQWUtoJDzjM984pFL+WgkLiJ2v3fPeN95 73r//3wPfR9+L38/gE+aT3RfdW//dn+Wj5efmK+Zv5rPm9+c78+d/58PgR9HcW1pZGGCxudLRE1m NkB1ZDWAkSFM8vMtoIW4VGhIIYJRS29Mdv+It2NhiOARMLNAL9FUwGYRvmuDoUcisZE9kQWQdLHh /UrQbgrAL8A04D3gNYBNsddM8UABR2IiGGBnY9EDIKezb1uTU8VYOruTIlmAc2RCtyFlaU4DtuaQ 5HD8aHkN0bmRB3ALUEfwhSH/VdECIFEwTtO5z6nyg0RPIv9LMEjgQBBUglBZUBG8FGNi/0fAhCFo n6TPpd+m76f/qQ//qh+rL6w/rU/Iz6Ffom+jf//FD8Yfxy/IP8lPyl/Lb8x/082P2owtLRLQaAUQ XuH5A5FIdUjgVbHSX9Nv1H9/1Y/Wn9evHuzkvzzDJVEvfz1COs/mL+ixMxE6cCWTfQHq4AAAAB8A NRABAAAAtgAAADwARgA2ADYAQQAwADQAQwAyADkAQQBEADkAMAAzADQAQQA4ADIAMAA1ADkANAA5 AEEARAAwAEMAOQAwADEAMAA0ADEAOABCAEUANAAxAEAAdwBpAG4ALQBtAHMAZwAtADAAMgAuAHcA aQBuAGcAcgBvAHUAcAAuAHcAaQBuAGQAZQBwAGwAbwB5AC4AbgB0AGQAZQB2AC4AbQBpAGMAcgBv AHMAbwBmAHQALgBjAG8AbQA+AAAAAAAfAEcQAQAAAB4AAABtAGUAcwBzAGEAZwBlAC8AcgBmAGMA OAAyADIAAAAAAAsA8hABAAAAHwDzEAEAAABCAAAAUgBFACUAMwBBACAARABOAFMAIABxAHUAZQBy AHkAIABvAHYAZQByACAAYQBuAHkAYwBhAHMAdAAuAEUATQBMAAAAAAALAPYQAAAAAEAABzBSNr7R 1OzAAUAACDAUnnnf1ezAAQMA3j/p/QAAAwDxPwkEAAAfAPg/AQAAACQAAABDAGgAcgBpAHMAdABp AGEAbgAgAEgAdQBpAHQAZQBtAGEAAAACAfk/AQAAAGAAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA AAAAAAAAL089TUlDUk9TT0ZUL09VPUZJUlNUIEFETUlOSVNUUkFUSVZFIEdST1VQL0NOPVJFQ0lQ SUVOVFMvQ049SFVJVEVNQQAfAPo/AQAAACoAAABTAHkAcwB0AGUAbQAgAEEAZABtAGkAbgBpAHMA dAByAGEAdABvAHIAAAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAu AAAAAwD9P+QEAAADABlAAAAAAAMAGkAAAAAAAwAdQAAAAAADAB5AAAAAAB8AMEABAAAAEAAAAEgA VQBJAFQARQBNAEEAAAAfADFAAQAAABAAAABIAFUASQBUAEUATQBBAAAAHwAyQAEAAAAkAAAAZABl AGUAcgBpAG4AZwBAAGMAaQBzAGMAbwAuAGMAbwBtAAAAHwAzQAEAAAAkAAAAZABlAGUAcgBpAG4A ZwBAAGMAaQBzAGMAbwAuAGMAbwBtAAAAHwA4QAEAAAAQAAAASABVAEkAVABFAE0AQQAAAB8AOUAB AAAABAAAAC4AAAALACkAAAAAAAsAIwAAAAAAAwAGEB0qC3wDAAcQBAMAAAMAEBAAAAAAAwAREAAA AAAeAAgQAQAAAGUAAABQQVJUT0ZUSEVQUk9CTEVNSVNUSEVERUZJTklUSU9OT0ZUSEVJUFY2QU5Z Q0FTVFNFUlZJQ0VXRVdPVUxEUkVBTExZV0FOVFRPSEFWRUFTRVJWSUNFVEhBVFdPUktTV0VMTEZP AAAAAAIBfwABAAAAWwAAADxGNjZBMDRDMjlBRDkwMzRBODIwNTk0OUFEMEM5MDEwNDE4QkU0MUB3 aW4tbXNnLTAyLndpbmdyb3VwLndpbmRlcGxveS5udGRldi5taWNyb3NvZnQuY29tPgAAyJ4= ------_=_NextPart_001_01C0ECD5.DF6B5010-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 02:22:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f549MQj19322 for ipng-dist; Mon, 4 Jun 2001 02:22:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f549MMe19315 for ; Mon, 4 Jun 2001 02:22:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11089 for ; Mon, 4 Jun 2001 02:22:31 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23594 for ; Mon, 4 Jun 2001 03:22:30 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id DC4D63190C; Mon, 4 Jun 2001 02:22:28 -0700 (PDT) Message-Id: <5.0.2.1.2.20010604021655.02044d18@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 04 Jun 2001 02:22:27 -0700 To: Robert Elz , Randy Bush , Steve Deering From: "David R. Conrad" Subject: Re: DNS query over anycast Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1146.991633748@brandenburg.cs.mu.OZ.AU> References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kre, At 12:49 PM 6/4/2001 +0700, Robert Elz wrote: >For v6, there are essentially no deployed resolvers yet (almost all v6 >name resolution that is currently done is done using the v4 DNS) Just a data point: last time I checked (back in April), there were about 100,000 unique sites downloading BIND version 9 which has a full IPv6 supporting resolver. How much that resolver is being used is, of course, a different question and one much harder to answer. Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 02:31:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f549Udv19367 for ipng-dist; Mon, 4 Jun 2001 02:30:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f549UYe19360 for ; Mon, 4 Jun 2001 02:30:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04201 for ; Mon, 4 Jun 2001 02:30:43 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA03714 for ; Mon, 4 Jun 2001 02:30:41 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:381b:8e53:5659:a3d6]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA25564; Mon, 4 Jun 2001 18:30:47 +0900 (JST) Date: Mon, 04 Jun 2001 18:28:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "David R. Conrad" Cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast In-Reply-To: <5.0.2.1.2.20010604021655.02044d18@localhost> References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> <1146.991633748@brandenburg.cs.mu.OZ.AU> <5.0.2.1.2.20010604021655.02044d18@localhost> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 04 Jun 2001 02:22:27 -0700, >>>>> "David R. Conrad" said: >> For v6, there are essentially no deployed resolvers yet (almost all v6 >> name resolution that is currently done is done using the v4 DNS) > Just a data point: last time I checked (back in April), there were about > 100,000 unique sites downloading BIND version 9 which has a full IPv6 > supporting resolver. How much that resolver is being used is, of course, a > different question and one much harder to answer. Just checking, what do you mean by "resolver" here? If you mean lwresd in bind9 or the resolver routine in BIND9 named, it's okay. However, as far as I know, all released BIND9 (except the very recent one -9.2.0a1-) do not include the "traditional" style of local resolver library, which can be linked with other application binaries. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 02:36:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f549aaq19408 for ipng-dist; Mon, 4 Jun 2001 02:36:36 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f549aWe19401 for ; Mon, 4 Jun 2001 02:36:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11829 for ; Mon, 4 Jun 2001 02:36:41 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA26153 for ; Mon, 4 Jun 2001 03:37:10 -0600 (MDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id C28353190D; Mon, 4 Jun 2001 02:36:38 -0700 (PDT) Message-Id: <5.0.2.1.2.20010604023437.031637a0@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 04 Jun 2001 02:36:37 -0700 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: "David R. Conrad" Subject: Re: DNS query over anycast Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <5.0.2.1.2.20010604021655.02044d18@localhost> <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> <1146.991633748@brandenburg.cs.mu.OZ.AU> <5.0.2.1.2.20010604021655.02044d18@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk lwresd (thus my comment about how much it being used :-)) At 06:28 PM 6/4/2001 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 04 Jun 2001 02:22:27 -0700, > >>>>> "David R. Conrad" said: > > >> For v6, there are essentially no deployed resolvers yet (almost all v6 > >> name resolution that is currently done is done using the v4 DNS) > > > Just a data point: last time I checked (back in April), there were about > > 100,000 unique sites downloading BIND version 9 which has a full IPv6 > > supporting resolver. How much that resolver is being used is, of > course, a > > different question and one much harder to answer. > >Just checking, what do you mean by "resolver" here? If you mean >lwresd in bind9 or the resolver routine in BIND9 named, it's okay. >However, as far as I know, all released BIND9 (except the very recent >one -9.2.0a1-) do not include the "traditional" style of local >resolver library, which can be linked with other application binaries. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 04:16:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54BG0c19508 for ipng-dist; Mon, 4 Jun 2001 04:16:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54BFve19501 for ; Mon, 4 Jun 2001 04:15:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18358 for ; Mon, 4 Jun 2001 04:16:03 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09466 for ; Mon, 4 Jun 2001 05:16:32 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156sKz-0009yg-00; Mon, 04 Jun 2001 04:15:57 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast References: <200106030719.f537Jav63818@drugs.dv.isc.org> <2378.991562684@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Mon, 04 Jun 2001 04:15:57 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the underlying mismatch is that anycast use should not require the other end to know that it is dealing with a second class citizen. folk deploying a service using anycast want it to look *exactly* the same as a unicast service. that's the whole point of it. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 04:40:13 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54Bdck19551 for ipng-dist; Mon, 4 Jun 2001 04:39:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54BdYe19544 for ; Mon, 4 Jun 2001 04:39:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12043 for ; Mon, 4 Jun 2001 04:39:36 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA27033 for ; Mon, 4 Jun 2001 04:39:36 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 156shm-000Ab1-00; Mon, 04 Jun 2001 04:39:30 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Christian Huitema Cc: Subject: RE: DNS query over anycast References: Message-Id: Date: Mon, 04 Jun 2001 04:39:30 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In the mid term, we would want to study a "real" solution. This should > probably be based on some kind of "redirect" scenario almost all current v4 anycast deployment uses anycast to very specifically find the [ei]gp closest server. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 05:48:12 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54ClX719623 for ipng-dist; Mon, 4 Jun 2001 05:47:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54ClTe19616 for ; Mon, 4 Jun 2001 05:47:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09042 for ; Mon, 4 Jun 2001 05:47:37 -0700 (PDT) Received: from fw1-b.osis.gov (fw1-b.osis.gov [204.178.104.234]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28351 for ; Mon, 4 Jun 2001 05:47:36 -0700 (PDT) Received: from neptune.jioc.osis.gov by fw1-b.osis.gov with ESMTP id IAA29042 (InterLock SMTP Gateway 4.2 for osis.gov); Mon, 4 Jun 2001 08:47:29 -0400 (EDT) Received: by neptune.jioc.osis.gov with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Jun 2001 07:46:22 -0500 Message-ID: From: "SESVOLD, DALE" To: "'Steve Deering'" , Randy Bush Cc: ipng@sunroof.eng.sun.com Subject: RE: DNS query over anycast Date: Mon, 4 Jun 2001 07:46:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0ECF4.5BA71190" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0ECF4.5BA71190 Content-Type: text/plain; charset="iso-8859-1" Please excuse my ignorance, but I need some clarification. Isn't the anycast address for DNS used in a similar method to the neighbor discovery with the link local multicast? Shouldn't the host request the address of a DNS server through the anycast address, and then when the unicast address is presented back to the host it would initiate all DNS communication directly on the proper unicast address? | DALE G SESVOLD | Senior Network Engineer | MacAulay-Brown, Inc. | Joint Information Operations Center | J61, Information Operations Technical Analysis -----Original Message----- From: Steve Deering [mailto:deering@cisco.com] Sent: Monday, June 04, 2001 1:25 AM To: Randy Bush Cc: ipng@sunroof.eng.sun.com Subject: Re: DNS query over anycast At 8:18 PM -0700 6/3/01, Randy Bush wrote: >we poor stupid operators have to do something to overcome the mis-designs >of the oh so brilliant but reality-challenged. > >while one can not measure all dns transactions, a significant number of >them use just such a 'misconfiguration'. please excuse our stupidity in >wishing to continue to offer our customers better service. Sigh. This is the classic tradeoff between the expedient hack and an alternative that accomplishes the same goal in a way that actually fits with the way the system was designed to work, but takes some more work to deploy. If there is an urgent customer need to deploy IPv6 anycast DNS transactions before the IPv6-capable DNS servers can be upgraded to provide a unicast source address in response to an anycast query, go ahead and (mis-)configure the servers to think an anycast address is a unicast address. Sure, this will work fine almost all of the time (or else you wouldn't be advocating it). ... Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C0ECF4.5BA71190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DNS query over anycast

Please excuse my ignorance, but I need some = clarification.  Isn't the anycast address for DNS used in a = similar method to the neighbor discovery with the link local = multicast?  Shouldn't the host request the address of a DNS server = through the anycast address, and then when the unicast address is = presented back to the host it would initiate all DNS communication = directly on the proper unicast address?

| DALE G SESVOLD
| Senior Network Engineer
| MacAulay-Brown, Inc.
| Joint Information Operations Center
| J61, Information Operations Technical = Analysis


-----Original Message-----
From: Steve Deering [mailto:deering@cisco.com]
Sent: Monday, June 04, 2001 1:25 AM
To: Randy Bush
Cc: ipng@sunroof.eng.sun.com
Subject: Re: DNS query over anycast


At 8:18 PM -0700 6/3/01, Randy Bush wrote:
>we poor stupid operators have to do something to = overcome the mis-designs
>of the oh so brilliant but = reality-challenged.
>
>while one can not measure all dns transactions, = a significant number of
>them use just such a 'misconfiguration'.  = please excuse our stupidity in
>wishing to continue to offer our customers = better service.

Sigh.

This is the classic tradeoff between the expedient = hack and an
alternative that accomplishes the same goal in a way = that actually
fits with the way the system was designed to work, = but takes some
more work to deploy.

If there is an urgent customer need to deploy IPv6 = anycast DNS
transactions before the IPv6-capable DNS servers can = be upgraded to
provide a unicast source address in response to an = anycast query,
go ahead and (mis-)configure the servers to think an = anycast address
is a unicast address.  Sure, this will work = fine almost all of the time
(or else you wouldn't be advocating it).  = ...

Steve

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C0ECF4.5BA71190-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 07:35:37 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54EYxL19737 for ipng-dist; Mon, 4 Jun 2001 07:34:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54EYte19730 for ; Mon, 4 Jun 2001 07:34:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21701 for ; Mon, 4 Jun 2001 07:35:01 -0700 (PDT) Received: from roam.psg.com (mg-206253200-75.ricochet.net [206.253.200.75]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13393 for ; Mon, 4 Jun 2001 08:34:58 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.22 #1) id 156uit-0000d2-00; Mon, 04 Jun 2001 06:48:47 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "SESVOLD, DALE" Cc: ipng@sunroof.eng.sun.com Subject: RE: DNS query over anycast References: Message-Id: Date: Mon, 04 Jun 2001 06:48:47 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Please excuse my ignorance, but I need some clarification. Isn't the > anycast address for DNS used in a similar method to the neighbor discovery > with the link local multicast? nope. most large isps have deployed dns caches on anycast, each isp a different address, and tell their customers to point to that address. it's just plain old dns, the request goes out, the reponse comes back. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 08:05:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54F4am19791 for ipng-dist; Mon, 4 Jun 2001 08:04:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54F4Xe19784 for ; Mon, 4 Jun 2001 08:04:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10799 for ; Mon, 4 Jun 2001 08:04:36 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06584 for ; Mon, 4 Jun 2001 09:04:34 -0600 (MDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f54F4WO25497; Mon, 4 Jun 2001 17:04:32 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f54F4V419939; Mon, 4 Jun 2001 18:04:32 +0300 (EET DST) Message-ID: <3B1BA37F.70B6B27F@lmf.ericsson.se> Date: Mon, 04 Jun 2001 18:04:31 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jun-ichiro itojun Hagino CC: ipng@sunroof.eng.sun.com Subject: Re: dialup PPP (material for interim meeting) References: <20010530054428.A2DE1782@starfruit.itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for the interesting draft. (Was this discussed at the interim and were there any notes taken?) One issue should perhaps also be taken up in the context of IPv6 and PPP. As we are moving (gprs etc) towards a more always-on world, it is possible that I run a PPP link, for instance, between my PDA and a GPRS terminal basically as a permanent connection. Do I want to retain the same address on it all the time, or should I be able to run the privacy extension (RFC 3041) over PPP as well? I.e. even in the static addressing model that you mention there may be needs to change the address for privacy reasons. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 08:13:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54FCo319835 for ipng-dist; Mon, 4 Jun 2001 08:12:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54FCje19828 for ; Mon, 4 Jun 2001 08:12:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17754 for ; Mon, 4 Jun 2001 08:12:52 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13648 for ; Mon, 4 Jun 2001 09:12:50 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 036B47BB; Tue, 5 Jun 2001 00:12:33 +0900 (JST) To: Jari Arkko Cc: ipng@sunroof.eng.sun.com In-reply-to: Jari.Arkko's message of Mon, 04 Jun 2001 18:04:31 +0300. <3B1BA37F.70B6B27F@lmf.ericsson.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dialup PPP (material for interim meeting) From: Jun-ichiro itojun Hagino Date: Tue, 05 Jun 2001 00:12:32 +0900 Message-Id: <20010604151233.036B47BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Thanks for the interesting draft. (Was this discussed >at the interim and were there any notes taken?) i hope that there's a note, there was a highly active discussions (partly because the draft kept many options open). >One issue should perhaps also be taken up in the context >of IPv6 and PPP. As we are moving (gprs etc) towards a >more always-on world, it is possible that I run a PPP link, >for instance, between my PDA and a GPRS terminal basically >as a permanent connection. Do I want to retain the same >address on it all the time, or should I be able to run >the privacy extension (RFC 3041) over PPP as well? I.e. >even in the static addressing model that you mention there >may be needs to change the address for privacy reasons. basically the above highly depends on the assuption you make for address assignments to PDA/GPRS devices. if you follow "allocate /64 to the network behind the device" model (2nd bullet in section 2.4), you can generate new source address out of the given /64 at will. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 08:40:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54Fd5A19898 for ipng-dist; Mon, 4 Jun 2001 08:39:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Fd1e19891 for ; Mon, 4 Jun 2001 08:39:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21854 for ; Mon, 4 Jun 2001 08:39:08 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07873 for ; Mon, 4 Jun 2001 09:39:40 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f54FbL521051; Mon, 4 Jun 2001 08:37:23 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHH17408; Mon, 4 Jun 2001 08:38:52 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09282; Mon, 4 Jun 2001 08:38:52 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15131.43916.485908.794477@thomasm-u1.cisco.com> Date: Mon, 4 Jun 2001 08:38:52 -0700 (PDT) To: Jun-ichiro itojun Hagino Cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: dialup PPP (material for interim meeting) In-Reply-To: <20010604151233.036B47BB@starfruit.itojun.org> References: <3B1BA37F.70B6B27F@lmf.ericsson.se> <20010604151233.036B47BB@starfruit.itojun.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jun-ichiro itojun Hagino writes: > > >Thanks for the interesting draft. (Was this discussed > >at the interim and were there any notes taken?) > > i hope that there's a note, there was a highly active discussions > (partly because the draft kept many options open). > > >One issue should perhaps also be taken up in the context > >of IPv6 and PPP. As we are moving (gprs etc) towards a > >more always-on world, it is possible that I run a PPP link, > >for instance, between my PDA and a GPRS terminal basically > >as a permanent connection. Do I want to retain the same > >address on it all the time, or should I be able to run > >the privacy extension (RFC 3041) over PPP as well? I.e. > >even in the static addressing model that you mention there > >may be needs to change the address for privacy reasons. > > basically the above highly depends on the assuption you make for > address assignments to PDA/GPRS devices. > if you follow "allocate /64 to the network behind the device" model > (2nd bullet in section 2.4), you can generate new source address out > of the given /64 at will. Er, that doesn't strike me as especially private. If there's a named device at that /64, I can pretty much use that subnet prefix to triangulate who the manufactured address is. I assume that many/most widgets will be named since they want to recieve INVITE's, and other peer-peer services. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 08:43:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54FhDV19920 for ipng-dist; Mon, 4 Jun 2001 08:43:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Fh9e19913 for ; Mon, 4 Jun 2001 08:43:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16688 for ; Mon, 4 Jun 2001 08:43:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09320 for ; Mon, 4 Jun 2001 09:42:55 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id CDE424B20; Tue, 5 Jun 2001 00:42:50 +0900 (JST) To: Michael Thomas Cc: Jari Arkko , ipng@sunroof.eng.sun.com In-reply-to: mat's message of Mon, 04 Jun 2001 08:38:52 MST. <15131.43916.485908.794477@thomasm-u1.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dialup PPP (material for interim meeting) From: itojun@iijlab.net Date: Tue, 05 Jun 2001 00:42:50 +0900 Message-ID: <22900.991669370@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Er, that doesn't strike me as especially private. If there's > a named device at that /64, I can pretty much use that subnet > prefix to triangulate who the manufactured address is. I assume > that many/most widgets will be named since they want to recieve > INVITE's, and other peer-peer services. if you want to accept inbound connections, i guess it is highly difficult to keep privacy anyways. what is your definition of "privacy" here? traffic analysis is inherently a hard problem. RFC3041 only solves (possible) issue (for those who cares) with EUI64-derived interface identifier, not others. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 08:50:11 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54FnX019986 for ipng-dist; Mon, 4 Jun 2001 08:49:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54FnUe19979 for ; Mon, 4 Jun 2001 08:49:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23825 for ; Mon, 4 Jun 2001 08:49:37 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06231 for ; Mon, 4 Jun 2001 08:49:36 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f54FnfU21083; Mon, 4 Jun 2001 08:49:41 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHI00074; Mon, 4 Jun 2001 08:49:31 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA09285; Mon, 4 Jun 2001 08:49:31 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15131.44555.517768.848625@thomasm-u1.cisco.com> Date: Mon, 4 Jun 2001 08:49:31 -0700 (PDT) To: itojun@iijlab.net Cc: Michael Thomas , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: dialup PPP (material for interim meeting) In-Reply-To: <22900.991669370@itojun.org> References: <15131.43916.485908.794477@thomasm-u1.cisco.com> <22900.991669370@itojun.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > > > Er, that doesn't strike me as especially private. If there's > > a named device at that /64, I can pretty much use that subnet > > prefix to triangulate who the manufactured address is. I assume > > that many/most widgets will be named since they want to recieve > > INVITE's, and other peer-peer services. > > if you want to accept inbound connections, i guess it is highly > difficult to keep privacy anyways. what is your definition of > "privacy" here? traffic analysis is inherently a hard problem. > RFC3041 only solves (possible) issue (for those who cares) with > EUI64-derived interface identifier, not others. You're probably right. I guess I find the whole concept of address privacy as it's constituted in RFC3041 to be pretty, well, underwhelming on the privacy front. If you want privacy, use an application layer anonymizer. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 10:10:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54HA4I20099 for ipng-dist; Mon, 4 Jun 2001 10:10:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54HA1e20092 for ; Mon, 4 Jun 2001 10:10:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09492 for ; Mon, 4 Jun 2001 10:10:08 -0700 (PDT) Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27008 for ; Mon, 4 Jun 2001 11:10:07 -0600 (MDT) Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.39 2001/05/18 00:47:02 root Exp $) with SMTP id RAA10761 for ; Mon, 4 Jun 2001 17:10:07 GMT Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.201 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 04 Jun 2001 17:10:07 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 10:10:05 -0700 Message-ID: From: "Dollinger, MatthewX" To: "Ipng Posts (E-mail)" Subject: interesting routing setup... Date: Mon, 4 Jun 2001 09:53:56 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am trying to setup a test network with the following layout (see diagram below). Subnet2----- Subnet1-----Subnet3 | | Subnet4 The routing tables are giving me no end of grief. I am familiar with routing on a linear network setup (sub1-->sub2-->sub3-->etc) but this one is being tough. Is there anything special for this type of layout? Thanks! Matthew Dollinger Ipv6/IPSec -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 10:42:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54HfpW20222 for ipng-dist; Mon, 4 Jun 2001 10:41:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Hfge20206; Mon, 4 Jun 2001 10:41:42 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02397; Mon, 4 Jun 2001 10:41:38 -0700 (PDT) Received: from malone.cisco.com (malone.cisco.com [171.70.157.157]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07033; Mon, 4 Jun 2001 10:41:37 -0700 (PDT) Received: from eagleswings (dhcp-171-70-71-64.cisco.com [171.70.71.64]) by malone.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA28324; Mon, 4 Jun 2001 10:41:36 -0700 (PDT) Reply-To: From: "Tony Hain" To: Cc: , Subject: Interim Meeting Logisics Date: Mon, 4 Jun 2001 10:41:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sandy, A quick note to say thanks for the logistical arrangements for the IPv6 interim meeting last week. While the rest of the MS gang directly heard the thanks for acting as hosts, we all know it is the behind the scene support that makes a meeting happen. On behalf of the WG chairs, Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 14:58:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54LvAQ20883 for ipng-dist; Mon, 4 Jun 2001 14:57:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Lv5e20876 for ; Mon, 4 Jun 2001 14:57:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19804 for ; Mon, 4 Jun 2001 14:57:11 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25370 for ; Mon, 4 Jun 2001 15:57:41 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f54Lv8O28845 for ; Mon, 4 Jun 2001 23:57:08 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Mon Jun 04 23:57:07 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Jun 2001 23:57:07 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEAB@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: [Q] Routing header Date: Mon, 4 Jun 2001 23:57:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > > > This is mostly a mipv6 issue, but suppose you have: > > > > > > MN------->MR------------------------>CN > > > > > > When the mobile node moves, it sends a BU to the CN. > > > When the mobile router moves, it too sends a BU to the CN. > > > > This is only your scenario. You could think of any scenario you want. > > Anyway, this is something I have already raised in the MIP WG and this > > is presumably a case where MIPv6 would fail. > > I'm aware that this is only my scenario, but this is > what I think a naive implementation would do. Ie, > the mobile router would think it's supposed to send > a BU when it see something come in from its home agent > tunnel interface, the MN (or another MR) would > think it's supposed to send a BU... > => There is nothing naive about the implementation you're referring to. In fact it is so far from naive that it's inventing it's own standard. Nothing in any of the MIP specs allows a MN/MR to send a BU on behalf of another MN. _If_ the WG were to accept a proposal like this we would have to make sure that there is some delegation of athority from the MN to the MR to do so. I have no idea how to do that though. I think what Thierry's draft is sufficient, if we want route optimisation I think we should keep it end to end as the MIPv6 draft requires it to be. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:04:57 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54M4WO21000 for ipng-dist; Mon, 4 Jun 2001 15:04:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54M4Te20993 for ; Mon, 4 Jun 2001 15:04:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19862 for ; Mon, 4 Jun 2001 15:04:35 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29328 for ; Mon, 4 Jun 2001 15:04:34 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA05447 for ; Mon, 4 Jun 2001 17:04:32 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f54M4Xp00345 for ; Mon, 4 Jun 2001 17:04:33 -0500 (CDT) Message-ID: <3B1C05EE.A59D94B6@usa.alcatel.com> Date: Mon, 04 Jun 2001 17:04:30 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: fragmentation in IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hai, I have a small doubt regarding fragmentation in IPv6. In Ipv6, even header can be fragmented. (with exception that fixed part of header should not be fragmented). .................. If a packet's header is fragmented, a new packet header is added to each fragment.But, once agin this new packet header should be fragmented..And this goes on recursively... ..... Can this problem occur in IPng? Thanks in advance, Sridhar. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:09:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54M8dN21046 for ipng-dist; Mon, 4 Jun 2001 15:08:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54M8Ye21039 for ; Mon, 4 Jun 2001 15:08:34 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20649 for ; Mon, 4 Jun 2001 15:08:41 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18896 for ; Mon, 4 Jun 2001 15:08:39 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 0660E7BB; Tue, 5 Jun 2001 07:08:18 +0900 (JST) To: Sridhar Gurivireddy Cc: ipng@sunroof.eng.sun.com In-reply-to: Sridhar.Gurivireddy's message of Mon, 04 Jun 2001 17:04:30 EST. <3B1C05EE.A59D94B6@usa.alcatel.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: fragmentation in IPv6 From: Jun-ichiro itojun Hagino Date: Tue, 05 Jun 2001 07:08:18 +0900 Message-Id: <20010604220819.0660E7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have a small doubt regarding fragmentation in IPv6. >In Ipv6, even header can be fragmented. >(with exception that fixed part of header should not be fragmented). >.................. >If a packet's header is fragmented, a new packet header is added to each >fragment.But, once agin this new packet header should be fragmented..And >this goes on recursively... packet fragmentation occurs only once, at the originating node. so there's no need to worry about the above scenario. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:21:00 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MKEm21150 for ipng-dist; Mon, 4 Jun 2001 15:20:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54MKBe21143 for ; Mon, 4 Jun 2001 15:20:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25599 for ; Mon, 4 Jun 2001 15:20:17 -0700 (PDT) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24568 for ; Mon, 4 Jun 2001 15:20:16 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA07112; Mon, 4 Jun 2001 17:20:16 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f54MKGp02591; Mon, 4 Jun 2001 17:20:17 -0500 (CDT) Message-ID: <3B1C099D.27E7D4D1@usa.alcatel.com> Date: Mon, 04 Jun 2001 17:20:13 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Stig Venaas CC: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 References: <3B1C05EE.A59D94B6@usa.alcatel.com> <20010604220819.0660E7BB@starfruit.itojun.org> <20010605001342.A15236@itea.ntnu.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk even if fragmentation done only at the source, it may have this problem because,..... say IP header(with extensions) is of size 4k!!!!! it's framented for the first time..... you get three pieces.. yu add header to each piece... each piece is now again >4k... so, fragmentation again.... Does this problem occur.. Thanks for the sharp response Stig Venaas wrote: > On Tue, Jun 05, 2001 at 07:08:18AM +0900, Jun-ichiro itojun Hagino wrote: > > > I have a small doubt regarding fragmentation in IPv6. > > >In Ipv6, even header can be fragmented. > > >(with exception that fixed part of header should not be fragmented). > > >.................. > > >If a packet's header is fragmented, a new packet header is added to each > > >fragment.But, once agin this new packet header should be fragmented..And > > >this goes on recursively... > > > > packet fragmentation occurs only once, at the originating node. > > so there's no need to worry about the above scenario. > > Also note that the minimum MTU for IPv6 is 1280 bytes. > > Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:34:28 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MXlw21219 for ipng-dist; Mon, 4 Jun 2001 15:33:47 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54MXje21212 for ; Mon, 4 Jun 2001 15:33:45 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f54MTtL07933 for ipng@sunroof.eng.sun.com; Mon, 4 Jun 2001 15:29:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54MDke21117 for ; Mon, 4 Jun 2001 15:13:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA13922 for ; Mon, 4 Jun 2001 15:13:53 -0700 (PDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10210 for ; Mon, 4 Jun 2001 16:13:51 -0600 (MDT) Received: by alfa.itea.ntnu.no id AAA0000003492; Tue, 5 Jun 2001 00:13:42 +0200 (MET DST) Date: Tue, 5 Jun 2001 00:13:42 +0200 From: Stig Venaas To: Jun-ichiro itojun Hagino Cc: Sridhar Gurivireddy , ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 Message-ID: <20010605001342.A15236@itea.ntnu.no> References: <3B1C05EE.A59D94B6@usa.alcatel.com> <20010604220819.0660E7BB@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20010604220819.0660E7BB@starfruit.itojun.org>; from itojun@iijlab.net on Tue, Jun 05, 2001 at 07:08:18AM +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jun 05, 2001 at 07:08:18AM +0900, Jun-ichiro itojun Hagino wrote: > > I have a small doubt regarding fragmentation in IPv6. > >In Ipv6, even header can be fragmented. > >(with exception that fixed part of header should not be fragmented). > >.................. > >If a packet's header is fragmented, a new packet header is added to each > >fragment.But, once agin this new packet header should be fragmented..And > >this goes on recursively... > > packet fragmentation occurs only once, at the originating node. > so there's no need to worry about the above scenario. Also note that the minimum MTU for IPv6 is 1280 bytes. Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:36:56 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MaQ421248 for ipng-dist; Mon, 4 Jun 2001 15:36:26 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54MaMe21241 for ; Mon, 4 Jun 2001 15:36:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07446 for ; Mon, 4 Jun 2001 15:36:29 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26364 for ; Mon, 4 Jun 2001 16:36:26 -0600 (MDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f54MaPO02759 for ; Tue, 5 Jun 2001 00:36:25 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jun 05 00:36:24 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 00:31:05 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEAC@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'itojun@iijlab.net'" , "'Michael Thomas'" Cc: "Jari Arkko (LMF)" , "'ipng@sunroof.eng.sun.com'" Subject: RE: dialup PPP (material for interim meeting) Date: Tue, 5 Jun 2001 00:36:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, going back to the original question, based on your implementation experience, would hosts use 3041 on a PPP link ? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:40:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MeCp21285 for ipng-dist; Mon, 4 Jun 2001 15:40:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Me7e21278 for ; Mon, 4 Jun 2001 15:40:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08611 for ; Mon, 4 Jun 2001 15:40:14 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29427 for ; Mon, 4 Jun 2001 16:40:12 -0600 (MDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f54MeBO03305 for ; Tue, 5 Jun 2001 00:40:11 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Jun 05 00:40:10 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 00:34:51 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEAD@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Date: Tue, 5 Jun 2001 00:40:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, Based on our private discussion in Seattle, think it would be useful to add a sending rule for mapped addresses as follows: - If the destination address is an IPv4-mapped IPv6 address, and - If the host is an IPv6-only host the source address MUST be an IPv6-translated address. Comments ? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:43:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54MgqY21303 for ipng-dist; Mon, 4 Jun 2001 15:42:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Mgle21296 for ; Mon, 4 Jun 2001 15:42:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27835 for ; Mon, 4 Jun 2001 15:42:53 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA21773 for ; Mon, 4 Jun 2001 16:43:23 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 8E2054B20; Tue, 5 Jun 2001 07:42:41 +0900 (JST) To: "Hesham Soliman (ERA)" Cc: "'Michael Thomas'" , "Jari Arkko (LMF)" , "'ipng@sunroof.eng.sun.com'" In-reply-to: Hesham.Soliman's message of Tue, 05 Jun 2001 00:36:24 +0200. <034BEFD03799D411A59F00508BDF7546013DBEAC@esealnt448.al.sw.ericsson.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dialup PPP (material for interim meeting) From: itojun@iijlab.net Date: Tue, 05 Jun 2001 07:42:41 +0900 Message-ID: <25742.991694561@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >going back to the original question, based on your >implementation experience, would hosts use 3041 >on a PPP link ? please declare which addressing policy is in your mind, otherwise we cannot even diagnose... from my point of view, (assuming that you will assign /64 to the network behind the dialup device) RFC3041 will be operated totally independently from dialup link. there's no real relationship/ interaction whatsoever. (see 2nd bullet on PPP draft section 2.4) if you try to assign /64 onto the dialup link, and use multilink subnet trick on dialup links attached to the ISP device, the story goes much more complicated (specifically DAD). i don't really like the approach personally, because it is a lot more complicated. (see 1st bullet on PPP draft section 2.4) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 15:53:18 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54Mqg521362 for ipng-dist; Mon, 4 Jun 2001 15:52:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Mqbe21355 for ; Mon, 4 Jun 2001 15:52:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29555 for ; Mon, 4 Jun 2001 15:52:44 -0700 (PDT) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09665 for ; Mon, 4 Jun 2001 15:52:43 -0700 (PDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f54MqgO04150 for ; Tue, 5 Jun 2001 00:52:42 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jun 05 00:52:40 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 00:47:21 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEB0@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'itojun@iijlab.net'" Cc: "'Michael Thomas'" , "Jari Arkko (LMF)" , "'ipng@sunroof.eng.sun.com'" Subject: RE: dialup PPP (material for interim meeting) Date: Tue, 5 Jun 2001 00:52:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >going back to the original question, based on your > >implementation experience, would hosts use 3041 > >on a PPP link ? > > please declare which addressing policy is in your mind, otherwise > we cannot even diagnose... > => Stateless address autoconfigration. If the interface id as assigned to the host during PPP negotation, would you still use RFC 3041 later ? Note, I'm not referring to a /64 assignment or multi-link subnets, just a simple /128 one. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 16:16:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f54NG4521524 for ipng-dist; Mon, 4 Jun 2001 16:16:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54NFxe21517 for ; Mon, 4 Jun 2001 16:15:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07822 for ; Mon, 4 Jun 2001 16:15:42 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA24498 for ; Mon, 4 Jun 2001 17:15:41 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3B8D14B20; Tue, 5 Jun 2001 08:15:36 +0900 (JST) To: "Hesham Soliman (ERA)" Cc: "'ipng@sunroof.eng.sun.com'" In-reply-to: Hesham.Soliman's message of Tue, 05 Jun 2001 00:52:39 +0200. <034BEFD03799D411A59F00508BDF7546013DBEB0@esealnt448.al.sw.ericsson.se> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: dialup PPP (material for interim meeting) From: itojun@iijlab.net Date: Tue, 05 Jun 2001 08:15:36 +0900 Message-ID: <25998.991696536@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => Stateless address autoconfigration. If the interface id > as assigned to the host during PPP negotation, would > you still use RFC 3041 later ? > Note, I'm not referring to a /64 assignment or multi-link > subnets, just a simple /128 one. multilink subnet issue should be diagnosed only after we diagnose situation without it, so let us take multilink subnet case aside... if you see /64 RA on dialup link, the link has the /64 prefix. so you can use RFC3041 after IPv6CP negotiation (don't forget to run DAD!). if you really really would like to hide your EUI64 from anyone, use random-number-generated EUI64 on IPv6CP too (to hide your IPv6CP from the adjacent ISP router). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 18:40:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f551c4o21830 for ipng-dist; Mon, 4 Jun 2001 18:38:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f551bwe21823 for ; Mon, 4 Jun 2001 18:37:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10228 for ; Mon, 4 Jun 2001 18:38:03 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA22555 for ; Mon, 4 Jun 2001 19:38:34 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:dd7f:eaff:d3cd:dffe]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id KAA01087; Tue, 5 Jun 2001 10:38:07 +0900 (JST) Date: Tue, 05 Jun 2001 10:35:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Sridhar Gurivireddy Cc: ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 In-Reply-To: <3B1C099D.27E7D4D1@usa.alcatel.com> References: <3B1C05EE.A59D94B6@usa.alcatel.com> <20010604220819.0660E7BB@starfruit.itojun.org> <20010605001342.A15236@itea.ntnu.no> <3B1C099D.27E7D4D1@usa.alcatel.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 04 Jun 2001 17:20:13 -0500, >>>>> Sridhar Gurivireddy said: > even if fragmentation done only at the source, > it may have this problem because,..... > say IP header(with extensions) is of size 4k!!!!! > it's framented for the first time..... > you get three pieces.. > yu add header to each piece... > each piece is now again >4k... > so, fragmentation again.... > Does this problem occur.. Yes, when the unfragmentable part of a packet is larger than the path MTU, fragmentation fails and you cannot send the packet. However, (at least through my operation experiences) we've never cared about the problem, since we've not seen any practical usage of such a pakcet with a long unfragmentale part. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 19:24:02 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f552NRJ21933 for ipng-dist; Mon, 4 Jun 2001 19:23:27 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f552NMe21926 for ; Mon, 4 Jun 2001 19:23:23 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id EAA15341; Tue, 5 Jun 2001 04:23:22 +0200 (MET DST) Date: Tue, 5 Jun 2001 04:23:16 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" To: "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <034BEFD03799D411A59F00508BDF7546013DBEAD@esealnt448.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Rich, > > Based on our private discussion in Seattle, think it would > be useful to add a sending rule for mapped addresses > as follows: > > - If the destination address is an IPv4-mapped IPv6 address, and > - If the host is an IPv6-only host > the source address MUST be an IPv6-translated address. I think this makes sense as long as we preface it very clearly with Nodes that implement SIIT (does not apply to other nodes) ... Without that preface adding these rules will do nothing but adding confusion. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 19:44:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f552htM21965 for ipng-dist; Mon, 4 Jun 2001 19:43:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f552hpe21958 for ; Mon, 4 Jun 2001 19:43:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA03382 for ; Mon, 4 Jun 2001 19:43:58 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA20057 for ; Mon, 4 Jun 2001 20:44:27 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f552htN08783 for ; Tue, 5 Jun 2001 04:43:55 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jun 05 04:43:54 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 04:43:54 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBEB8@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" Cc: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" Date: Tue, 5 Jun 2001 04:43:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > Based on our private discussion in Seattle, think it would > > be useful to add a sending rule for mapped addresses > > as follows: > > > > - If the destination address is an IPv4-mapped IPv6 address, and > > - If the host is an IPv6-only host > > the source address MUST be an IPv6-translated address. > > I think this makes sense as long as we preface it very clearly with > Nodes that implement SIIT (does not apply to other nodes) ... > => Agreed, that's where it would be relevant. > Without that preface adding these rules will do nothing but adding confusion. > => So if the node is not implementing SIIT then I guess communication is not possible in the scenario above. Is this a correct understanding ? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 19:58:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f552wOZ21989 for ipng-dist; Mon, 4 Jun 2001 19:58:24 -0700 (PDT) Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f552wJe21982 for ; Mon, 4 Jun 2001 19:58:19 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id EAA16642; Tue, 5 Jun 2001 04:58:19 +0200 (MET DST) Date: Tue, 5 Jun 2001 04:58:14 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" To: "Hesham Soliman (ERA)" Cc: "'Erik Nordmark'" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <034BEFD03799D411A59F00508BDF7546013DBEB8@esealnt448.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => So if the node is not implementing SIIT then I guess communication > is not possible in the scenario above. Is this a correct understanding ? When an application on a dual-stack node sends to an IPv4-mapped address the result is that the box is communicating using IPv4 packets. When an application on an IPv6-only box which implements SIIT does this the result is to send IPv6 packets (with an IPv4-mapped dest and an IPv4-translatable source) to the SIIT translator box, which will translate those to IPv4 packets. When an application on an IPv6 only box which does not implement SIIT sends to an IPv4-mapped address then communication doesn't happen - presumably the stack would drop the packets and tell the application. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 4 22:07:06 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5556Wu22063 for ipng-dist; Mon, 4 Jun 2001 22:06:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5556Te22056 for ; Mon, 4 Jun 2001 22:06:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA28670 for ; Mon, 4 Jun 2001 22:06:37 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id XAA22960 for ; Mon, 4 Jun 2001 23:07:07 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA28888; Tue, 5 Jun 2001 01:06:35 -0400 Date: Tue, 5 Jun 2001 01:06:35 -0400 (EDT) From: Jim Bound To: ipng@sunroof.eng.sun.com Subject: Interim meeting Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chairs, Great meeting. Look forward to the minutes. And Microsoft did a par excellence job hosting us across the board. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 00:05:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5574mt22155 for ipng-dist; Tue, 5 Jun 2001 00:04:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5574je22148 for ; Tue, 5 Jun 2001 00:04:45 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01644 for ; Tue, 5 Jun 2001 00:04:52 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA21845 for ; Tue, 5 Jun 2001 00:04:52 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA09930; Tue, 5 Jun 2001 00:04:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5574pU25737; Tue, 5 Jun 2001 00:04:51 -0700 X-mProtect: Tue, 5 Jun 2001 00:04:51 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.44.21, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdUsJHvM; Tue, 05 Jun 2001 00:04:48 PDT Message-Id: <4.3.2.7.2.20010605000335.023a4e20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jun 2001 00:04:16 -0700 To: Jim Bound From: Bob Hinden Subject: Re: Interim meeting Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, Thanks. Many thanks to our hosts from Microsoft for hosting the meeting!!! Bob At 01:06 AM 6/5/2001 -0400, Jim Bound wrote: >Chairs, > >Great meeting. Look forward to the minutes. And Microsoft did a par >excellence job hosting us across the board. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 00:17:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f557GTm22185 for ipng-dist; Tue, 5 Jun 2001 00:16:29 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f557GOe22178 for ; Tue, 5 Jun 2001 00:16:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19698 for ; Tue, 5 Jun 2001 00:16:05 -0700 (PDT) Received: from dns1.catt.ac.cn ([202.106.106.98]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA03906 for ; Tue, 5 Jun 2001 01:16:01 -0600 (MDT) Received: from liangxg (202.106.106.126 [202.106.106.126]) by dns1.catt.ac.cn with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LPMJYMCD; Tue, 5 Jun 2001 15:10:19 +0800 Message-ID: <016301c0ed8f$21b218c0$75ce12ac@MCSD.local> From: "Xingang Liang" To: Subject: To Bob Hinden Date: Tue, 5 Jun 2001 15:14:11 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0160_01C0EDD2.2CE0F7F0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0160_01C0EDD2.2CE0F7F0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksQm9iLEkgd29uZGVyIHRoZSBtaW51dGVzIG9mIElFVEYgSVB2NiBpbnRlcmltIG1lZXRpbmcg d2lsbCBiZSBzZW50IG91dCBpbnRvIHRoaXMgbWFpbCBsaXN0Pw0KSWYgeWVzLHdoYXQgaXMgdGhl IHRpbWUgdGhhdCBJIGNhbiByZWFkIGl0Pw0KDQpCZXN0IFJlZ2FyZHMNCg0KDQpYaW5nYW5nIExp YW5nDQpTdGFuZGFyZGl6YXRpb24gRGVwYXJ0bWVudA0KTW9iaWxlIENvbW11bmljYXRpb24gUiZE IENlbnRlcg0KQ2hpbmEgQWNhZGVteSBvZiBUZWxlY29tbXVuaWNhdGlvbiBUZWNobm9sb2d5KENB VFQpDQpOby40MCxYdWV5dWFuIFJvYWQNCkJlaWppbmcsQ2hpbmENCjEwMDA4Mw0KVGVsOis4NjEw IDYyMzA0NDIyRVhUMjI1DQpGYXg6Kzg2MTAgNjIzMDMxMjcNCk1haWx0bzpsaWFuZ3hnQGNhdHQu YWMuY24NCiANCiANCg== ------=_NextPart_000_0160_01C0EDD2.2CE0F7F0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdi MjMxMiIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+PEJBU0UgDQpocmVmPSJmaWxlOi8vQzpcUHJv Z3JhbSBGaWxlc1xDb21tb24gRmlsZXNcTWljcm9zb2Z0IFNoYXJlZFxTdGF0aW9uZXJ5XCI+DQo8 U1RZTEU+Qk9EWSB7DQoJQkFDS0dST1VORC1QT1NJVElPTjogbGVmdCB0b3A7IEJBQ0tHUk9VTkQt UkVQRUFUOiBuby1yZXBlYXQ7IENPTE9SOiAjMDAwMDAwOyBGT05ULUZBTUlMWTogQ291cmllciBO ZXcgQ0U7IEZPTlQtU0laRTogMTBwdDsgTUFSR0lOLUxFRlQ6IDI1cHg7IE1BUkdJTi1UT1A6IDI1 cHgNCn0NCjwvU1RZTEU+DQoNCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA1LjAwLjMxMDMuMTAwMCIg bmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj5IaSxC b2IsSSB3b25kZXIgdGhlIG1pbnV0ZXMgb2YgSUVURiBJUHY2IGludGVyaW0gbWVldGluZyB3aWxs IGJlIHNlbnQgb3V0IA0KaW50byB0aGlzIG1haWwgbGlzdD88L0RJVj4NCjxESVY+SWYgeWVzLHdo YXQgaXMgdGhlIHRpbWUgdGhhdCBJIGNhbiByZWFkIGl0PzwvRElWPg0KPERJVj4mbmJzcDs8L0RJ Vj4NCjxESVY+QmVzdCBSZWdhcmRzPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4mbmJz cDs8L0RJVj4NCjxESVY+WGluZ2FuZyBMaWFuZzxCUj5TdGFuZGFyZGl6YXRpb24gRGVwYXJ0bWVu dDxCUj5Nb2JpbGUgQ29tbXVuaWNhdGlvbiBSJmFtcDtEIA0KQ2VudGVyPEJSPkNoaW5hIEFjYWRl bXkgb2YgVGVsZWNvbW11bmljYXRpb24gVGVjaG5vbG9neShDQVRUKTxCUj5Oby40MCxYdWV5dWFu IA0KUm9hZDxCUj5CZWlqaW5nLENoaW5hPEJSPjEwMDA4MzxCUj5UZWw6Kzg2MTAgNjIzMDQ0MjJF WFQyMjU8QlI+RmF4Ois4NjEwIA0KNjIzMDMxMjc8QlI+PEEgDQpocmVmPSJtYWlsdG86bGlhbmd4 Z0BjYXR0LmFjLmNuIj5NYWlsdG86bGlhbmd4Z0BjYXR0LmFjLmNuPC9BPjxCUj4mbmJzcDs8QlI+ Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_0160_01C0EDD2.2CE0F7F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 03:54:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55As0I22378 for ipng-dist; Tue, 5 Jun 2001 03:54:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Ar0e22341; Tue, 5 Jun 2001 03:53:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18097; Tue, 5 Jun 2001 03:53:05 -0700 (PDT) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18184; Tue, 5 Jun 2001 04:53:35 -0600 (MDT) Received: from yjkim2 (kimyj.etri.re.kr [129.254.164.113]) by pec.etri.re.kr (8.10.0/8.10.0) with SMTP id f55AsUZ02052; Tue, 5 Jun 2001 19:54:30 +0900 (KST) Message-ID: <02df01c0edaf$60a7e710$71a4fe81@yjkim2> From: "Dr. Yong-Jin Kim" To: , <6winit@cs.ucl.ac.uk>, , , , Subject: Global IPv6 Summit in Seoul Date: Tue, 5 Jun 2001 20:05:05 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02DC_01C0EDFA.D0587980" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_02DC_01C0EDFA.D0587980 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNClRoaXMgaXMgYSByZW1pbmRlciB0aGF0IHRoZSBuZXh0IEdsb2JhbCBJUHY2 IFN1bW1pdCB3aWxsIGJlIGhlbGQgaW4NClNlb3VsIEp1bHkgMyAtIDYuIA0KDQpGb3IgdGhlIGNv bmZlcmVuY2UgcHJvZ3JhbSwgbmV3IHByZS1jb25mZXJlbmNlIHR1dG9yaWFsLCBhbmQgcmVnaXN0 cmF0aW9uDQpzZWUgaHR0cDovL3d3dy5pcHY2Lm9yLmtyL2lwdjZzdW1taXQNCg0KSW4ga2VlcGlu ZyB3aXRoIElQdjYgRm9ydW0ncyBtaXNzaW9uIHRvIGluY3JlYXNlIGF3YXJlbmVzcyBvZiBJUHY2 LCBwbGVhc2UNCnRha2UgYSBtaW51dGUgdG8gY29uc2lkZXIgd2hvIGFtb25nIHlvdXIgY29sbGVh Z3VlcyANCmNvdWxkIGJlbmVmaXQgZnJvbSB0aGlzIFN1bW1pdCBvcHBvcnR1bml0eSwgYW5kIGZv cndhcmQgdGhlbSB0aGlzIGNvbmZlcmVuY2UgaW5mb3JtYXRpb24uIA0KDQpSZWdhcmRzLA0KDQpZ b25nLUppbiBLaW0NCklQdjYgRm9ydW0NClByZXNpZGVudCBvZiBJUHY2IEZvcnVtIEtvcmVhDQoN Cg== ------=_NextPart_000_02DC_01C0EDFA.D0587980 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MIHhtbG5zOm8gPSAidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 b2ZmaWNlIj48SEVBRD4NCjxNRVRBIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD1rc19jXzU2MDEtMTk4NyI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwg NS41MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+ DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9ND48U1BBTiBsYW5nPUVO LVVTIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIA0Kc2l6ZT0z PkRlYXIgYWxsLDwvRk9OVD48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTQ+ PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48 Rk9OVCANCnNpemU9Mz48L0ZPTlQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZP TlQgc2l6ZT00PjxTUEFOIGxhbmc9RU4tVVMgc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3 IFJvbWFuJyI+PEZPTlQgDQpzaXplPTM+VGhpcyBpcyBhIHJlbWluZGVyIHRoYXQgdGhlIG5leHQg R2xvYmFsIElQdjYgU3VtbWl0IHdpbGwgYmUgaGVsZCANCmluPEJSPlNlb3VsIEp1bHkgMyAtIDYu IDxCUj48QlI+Rm9yIHRoZSBjb25mZXJlbmNlIHByb2dyYW0sIG5ldyBwcmUtY29uZmVyZW5jZSAN CnR1dG9yaWFsLCBhbmQgcmVnaXN0cmF0aW9uPEJSPnNlZSA8L0ZPTlQ+PEEgDQpocmVmPSJodHRw Oi8vd3d3LmZvcmV0ZWMuY29tL0lQdjYtaW5kZXguaHRtIj48Rk9OVCBzaXplPTM+PEEgDQpocmVm PSJodHRwOi8vd3d3LmlwdjYub3Iua3IvaXB2NnN1bW1pdCI+aHR0cDovL3d3dy48L0ZPTlQ+PC9B PjxGT05UIA0Kc2l6ZT0zPmlwdjYub3Iua3IvaXB2NnN1bW1pdDwvQT48QlI+PEJSPkluIGtlZXBp bmcgd2l0aCZuYnNwO0lQdjYgRm9ydW0ncyANCm1pc3Npb24gdG8gaW5jcmVhc2UgYXdhcmVuZXNz IG9mIElQdjYsIHBsZWFzZTxCUj50YWtlIGEgbWludXRlIHRvIGNvbnNpZGVyIHdobyANCmFtb25n IHlvdXIgY29sbGVhZ3VlcyA8QlI+Y291bGQgYmVuZWZpdCBmcm9tIHRoaXMgU3VtbWl0IG9wcG9y dHVuaXR5LCBhbmQgDQpmb3J3YXJkIHRoZW0gdGhpcyBjb25mZXJlbmNlIGluZm9ybWF0aW9uLiA8 QlI+PEJSPlJlZ2FyZHMsPEJSPjxCUj5Zb25nLUppbiANCktpbTwvRk9OVD48L1NQQU4+PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTQ+PFNQQU4gbGFuZz1FTi1VUyBzdHlsZT0iRk9OVC1G QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nIj48Rk9OVCANCnNpemU9Mz5JUHY2IEZvcnVtPC9GT05U PjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9ND48U1BBTiBsYW5nPUVOLVVT IHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbiciPjxGT05UIA0Kc2l6ZT0zPlBy ZXNpZGVudCBvZiBJUHY2IEZvcnVtIA0KS29yZWE8L0ZPTlQ+PEJSPjwvU1BBTj48L0ZPTlQ+PC9E SVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_02DC_01C0EDFA.D0587980-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 07:16:09 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55EE5C22724 for ipng-dist; Tue, 5 Jun 2001 07:14:05 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55EE1e22717 for ; Tue, 5 Jun 2001 07:14:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09109 for ; Tue, 5 Jun 2001 07:14:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23055 for ; Tue, 5 Jun 2001 08:14:04 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA25154; Tue, 5 Jun 2001 07:14:04 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f55EDxX14524; Tue, 5 Jun 2001 07:13:59 -0700 X-mProtect: Tue, 5 Jun 2001 07:13:59 -0700 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.44.21, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdBRcD2L; Tue, 05 Jun 2001 07:13:56 PDT Message-Id: <4.3.2.7.2.20010605071222.020f4cd0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 05 Jun 2001 07:13:23 -0700 To: "Xingang Liang" From: Bob Hinden Subject: Re: To Bob Hinden Cc: ipng@sunroof.eng.sun.com In-Reply-To: <016301c0ed8f$21b218c0$75ce12ac@MCSD.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, they will be sent to the IPng list. I expect to have them out late this week. Bob At 03:14 PM 6/5/2001 +0800, Xingang Liang wrote: >Hi,Bob,I wonder the minutes of IETF IPv6 interim meeting will be sent out >into this mail list? >If yes,what is the time that I can read it? > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 09:48:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55Glr622997 for ipng-dist; Tue, 5 Jun 2001 09:47:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Glne22990 for ; Tue, 5 Jun 2001 09:47:49 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26517 for ; Tue, 5 Jun 2001 09:47:56 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19444 for ; Tue, 5 Jun 2001 10:48:26 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA91762 for ; Tue, 5 Jun 2001 12:41:16 -0500 Received: from d04mc300.raleigh.ibm.com (d04mc300.raleigh.ibm.com [9.67.228.190]) by southrelay02.raleigh.ibm.com (8.11.1/NCO v4.96) with ESMTP id f55GlsX78396 for ; Tue, 5 Jun 2001 12:47:54 -0400 Importance: Normal Subject: IPv6_UNICAST_HOPS and IPV6_HOPLIMT To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Lori Napoli" Date: Tue, 5 Jun 2001 12:45:31 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/05/2001 12:47:53 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can someone explain how the two options IPv6_UNICAST_HOPS and IPv6_HOPLIMIT work together. Does IPv6_UNICAST_HOPS override IPV6_HOPLIMIT ? And IPv6_HOPLIMIT overrides the system configured default? Thanks Lori z/OS Communications Server Development - TCP/IP Stack 919-254-6146 T/L 8-444-6146 E-mail: lanapoli@us.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 12:48:59 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55JlUi23378 for ipng-dist; Tue, 5 Jun 2001 12:47:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55JlQe23371 for ; Tue, 5 Jun 2001 12:47:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28940 for ; Tue, 5 Jun 2001 12:47:32 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24730 for ; Tue, 5 Jun 2001 12:47:31 -0700 (PDT) Received: from onatopp.cisco.com (onatopp.cisco.com [198.135.0.157]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f55JlNU28296; Tue, 5 Jun 2001 12:47:24 -0700 (PDT) Received: (otroan@localhost) by onatopp.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA00553; Tue, 5 Jun 2001 20:47:19 +0100 (BST) X-Authentication-Warning: onatopp.cisco.com: otroan set sender to ot@cisco.com using -f To: "Hesham Soliman (ERA)" Cc: "'itojun@iijlab.net'" , "'Michael Thomas'" , "Jari Arkko (LMF)" , "'ipng@sunroof.eng.sun.com'" Subject: Re: dialup PPP (material for interim meeting) References: <034BEFD03799D411A59F00508BDF7546013DBEB0@esealnt448.al.sw.ericsson.se> From: Ole Troan Date: 05 Jun 2001 20:47:19 +0100 In-Reply-To: "Hesham Soliman's message of "Tue, 5 Jun 2001 00:52:39 +0200" Message-ID: <7t5hexulneg.fsf@onatopp.cisco.com> Lines: 19 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, > > >going back to the original question, based on your > > >implementation experience, would hosts use 3041 > > >on a PPP link ? > > > > please declare which addressing policy is in your mind, otherwise > > we cannot even diagnose... > > > => Stateless address autoconfigration. If the interface id > as assigned to the host during PPP negotation, would > you still use RFC 3041 later ? > Note, I'm not referring to a /64 assignment or multi-link > subnets, just a simple /128 one. current stateless address autoconfiguration does not allow assignment of a /128. i.e prefixes where the prefix length in the RA is 128. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 13:12:55 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55KBp923437 for ipng-dist; Tue, 5 Jun 2001 13:11:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55KBle23430 for ; Tue, 5 Jun 2001 13:11:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15325 for ; Tue, 5 Jun 2001 13:11:54 -0700 (PDT) Received: from mail.ipf.es ([62.164.0.20]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA17095 for ; Tue, 5 Jun 2001 14:11:52 -0600 (MDT) Received: (qmail 4162 invoked from network); 5 Jun 2001 20:15:44 -0000 Received: from consulintel.customer.pool4.infovia.gigabell.es (HELO consulintel.es) (62.164.5.2) by mail.ipf.es with SMTP; 5 Jun 2001 20:15:44 -0000 Received: from consulintel02 [193.152.174.62] by consulintel.es [127.0.0.1] with SMTP (MDaemon.v3.5.2.R) for ; Tue, 05 Jun 2001 22:06:49 +0200 Message-ID: <014001c0edfa$ecbf70b0$8700000a@consulintel02> Reply-To: "JORDI PALET MARTINEZ" From: "JORDI PALET MARTINEZ" To: "Sridhar Gurivireddy" Cc: Subject: Re: fragmentation in IPv6 Date: Tue, 5 Jun 2001 22:05:51 +0200 Organization: Consulintel MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MDRemoteIP: 193.152.174.62 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the other way, if this happens, the fragmentation will be carried out at the link layer, if I'm not wrong ? Thanks and best regards, Jordi Palet Consulintel http://www.consulintel.es Tel: 91 151 81 99 - Fax: 91 151 81 98 ----- Original Message ----- From: )> To: "Sridhar Gurivireddy" Cc: Sent: Tuesday, June 05, 2001 3:35 AM Subject: Re: fragmentation in IPv6 > >>>>> On Mon, 04 Jun 2001 17:20:13 -0500, > >>>>> Sridhar Gurivireddy said: > > > even if fragmentation done only at the source, > > it may have this problem because,..... > > say IP header(with extensions) is of size 4k!!!!! > > it's framented for the first time..... > > you get three pieces.. > > yu add header to each piece... > > each piece is now again >4k... > > so, fragmentation again.... > > Does this problem occur.. > > Yes, when the unfragmentable part of a packet is larger than the path > MTU, fragmentation fails and you cannot send the packet. However, > (at least through my operation experiences) we've never cared about > the problem, since we've not seen any practical usage of such a pakcet > with a long unfragmentale part. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > ----------------------------------------------------------------------------------------------------------- La UE se encamina a IPv6: www.ipv6tf.org Más información de IPv6 en www.consulintel.es/ipv6 Contrate con nosotros sus productos de Telefonica -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 13:23:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55KMO523480 for ipng-dist; Tue, 5 Jun 2001 13:22:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55KMKe23473 for ; Tue, 5 Jun 2001 13:22:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05659 for ; Tue, 5 Jun 2001 13:22:26 -0700 (PDT) Received: from fw1-a.osis.gov (fw1-a.osis.gov [204.178.104.233]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10622 for ; Tue, 5 Jun 2001 13:22:26 -0700 (PDT) Received: from neptune.jioc.osis.gov by fw1-a.osis.gov with ESMTP id QAA06527 (InterLock SMTP Gateway 4.2 for osis.gov); Tue, 5 Jun 2001 16:22:25 -0400 (EDT) Received: by neptune.jioc.osis.gov with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Jun 2001 15:21:21 -0500 Message-ID: From: "SESVOLD, DALE" To: ipng@sunroof.eng.sun.com, "'users@ipv6.org'" Subject: DNS Discovery for IPv6 Date: Tue, 5 Jun 2001 15:21:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0EDFD.1526B540" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0EDFD.1526B540 Content-Type: text/plain; charset="iso-8859-1" Can anyone tell me what documents (draft or otherwise) are available for DNS DISCOVERY on IPv6? Thanks | DALE G SESVOLD | Senior Network Engineer | MacAulay-Brown, Inc. | Joint Information Operations Center | J61, Information Operations Technical Analysis ------_=_NextPart_001_01C0EDFD.1526B540 Content-Type: text/html; charset="iso-8859-1" DNS Discovery for IPv6

Can anyone tell me what documents (draft or otherwise) are available for DNS DISCOVERY on IPv6?

Thanks

| DALE G SESVOLD
| Senior Network Engineer
| MacAulay-Brown, Inc.
| Joint Information Operations Center
| J61, Information Operations Technical Analysis

------_=_NextPart_001_01C0EDFD.1526B540-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 13:34:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55KXPf23516 for ipng-dist; Tue, 5 Jun 2001 13:33:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55KXMe23509 for ; Tue, 5 Jun 2001 13:33:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18480 for ; Tue, 5 Jun 2001 13:33:29 -0700 (PDT) Received: from pimout4-int.prodigy.net (pimout4-ext.prodigy.net [207.115.63.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21989 for ; Tue, 5 Jun 2001 13:33:28 -0700 (PDT) Received: from jim (ip-111-152-148.chicago-n.navipath.net [64.111.152.148]) by pimout4-int.prodigy.net (8.11.0/8.11.0) with SMTP id f55KXOS185296; Tue, 5 Jun 2001 16:33:25 -0400 From: "JIM FLEMING" To: "SESVOLD, DALE" , , Subject: RE: DNS Discovery for IPv6 Date: Tue, 5 Jun 2001 15:34:38 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We "discovered" a whole bunch of interesting IPv16-compliant domain names at http://www.New.Net :-) Jim Fleming http://www.Arizona.Chat http://www.DOT-Arizona.com http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of SESVOLD, DALE Sent: Tuesday, June 05, 2001 3:21 PM To: ipng@sunroof.eng.sun.com; 'users@ipv6.org' Subject: DNS Discovery for IPv6 Can anyone tell me what documents (draft or otherwise) are available for DNS DISCOVERY on IPv6? Thanks | DALE G SESVOLD | Senior Network Engineer | MacAulay-Brown, Inc. | Joint Information Operations Center | J61, Information Operations Technical Analysis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 13:36:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55KaA623537 for ipng-dist; Tue, 5 Jun 2001 13:36:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Ka5e23530 for ; Tue, 5 Jun 2001 13:36:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21862 for ; Tue, 5 Jun 2001 13:36:12 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17046 for ; Tue, 5 Jun 2001 13:36:11 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f55KaAN05605 for ; Tue, 5 Jun 2001 22:36:10 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Jun 05 22:36:09 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 22:36:09 +0200 Message-ID: <034BEFD03799D411A59F00508BDF7546013DBED3@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Ole Troan'" Cc: "'itojun@iijlab.net'" , "'Michael Thomas'" , "Jari Arkko (LMF)" , "'ipng@sunroof.eng.sun.com'" Subject: RE: dialup PPP (material for interim meeting) Date: Tue, 5 Jun 2001 22:36:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole, > > > >going back to the original question, based on your > > > >implementation experience, would hosts use 3041 > > > >on a PPP link ? > > > > > > please declare which addressing policy is in your mind, otherwise > > > we cannot even diagnose... > > > > > => Stateless address autoconfigration. If the interface id > > as assigned to the host during PPP negotation, would > > you still use RFC 3041 later ? > > Note, I'm not referring to a /64 assignment or multi-link > > subnets, just a simple /128 one. > > current stateless address autoconfiguration does not allow assignment > of a /128. i.e prefixes where the prefix length in the RA is 128. > => Sure, but I wasn't referring to a prefix length of 128 I was referring to assigning one address to a host on a ppp link. A /128 given to a host. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 14:08:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55L7hp23614 for ipng-dist; Tue, 5 Jun 2001 14:07:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55L7de23607 for ; Tue, 5 Jun 2001 14:07:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA27363 for ; Tue, 5 Jun 2001 14:06:32 -0700 (PDT) Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22873 for ; Tue, 5 Jun 2001 15:07:02 -0600 (MDT) Received: from us-ea-gtwy-6.ea.unisys.com (us-ea-gtwy-6.ea.unisys.com [192.61.146.102]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id VAA15236; Tue, 5 Jun 2001 21:04:08 GMT Received: by us-ea-gtwy-6.ea.unisys.com with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Jun 2001 16:04:21 -0500 Message-ID: <236F133B43F4D211A4B00090273C79DC077BCCD2@us-rv-exch-2.rsvl.unisys.com> From: "Sellers, Julian P" To: "'Thomas Narten'" Cc: "'itojun@iijlab.net'" , "'ipng@sunroof.eng.sun.com'" Subject: RE: DAD Date: Tue, 5 Jun 2001 16:04:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, Is there a problem with requiring nodes to perform DAD on the link-local address generated from a given interface identifier, even if they only want to use the site-local or the global address? That's what I thought the following sentences from 5.4 of RFC 2462 required: Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. It's not clear to me what the qualifier "In such cases" refers to. Maybe this paragraph just needs to state clearly that - If a node has successfully performed DAD on a link-local address, the node has the right to all addresses on the same link that contain the same interface identifier. - If a node has not performed DAD on the link-local address, or if the link-local address has failed DAD, the node must not use any address on that link generated with the same interface identifier. Julian > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Friday, June 01, 2001 1:47 PM > To: itojun@iijlab.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: DAD > > > Here is a suggestion for how to plug the main vulnerabilities that > were discussed in the meeting. > > Problem (as I understand it): the main issue is that there are some > (non-link local scope) addresses that may be assigned to an interface > (e.g., manually configured, temporary addresses, DHCP assigned, etc.), > but for which there is no corresponding link-local address using the > same interface identifier. The stateless addrconf document (RFC 2462) > says that a node can skip DAD for global (and site local) scope > addresses generated from the same interface ID as the link-local > address. This opens up a potential hole where a node (doing normal > addrconf) has run DAD on the link-local address, but has not yet > configured a global-scope address using the same interface > identifier. Then, some other node (e.g., via DHCP, a temporary address > etc.) chooses the same interface identifier and creates such an > address, runs DAD successfully (since no other node is currently using > that address), and then assigns the address to its interface. Later, > the first node (which is running normal addrconf) also generates the > address, but skips DAD, and now there are two nodes using the same > address. Oops. > > Proposal: update specs to require that nodes MUST run DAD on all > addresses for which the interface identifier is NOT globally unique > (per the setting of the 'u' bit in interface identifier). DAD can be > skipped on addresses that contain IEEE EUI-64-derived interface > identifiers (and for which DAD has already been run on the > corresponding link-local address). > > This means: still no need to run DAD on global addresses when doing > normal addrconf, provided the interface identifier comes from an IEEE > identifier. But one would have to run DAD for links with randomly > generated identifiers (e.g., some PPP links). One would also still > need to run DAD for temporary addresses. For DHCP addresses, we'd need > to make sure that the server sets the 'u' bit properly, and clients > would need to run DAD if the 'u' bit indicated locally unique only. > > Does this solve the underlying problem in an acceptable fashion? > > Thomas > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 15:19:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55MIss23973 for ipng-dist; Tue, 5 Jun 2001 15:18:54 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55MIqe23966 for ; Tue, 5 Jun 2001 15:18:53 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f55MF2f08361 for ipng@sunroof.eng.sun.com; Tue, 5 Jun 2001 15:15:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f54Mmse21314 for ; Mon, 4 Jun 2001 15:48:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10483 for ; Mon, 4 Jun 2001 15:49:01 -0700 (PDT) Received: from alfa.itea.ntnu.no (alfa.itea.ntnu.no [129.241.18.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA07894 for ; Mon, 4 Jun 2001 15:49:00 -0700 (PDT) Received: by alfa.itea.ntnu.no id AAA0000002427; Tue, 5 Jun 2001 00:48:46 +0200 (MET DST) Date: Tue, 5 Jun 2001 00:48:46 +0200 From: Stig Venaas To: Sridhar Gurivireddy Cc: Stig Venaas , Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 Message-ID: <20010605004846.A7467@itea.ntnu.no> References: <3B1C05EE.A59D94B6@usa.alcatel.com> <20010604220819.0660E7BB@starfruit.itojun.org> <20010605001342.A15236@itea.ntnu.no> <3B1C099D.27E7D4D1@usa.alcatel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3B1C099D.27E7D4D1@usa.alcatel.com>; from Sridhar.Gurivireddy@usa.alcatel.com on Mon, Jun 04, 2001 at 05:20:13PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jun 04, 2001 at 05:20:13PM -0500, Sridhar Gurivireddy wrote: > even if fragmentation done only at the source, > it may have this problem because,..... > say IP header(with extensions) is of size 4k!!!!! > it's framented for the first time..... > you get three pieces.. > yu add header to each piece... > each piece is now again >4k... > so, fragmentation again.... > Does this problem occur.. > Thanks for the sharp response It's not exactly recursion. The only problem I see, is if the size of the IPv6 header plus hop-by-hop options and routing header (the headers that must be inspected by routers) plus fragmentation header is >= path MTU. This is explained in RFC 2460. The path MTU is guaranteed to be at least 1280. Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 16:46:54 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f55Njoq24323 for ipng-dist; Tue, 5 Jun 2001 16:45:50 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f55Njke24316 for ; Tue, 5 Jun 2001 16:45:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02943 for ; Tue, 5 Jun 2001 16:45:49 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA19670 for ; Tue, 5 Jun 2001 16:45:49 -0700 (PDT) Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Jun 2001 16:36:53 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 5 Jun 2001 16:39:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DNS Discovery for IPv6 Date: Tue, 5 Jun 2001 16:38:58 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS Discovery for IPv6 thread-index: AcDt/fcUI348zLllTvG3mSrQZE8FdwAGpaDg From: "Brian Zill" To: "SESVOLD, DALE" , , X-OriginalArrivalTime: 05 Jun 2001 23:39:06.0456 (UTC) FILETIME=[B5E31D80:01C0EE18] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f55Njle24317 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See http://search.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-0 1.txt, "Analysis of DNS Server Discovery Mechanisms for IPv6". -----Original Message----- From: SESVOLD, DALE [mailto:dale.sesvold@jioc.osis.gov] Sent: Tuesday, 05 June, 2001 13:21 To: ipng@sunroof.eng.sun.com; 'users@ipv6.org' Subject: DNS Discovery for IPv6 Can anyone tell me what documents (draft or otherwise) are available for DNS DISCOVERY on IPv6? Thanks | DALE G SESVOLD | Senior Network Engineer | MacAulay-Brown, Inc. | Joint Information Operations Center | J61, Information Operations Technical Analysis -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 17:03:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56030F24384 for ipng-dist; Tue, 5 Jun 2001 17:03:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5602We24362; Tue, 5 Jun 2001 17:02:32 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06596; Tue, 5 Jun 2001 17:02:40 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26223; Tue, 5 Jun 2001 17:02:39 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id JAA01310; Wed, 6 Jun 2001 09:02:37 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id JAA09544; Wed, 6 Jun 2001 09:02:37 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id JAA00403; Wed, 6 Jun 2001 09:02:37 +0900 (JST) Date: Wed, 06 Jun 2001 09:02:55 +0900 (JST) Message-Id: <20010606.090255.98580503.kazu@iijlab.net> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: IPv6 ShowCase, N+I Tokyo From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b125 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello guys, The IPv6 community in Japan will have the IPv6 ShowCase booth at N+I Tokyo this year, too. N+I will be open today (6/6) and end in Friday (7/8). Highlights of this booth include: Inter-operability test of OSPFv3 New datalink -- GbE, FE, POS, ATM, DSL, ... Electric Appliance (IPv4 ready, of course) Phone, FAX, TV, remote camera, temperature sensor ... InternetCAR If you are interested, please gain access to http://kame.showcase.jp.interop.net/photos/ by either IPv6 or IPv4. More photographs are coming soon. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 17:06:38 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56067V24405 for ipng-dist; Tue, 5 Jun 2001 17:06:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56063e24398 for ; Tue, 5 Jun 2001 17:06:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27339 for ; Tue, 5 Jun 2001 17:06:10 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA27759 for ; Tue, 5 Jun 2001 17:06:09 -0700 (PDT) Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 05 Jun 2001 16:49:50 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 5 Jun 2001 16:52:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: DAD Date: Tue, 5 Jun 2001 16:51:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DAD thread-index: AcDuBCKGkPjmAWCZROiV02r53J3DrQAFXQlA From: "Brian Zill" To: "Sellers, Julian P" Cc: X-OriginalArrivalTime: 05 Jun 2001 23:52:00.0065 (UTC) FILETIME=[82FE7B10:01C0EE1A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f56064e24399 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Julian, When this idea was suggested at the Interim Meeting, several people expressed concern about needing to have a link-local address for every interface identifier you might be using. A node may want to have a large number of global addresses, for example, and the overhead of requiring that it keep a corresponding link-local address for each might be prohibitive. I think I'd prefer to just perfom DAD on all the global addresses instead. It's the same amount of DADing going on, and you don't need to keep all those link-local addresses around. --Brian > -----Original Message----- > From: Sellers, Julian P [mailto:Julian.Sellers@UNISYS.com] > Sent: Tuesday, 05 June, 2001 14:04 > To: 'Thomas Narten' > Cc: 'itojun@iijlab.net'; 'ipng@sunroof.eng.sun.com' > Subject: RE: DAD > > > Thomas, > > Is there a problem with requiring nodes to perform DAD on the > link-local address generated from a given interface > identifier, even if they only want to use the site-local or > the global address? That's what I thought the following > sentences from 5.4 of RFC 2462 required: > > Thus, for a set of addresses formed from the same > interface identifier, it is sufficient to check that the link- > local address generated from the identifier is unique on the > link. In such cases, the link-local address MUST be tested for > uniqueness, and if no duplicate address is detected, an > implementation MAY choose to skip Duplicate Address Detection > for additional addresses derived from the same interface > identifier. > > It's not clear to me what the qualifier "In such cases" > refers to. Maybe this paragraph just needs to state clearly that > > - If a node has successfully performed DAD on a > link-local address, the node has the > right to all addresses on the same link that contain > the same interface identifier. > - If a node has not performed DAD on the link-local > address, or if the link-local > address has failed DAD, the node must not use any > address on that link generated with > the same interface identifier. > > Julian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 18:41:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f561eLU24649 for ipng-dist; Tue, 5 Jun 2001 18:40:21 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f561dPe24630; Tue, 5 Jun 2001 18:39:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21333; Tue, 5 Jun 2001 18:39:33 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09403; Tue, 5 Jun 2001 19:40:02 -0600 (MDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA03954; Wed, 6 Jun 2001 10:39:30 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA28939; Wed, 6 Jun 2001 10:39:30 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA14101; Wed, 6 Jun 2001 10:39:29 +0900 (JST) Date: Wed, 06 Jun 2001 10:39:48 +0900 (JST) Message-Id: <20010606.103948.68538275.kazu@iijlab.net> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) IPv6 ShowCase, N+I Tokyo From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <20010606.090255.98580503.kazu@iijlab.net> References: <20010606.090255.98580503.kazu@iijlab.net> X-Mailer: Mew version 1.95b125 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Kazu Yamamoto ($B;3K\OBI'(B) Subject: (ngtrans) IPv6 ShowCase, N+I Tokyo > Inter-operability test of OSPFv3 I have received a question about OSPFv3. Participants are Zebra on KAME, NEC IX 5000, Hitachi GR 2000, Ericsson (Telebit) AXI 462. OSPFv3 is running the backbone of IPv6 ShowCase while RIPng is used in edges. If you have any questions about IPv6 ShowCase, please post them to this ml (not directly to me). I have no time to answer twice. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 21:10:42 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5649rQ24808 for ipng-dist; Tue, 5 Jun 2001 21:09:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5649me24801 for ; Tue, 5 Jun 2001 21:09:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05421 for ; Tue, 5 Jun 2001 21:09:55 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA19058 for ; Tue, 5 Jun 2001 22:09:54 -0600 (MDT) Received: from mira-sjcd-1.cisco.com (mira-sjcd-1.cisco.com [171.69.43.44]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f5648L514356; Tue, 5 Jun 2001 21:08:21 -0700 (PDT) Received: from cisco.com (dhcp-171-69-51-13.cisco.com [171.69.51.13]) by mira-sjcd-1.cisco.com (Mirapoint) with ESMTP id AAS13632 (AUTH sreeramv); Tue, 5 Jun 2001 21:09:52 -0700 (PDT) Message-ID: <3B1DACD2.B9D42CD1@cisco.com> Date: Tue, 05 Jun 2001 21:08:50 -0700 From: Sreeram Vankadari X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: JORDI PALET MARTINEZ CC: Sridhar Gurivireddy , ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 References: <014001c0edfa$ecbf70b0$8700000a@consulintel02> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk True, but not all the L2 protocols support fragmentation. Ethernet 802.3 ARPA, LLC etc.. don't support fragmentation. Sreeram Vankadari JORDI PALET MARTINEZ wrote: > In the other way, if this happens, the fragmentation will be carried out at the link layer, if I'm not wrong ? > > Thanks and best regards, > > Jordi Palet > Consulintel > > http://www.consulintel.es > Tel: 91 151 81 99 - Fax: 91 151 81 98 > > ----- Original Message ----- > From: )> > To: "Sridhar Gurivireddy" > Cc: > Sent: Tuesday, June 05, 2001 3:35 AM > Subject: Re: fragmentation in IPv6 > > > >>>>> On Mon, 04 Jun 2001 17:20:13 -0500, > > >>>>> Sridhar Gurivireddy said: > > > > > even if fragmentation done only at the source, > > > it may have this problem because,..... > > > say IP header(with extensions) is of size 4k!!!!! > > > it's framented for the first time..... > > > you get three pieces.. > > > yu add header to each piece... > > > each piece is now again >4k... > > > so, fragmentation again.... > > > Does this problem occur.. > > > > Yes, when the unfragmentable part of a packet is larger than the path > > MTU, fragmentation fails and you cannot send the packet. However, > > (at least through my operation experiences) we've never cared about > > the problem, since we've not seen any practical usage of such a pakcet > > with a long unfragmentale part. > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, Toshiba Corp. > > jinmei@isl.rdc.toshiba.co.jp > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > > > ----------------------------------------------------------------------------------------------------------- > La UE se encamina a IPv6: www.ipv6tf.org > Más información de IPv6 en www.consulintel.es/ipv6 > Contrate con nosotros sus productos de Telefonica > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 5 22:58:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f565vjI24882 for ipng-dist; Tue, 5 Jun 2001 22:57:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f565vfe24875 for ; Tue, 5 Jun 2001 22:57:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA07228 for ; Tue, 5 Jun 2001 22:57:48 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08311 for ; Tue, 5 Jun 2001 22:57:46 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id JAA06321; Wed, 6 Jun 2001 09:14:55 +0300 Date: Wed, 6 Jun 2001 09:14:55 +0300 Message-Id: <200106060614.JAA06321@burp.tkv.asdf.org> From: Markku Savela To: bzill@microsoft.com CC: Julian.Sellers@UNISYS.com, ipng@sunroof.eng.sun.com In-reply-to: (bzill@microsoft.com) Subject: Re: DAD References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Brian Zill" > When this idea was suggested at the Interim Meeting, several people > expressed concern about needing to have a link-local address for every > interface identifier you might be using. A node may want to have a > large number of global addresses, for example, and the overhead of > requiring that it keep a corresponding link-local address for each might > be prohibitive. I think I'd prefer to just perfom DAD on all the global > addresses instead. It's the same amount of DADing going on, and you > don't need to keep all those link-local addresses around. My proposal, doing the DAD related comparison only with the ID part, solves the same problem, but lets you do single DAD / Id, regardless of the number of prefixes you combine with this id. And, you don't need to generate link-local address, if you are not using it. There was some concern about the backwards compatibility, but I *still* cannot see this introducing any more problems than what already exists legally by the current specification, where you can have hosts reserving ID for all combinations by DAD on link local, and hosts that don't do that. And, if you change specification, might as well change it to what I proposed :-). -- Markku Savela -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 01:04:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5683ia24995 for ipng-dist; Wed, 6 Jun 2001 01:03:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5683fe24988 for ; Wed, 6 Jun 2001 01:03:41 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20957 for ; Wed, 6 Jun 2001 01:03:48 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05866 for ; Wed, 6 Jun 2001 01:03:48 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5683hZ10889; Wed, 6 Jun 2001 01:03:43 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f5683hZ14605; Wed, 6 Jun 2001 01:03:43 -0700 Message-Id: <200106060803.f5683hZ14605@zed.isi.edu> Subject: Re: DNS Discovery for IPv6 To: dale.sesvold@jioc.osis.gov (SESVOLD, DALE) Date: Wed, 6 Jun 2001 01:03:42 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com, users@ipv6.org ('users@ipv6.org') In-Reply-To: from "SESVOLD, DALE" at Jun 05, 2001 03:21:20 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Can anyone tell me what documents (draft or otherwise) are available for DNS % DISCOVERY on IPv6? % % Thanks % % | DALE G SESVOLD % | Senior Network Engineer % | MacAulay-Brown, Inc. In addition to Dave's draft, you may wish to review the drafts on multicast aware DNS and the draft on the DISCOVER opcode. ./draft-aboba-dnsext-mdns-01.txt ./draft-manning-dnsext-mdns-00.txt ./draft-ietf-dnsext-mdns-00.txt ./draft-aboba-dhc-mdns-conf-02.txt ./draft-manning-dnsext-mdns-01.txt ./draft-aboba-dnsext-mdns-02.txt ./draft-ietf-ipngwg-dns-discovery-00.txt ./draft-ymbk-opcode-discover-00.txt ./draft-ietf-ipngwg-dns-discovery-01.txt ./draft-ymbk-opcode-discover-01.txt -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 02:28:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f569RX525120 for ipng-dist; Wed, 6 Jun 2001 02:27:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f569RTe25113 for ; Wed, 6 Jun 2001 02:27:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29704 for ; Wed, 6 Jun 2001 02:27:38 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20010 for ; Wed, 6 Jun 2001 02:27:34 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA06438; Wed, 6 Jun 2001 12:44:47 +0300 Date: Wed, 6 Jun 2001 12:44:47 +0300 Message-Id: <200106060944.MAA06438@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: IPv6 Scoped Address Architecture & sin6 scope id encoding Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In the meeting there was a question of whether to prefer a) 4 bit scope + 28 index b) 32 index (get scope from somewhere else) for sockaddr_in6 sin6 scope id. I've a slight preference for case (a). This seems to be an API issue, but even if EPOC API is different from the Unix socket API, it will be nice if the concepts have 1:1 mapping (porting applications becomes easier). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 02:40:23 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f569dlO25152 for ipng-dist; Wed, 6 Jun 2001 02:39:47 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f569dhe25145 for ; Wed, 6 Jun 2001 02:39:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06870 for ; Wed, 6 Jun 2001 02:39:51 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01950 for ; Wed, 6 Jun 2001 03:39:49 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:adff:feba:bcfc:5b75]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA11648 for ; Wed, 6 Jun 2001 18:40:03 +0900 (JST) Date: Wed, 06 Jun 2001 18:37:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: IPv6 Scoped Address Architecture & sin6 scope id encoding In-Reply-To: <200106060944.MAA06438@burp.tkv.asdf.org> References: <200106060944.MAA06438@burp.tkv.asdf.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 6 Jun 2001 12:44:47 +0300, >>>>> Markku Savela said: > In the meeting there was a question of whether to prefer > a) 4 bit scope + 28 index > b) 32 index (get scope from somewhere else) > for sockaddr_in6 sin6 scope id. I've a slight preference for case (a). > This seems to be an API issue, but even if EPOC API is different from > the Unix socket API, it will be nice if the concepts have 1:1 > mapping (porting applications becomes easier). So, let's discuss this in the API folks mailing list. I'll summarize my opinion and post it to the list in a few days. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 03:37:27 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56AaqP25201 for ipng-dist; Wed, 6 Jun 2001 03:36:52 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Aane25194 for ; Wed, 6 Jun 2001 03:36:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA07957 for ; Wed, 6 Jun 2001 03:36:55 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00082 for ; Wed, 6 Jun 2001 03:36:54 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA29107; Wed, 6 Jun 2001 12:36:47 +0200 (MET DST) Date: Wed, 6 Jun 2001 12:36:47 +0200 From: Ignatios Souvatzis To: JORDI PALET MARTINEZ Cc: Sridhar Gurivireddy , ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 Message-ID: <20010606123647.D29001@theory.cs.uni-bonn.de> References: <014001c0edfa$ecbf70b0$8700000a@consulintel02> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7lMq7vMTJT4tNk0a" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <014001c0edfa$ecbf70b0$8700000a@consulintel02>; from jordi.palet@consulintel.es on Tue, Jun 05, 2001 at 10:05:51PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --7lMq7vMTJT4tNk0a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 05, 2001 at 10:05:51PM +0200, JORDI PALET MARTINEZ wrote: > In the other way, if this happens, the fragmentation will be carried > out at the link layer, if I'm not wrong ? Yes, that is required of link layers with limits. E.g., an ARCnet driver will use the ARCnet packet header standard to split the packets and reassemble them at the receiving end. Note that this process is invisible to IPv6! Regards, -is --7lMq7vMTJT4tNk0a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOx4HvDCn4om+4LhpAQHBSwf+LUOsS6nEvsegdYY3vetQNBmxFtbpfw95 gbjJpsX8iPeD1OjGTuYcKIKSZlvpKx5Grh/FTl6r+2NRqQBphpqO9rXZfEeurLGh yLi10JmIBoIGp4snHCwabTWS+DTaxzq4mGVtYjvNIeWnUUNiQywC8NSB1Zd3trmx VJT3pLVOvrMEj64C+NjxqjwjBr/i5R3i0g99usnv0+YefcNqhfYw4+QTCN7H67/I pGFKe9GBVEAzAIT61aEHYWo0SAReWlV4M5KHgYFyaYol1sfVI2G315EsovfVuOf4 lELmAjNcyLJDZ5tRAXMSNI1jMLzFL3d6YmDfLXLxCkxD/xzm9fZI7A== =og/F -----END PGP SIGNATURE----- --7lMq7vMTJT4tNk0a-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 03:38:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56Abrb25219 for ipng-dist; Wed, 6 Jun 2001 03:37:53 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Abne25212 for ; Wed, 6 Jun 2001 03:37:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06526 for ; Wed, 6 Jun 2001 03:37:55 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29388 for ; Wed, 6 Jun 2001 03:37:53 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA29117; Wed, 6 Jun 2001 12:37:40 +0200 (MET DST) Date: Wed, 6 Jun 2001 12:37:39 +0200 From: Ignatios Souvatzis To: Sreeram Vankadari Cc: JORDI PALET MARTINEZ , Sridhar Gurivireddy , ipng@sunroof.eng.sun.com Subject: Re: fragmentation in IPv6 Message-ID: <20010606123739.E29001@theory.cs.uni-bonn.de> References: <014001c0edfa$ecbf70b0$8700000a@consulintel02> <3B1DACD2.B9D42CD1@cisco.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="9jHkwA2TBA/ec6v+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B1DACD2.B9D42CD1@cisco.com>; from svankada@cisco.com on Tue, Jun 05, 2001 at 09:08:50PM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --9jHkwA2TBA/ec6v+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 05, 2001 at 09:08:50PM -0700, Sreeram Vankadari wrote: > True, but not all the L2 protocols support fragmentation. > Ethernet 802.3 ARPA, LLC etc.. don't support fragmentation. Yes, but their MTU is bigger than 1280 bytes. -is --9jHkwA2TBA/ec6v+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBOx4H8DCn4om+4LhpAQHB/wf+PppVimxhHTIGzXzrF0s2WOQXIpMZ2ZQA UiYsnijfutGviQTRBFIcS+MxdN8EiPP1Hu8XuVUcaDzC5+1Mwh+w60ordbVXCgAa CbmlCqg6STu0QblmopI1rtzQFqVmJhq9d/F2RrreNhRKVglzwh2r1upX7796x2kh GVF1UG14dxcES1ivupnRgBeHqGdrykKUPZ3NELIFT6U8A7RyDSAJap305Sx0NGOt xBMsFhuFShXCPa9IMssXs05H6ujdpFOzRrJGiHwIhKv4m4DQ8ZA/CBucwdS+ekmx QJMxvSdj1Rvzlo47LOnFPh2kVLwiu+bIH+aKuoCSq/JNaTVh+awrOg== =NLeT -----END PGP SIGNATURE----- --9jHkwA2TBA/ec6v+-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 09:12:30 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56GBs225748 for ipng-dist; Wed, 6 Jun 2001 09:11:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56GBoe25741 for ; Wed, 6 Jun 2001 09:11:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05072 for ; Wed, 6 Jun 2001 09:11:57 -0700 (PDT) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18968 for ; Wed, 6 Jun 2001 09:11:57 -0700 (PDT) Received: from jim (ip-20-152-116.chicago-n.navipath.net [64.20.152.116]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id f56GBs068346; Wed, 6 Jun 2001 12:11:54 -0400 From: "JIM FLEMING" To: Cc: "Patrick Corliss" , Subject: IPv6 Servers for 6:224 AU (AUSTRALIA) Date: Wed, 6 Jun 2001 11:13:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.icannwatch.org AUDA Seeks ICANN's Help to Force .au Redelegation Posted by michael on Wednesday, June 06 @ 07:51:22 MDT (read: 5 times) Kate Mackenzie reports in Australian IT that the auDA, the "industry self-regulatory body" endorsed by the Australian federal government to take over .au, has sought ICANN's help (under its "IANA" hat) to force the redelegation of .au from Internet pioneer Robert Elz to whom it is currently delegated. ----------------------------------------- Are there any IPv6 Servers for .AU ? http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 6:224 AU (AUSTRALIA) Jim Fleming http://www.DOT-NZ.com http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 11:18:24 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56IHkm26260 for ipng-dist; Wed, 6 Jun 2001 11:17:46 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56IHge26253 for ; Wed, 6 Jun 2001 11:17:42 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-57.EBay.Sun.COM [129.150.4.57]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56IHfQ234821; Wed, 6 Jun 2001 11:17:43 -0700 (PDT) Message-Id: <5.1.0.14.0.20010606111548.03c015d0@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Jun 2001 11:22:51 -0700 To: Marc Blanchet , ipng@sunroof.eng.sun.com From: Alain Durand Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt Cc: fink@es.net In-Reply-To: <5.1.0.14.1.20010512092146.01f7e380@mail.viagenie.qc.ca> References: <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:25 AM 5/12/2001 -0400, Marc Blanchet wrote: >- As Robert was saying about my draft, there is two issues: > + do we agree on the idea of the draft? > if yes, then find one address space which is the best one for that > purpose. I don't care which one, I just proposed one. Any advice is > appreciated. For the sake of generality, we might want to reserve a > range that is similar to a TLA, so that anyone would be able to use it > for examples involving TLAs. > if no, then forget the draft. > >What is the opinion of the group? I would like to say that I like Marc's idea a lot. It is like the 555 area code in the movies. It looks real, but everybody knows it's fake. Carving address space from something already allocated to a customer, as kre pointed out, is a bad idea. However, 3fffe:ff00::/24 has not been allocated to anyone. Thus, it looks ok to me. The only one who can complain is Bob Fink, steward of the 6bone 3ffe::/16 prefix. I'm going to use this in draft-ietf-ngtrans-introduction-to-ipv6-transition-07.txt every times I need to give an example of an IPv6 address. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 11:22:33 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56IMAl26281 for ipng-dist; Wed, 6 Jun 2001 11:22:10 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56IM6e26274 for ; Wed, 6 Jun 2001 11:22:06 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-57.EBay.Sun.COM [129.150.4.57]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56IM5Q236896; Wed, 6 Jun 2001 11:22:07 -0700 (PDT) Message-Id: <5.1.0.14.0.20010606112554.03c16008@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Jun 2001 11:27:15 -0700 To: Marc Blanchet , ipng@sunroof.eng.sun.com From: Alain Durand Subject: Fwd: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt Cc: fink@es.net Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I would like to say that I like Marc's idea a lot. It is like the 555 area >code in the movies. >It looks real, but everybody knows it's fake. >Carving address space from something already allocated to a customer, >as kre pointed out, is a bad idea. However, 3fffe:ff00::/24 has not been >allocated to anyone. >Thus, it looks ok to me. An alternative would be to reserve 3ffe:5550::/28. I've checked in the 6bone pTLA list, it is not assigned yet. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 11:50:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56Io9526370 for ipng-dist; Wed, 6 Jun 2001 11:50:09 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56Io5e26363 for ; Wed, 6 Jun 2001 11:50:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13527 for ; Wed, 6 Jun 2001 11:50:12 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12716; Wed, 6 Jun 2001 12:50:41 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f56Io5Z00704; Wed, 6 Jun 2001 11:50:05 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f56Io5d15897; Wed, 6 Jun 2001 11:50:05 -0700 Message-Id: <200106061850.f56Io5d15897@zed.isi.edu> Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt To: Alain.Durand@sun.com (Alain Durand) Date: Wed, 6 Jun 2001 11:50:05 -0700 (PDT) Cc: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet), ipng@sunroof.eng.sun.com, fink@es.net In-Reply-To: <5.1.0.14.0.20010606111548.03c015d0@jurassic> from "Alain Durand" at Jun 06, 2001 11:22:51 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % I would like to say that I like Marc's idea a lot. It is like the 555 area % code in the movies. % It looks real, but everybody knows it's fake. % Carving address space from something already allocated to a customer, % as kre pointed out, is a bad idea. However, 3fffe:ff00::/24 has not been % allocated to anyone. % Thus, it looks ok to me. % % The only one who can complain is Bob Fink, steward of the 6bone 3ffe::/16 % prefix. % % I'm going to use this in % draft-ietf-ngtrans-introduction-to-ipv6-transition-07.txt % every times I need to give an example of an IPv6 address. % % - Alain. Strong Objections to this tactic. If you want a 6bone prefix, you should follow the process. Hijacking is bad form. I'm sure Bob would be amenable to making the delegation, but asking is appropriate. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 12:03:47 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56J3AA26395 for ipng-dist; Wed, 6 Jun 2001 12:03:10 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56J36e26388 for ; Wed, 6 Jun 2001 12:03:06 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-57.EBay.Sun.COM [129.150.4.57]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56J35Q248238; Wed, 6 Jun 2001 12:03:06 -0700 (PDT) Message-Id: <5.1.0.14.0.20010606120326.00af9cc0@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Jun 2001 12:08:06 -0700 To: Bill Manning , fink@es.net From: Alain Durand Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt Cc: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet), ipng@sunroof.eng.sun.com In-Reply-To: <200106061850.f56Io5d15897@zed.isi.edu> References: <5.1.0.14.0.20010606111548.03c015d0@jurassic> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:50 AM 6/6/2001 -0700, Bill Manning wrote: > Strong Objections to this tactic. If you want a 6bone prefix, > you should follow the process. Hijacking is bad form. I'm > sure Bob would be amenable to making the delegation, but > asking is appropriate. This is the reason why I had Cced Bob to this thread. Bob: - do you think it would be appropriate to use a 6bone ptla for that purpose? - what should be the formal process to follow? - would you have any preferences? 3ffe:ff00::/24, 3ffe:5550::/28, anything else? - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 15:00:16 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f56LxUL26773 for ipng-dist; Wed, 6 Jun 2001 14:59:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f56LxRe26766 for ; Wed, 6 Jun 2001 14:59:27 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25353 for ; Wed, 6 Jun 2001 14:59:33 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15983; Wed, 6 Jun 2001 14:59:29 -0700 (PDT) Received: from CLASSIC.viagenie.qc.ca (wlan-233-240.sheraton.inet2001.isoc.org [217.199.233.240] (may be forged)) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f56MFd184239; Wed, 6 Jun 2001 18:15:39 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010606174617.03582ed0@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 06 Jun 2001 17:48:07 -0400 To: Alain Durand , Bill Manning , fink@es.net From: Marc Blanchet Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.0.20010606120326.00af9cc0@jurassic> References: <200106061850.f56Io5d15897@zed.isi.edu> <5.1.0.14.0.20010606111548.03c015d0@jurassic> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk there was suggestion to not use 3ffe::/16 space so that it can be later (humm, do not know how many years...) reclaimed and reused as part of the 001b/3 current addressing architecture. So may be something out of 2000::/3 is the right thing, I don't know, and actually, I don't care. My point was to reserve a space, any space, for documentation/examples/... purposes. Marc. At/À 12:08 2001-06-06 -0700, Alain Durand you wrote/vous écriviez: >At 11:50 AM 6/6/2001 -0700, Bill Manning wrote: > >> Strong Objections to this tactic. If you want a 6bone prefix, >> you should follow the process. Hijacking is bad form. I'm >> sure Bob would be amenable to making the delegation, but >> asking is appropriate. > >This is the reason why I had Cced Bob to this thread. > >Bob: >- do you think it would be appropriate to use a 6bone ptla for that purpose? >- what should be the formal process to follow? >- would you have any preferences? 3ffe:ff00::/24, 3ffe:5550::/28, anything >else? > > - Alain. > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 6 17:50:50 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f570oHK26995 for ipng-dist; Wed, 6 Jun 2001 17:50:17 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f570nne26973; Wed, 6 Jun 2001 17:49:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04278; Wed, 6 Jun 2001 17:49:54 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA14876; Wed, 6 Jun 2001 17:49:53 -0700 (PDT) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id JAA29083; Thu, 7 Jun 2001 09:49:52 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id JAA10640; Thu, 7 Jun 2001 09:49:52 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id JAA21864; Thu, 7 Jun 2001 09:49:51 +0900 (JST) Date: Thu, 07 Jun 2001 09:50:10 +0900 (JST) Message-Id: <20010607.095010.46614318.kazu@iijlab.net> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) IPv6 ShowCase, N+I Tokyo From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <20010606.090255.98580503.kazu@iijlab.net> References: <20010606.090255.98580503.kazu@iijlab.net> X-Mailer: Mew version 1.95b125 on Emacs 21.0 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Kazu Yamamoto ($B;3K\OBI'(B) Subject: (ngtrans) IPv6 ShowCase, N+I Tokyo > Highlights of this booth include: > Inter-operability test of OSPFv3 > New datalink -- GbE, FE, POS, ATM, DSL, ... > Electric Appliance (IPv4 ready, of course) > Phone, FAX, TV, remote camera, temperature sensor ... > InternetCAR One guy pointed out my fatal typo. "IPv4 ready, of course" means "*IPv6* ready, of course". :-) --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 02:00:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f578xt728035 for ipng-dist; Thu, 7 Jun 2001 01:59:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f578xpe28028 for ; Thu, 7 Jun 2001 01:59:51 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25777 for ; Thu, 7 Jun 2001 01:59:59 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00564; Thu, 7 Jun 2001 02:59:56 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f578xol02788; Thu, 7 Jun 2001 15:59:51 +0700 (ICT) From: Robert Elz To: Alain Durand cc: Marc Blanchet , ipng@sunroof.eng.sun.com, fink@es.net Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <5.1.0.14.0.20010606111548.03c015d0@jurassic> References: <5.1.0.14.0.20010606111548.03c015d0@jurassic> <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Thu, 07 Jun 2001 15:59:50 +0700 Message-ID: <2786.991904390@brandenburg.cs.mu.OZ.AU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f578xqe28029 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 06 Jun 2001 11:22:51 -0700 From: Alain Durand Message-ID: <5.1.0.14.0.20010606111548.03c015d0@jurassic> | I would like to say that I like Marc's idea a lot. It is like the 555 area | code in the movies. | It looks real, but everybody knows it's fake. Yes, that's exactly what should be done (pity 555 doesn't exist anywhere but in the US, in AU it used to be a perfectly valid number - phone numbers now are 8 digits, and US 555's are just 7, so at least that issue went away). That seems to be an irrelevance, which shouldn't be wasting the time on the list (555 numbers in AU) - I don't think it is however, unless it has the unfortunate effect of leading to a bunch of "my funniest 555 story" messages, which I hope it won't. That's because... | Carving address space from something already allocated to a customer, | as kre pointed out, is a bad idea. Yes, but I was trying to say more than that. It should not only not be taken from space allocated to a customer, it should also not be taken from space that potentially could be allocated to a customer. That is, not from any address block set aside for that purpose. And ... | However, 3fffe:ff00::/24 has not been allocated to anyone. that one, and even the "prettier" 3ffe:0555 (or 3ffe:5550 or 3ffe:5555 or something) from your later message are in the "could be allocated" category. We want a number that is trivially easy to recognise and filter, not a number (like the rfc1918 set -where there was little choice of course) that only "experts" can tell is not a valid number. That is, I think we should do as much as we can to decrease the risk that any random person getting a box, and following its accompanying doc, will naïvely just configure the addresses in the examples, and then wonder why it doesn't work. The config process on the box needs to be able to immediately say "That isn't a valid address block, contact your ISP to obtain addresses to use" or something when it sees an attempt to config the magic address. kre ps: and I made a similar reply to Bob's message on the 6bone list where he asked the 6bone people about setting aside a piece of the 6bone addr space. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 05:49:10 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57CmXY28427 for ipng-dist; Thu, 7 Jun 2001 05:48:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57CmUe28420 for ; Thu, 7 Jun 2001 05:48:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23051 for ; Thu, 7 Jun 2001 05:48:37 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11409; Thu, 7 Jun 2001 06:48:35 -0600 (MDT) Received: from CLASSIC.viagenie.qc.ca (wlan-226-222.inet2001.isoc.org [217.199.226.222]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f57D3i192600; Thu, 7 Jun 2001 09:03:44 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 07 Jun 2001 08:42:28 -0400 To: Robert Elz From: Marc Blanchet Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt Cc: ipng@sunroof.eng.sun.com, fink@es.net, Alain Durand In-Reply-To: <2786.991904390@brandenburg.cs.mu.OZ.AU> References: <5.1.0.14.0.20010606111548.03c015d0@jurassic> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At/À 15:59 2001-06-07 +0700, Robert Elz you wrote/vous écriviez: ...cut... > | However, 3fffe:ff00::/24 has not been allocated to anyone. > >that one, and even the "prettier" 3ffe:0555 (or 3ffe:5550 or >3ffe:5555 or something) from your later message are in the >"could be allocated" category. but anything outside of 2000::/3 has _no_ structure defined, so choosing something outside of 2000::/3 is worst. >We want a number that is trivially easy to recognise and filter, not >a number (like the rfc1918 set -where there was little choice of course) >that only "experts" can tell is not a valid number. (but only "experts" will filter anyway, no? Marc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 10:38:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57Hc7k29701 for ipng-dist; Thu, 7 Jun 2001 10:38:07 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57Hc5e29694 for ; Thu, 7 Jun 2001 10:38:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f57HYDH09463 for ipng@sunroof.eng.sun.com; Thu, 7 Jun 2001 10:34:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f573mte27426 for ; Wed, 6 Jun 2001 20:48:55 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24343 for ; Wed, 6 Jun 2001 20:49:02 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA02514 for ; Wed, 6 Jun 2001 20:49:02 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f573lTF29853 for ; Wed, 6 Jun 2001 20:47:29 -0700 (PDT) Received: from RSAMPRAT-W2K.cisco.com (dhcp-171-71-97-13.cisco.com [171.71.97.13]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AHU05808; Wed, 6 Jun 2001 20:49:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20010606203803.02a6b900@mira-sjc5-7.cisco.com> X-Sender: rsamprat@mira-sjc5-7.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Jun 2001 20:40:26 -0700 To: ipng@sunroof.eng.sun.com From: Ravikanth Samprathi Subject: NAT-PT for linux Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1906749620==_.ALT" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_1906749620==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I have a small question about NAT-PT that is implemented for linux. I am hoping you would provide with the feedback. In the install-document of NAT-PT, they say that the NAT-PT is running in the border gateway and, dns server for ipv4 is running in a machine ipv4-stub and, dns server for ipv6 is running in another machine in ipv6-stub. My question is the following:- Is it possible that the dns servers for both ipv4 and ipv6 to run in the same border gateway as the NAT-PT? Or in other words, Can we run, NAT-PT, ipv4-dns-server and ipv6-dns-server in the same border gateway?? And can we have NAT-PT's dns-alg use the ipv4 and ipv6 dns servers from the servers running the same border gateway machine? Thank you, Hope you will answer my question. Thanx, ravi --=====================_1906749620==_.ALT Content-Type: text/html; charset="us-ascii"
Hi,
I have a small question about NAT-PT that is
implemented for linux. I am hoping you would provide
with the feedback.
In the install-document of NAT-PT, they say that the
NAT-PT is running in the border gateway and,
dns server for ipv4 is running in a machine ipv4-stub and,
dns server for ipv6 is running in another machine in ipv6-stub.
My question is the following:-
Is it possible that the dns servers for both ipv4 and ipv6 to
run in the same border gateway as the NAT-PT?
Or in other words,
Can we run, NAT-PT, ipv4-dns-server and ipv6-dns-server
in the same border gateway??
And can we have NAT-PT's dns-alg use the ipv4 and ipv6
dns servers from the servers running the same border
gateway machine?
Thank you,
Hope you will answer my question.
Thanx,
ravi
--=====================_1906749620==_.ALT-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 11:07:21 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57I6Lu29964 for ipng-dist; Thu, 7 Jun 2001 11:06:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57I6Ie29957 for ; Thu, 7 Jun 2001 11:06:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00979 for ; Thu, 7 Jun 2001 11:06:24 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00187 for ; Thu, 7 Jun 2001 12:06:22 -0600 (MDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f57I6LU02723; Thu, 7 Jun 2001 11:06:26 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAS26389; Thu, 7 Jun 2001 11:06:16 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <3B0CDA3C.BF2760CE@cisco.com> References: <3B0CDA3C.BF2760CE@cisco.com> Date: Thu, 7 Jun 2001 11:06:16 -0700 To: Dario Accornero From: Steve Deering Subject: Re: IPv6 MIBs comments/questions [2nd attempt] Cc: ipng@sunroof.eng.sun.com, fenner@research.att.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dario, I don't know if you received private answers to your MIB questions, but in case not, here are answers to a few of your points (from someone who knows about the IPv6 protocol but nothing about the IPv6 MIBs): At 10:54 AM +0100 5/24/01, Dario Accornero wrote: >Section 4 Page 7 >ipv6InterfaceEffectiveMtu: I assume the MTU is related to the whole >packet, and not just the payload, but I would like to make sure. In the IP world, MTU always refers to the maximum IP packet size including the IP header but excluding any lower-layer headers. >Section 4 Page 9 >ipv6InterfaceIdentifierLength: The reason for the existence of this >field should be clearly stated, e.g. in what case could we have an >interface identifier length different from 64 bits? >I suggest that we get rid of this object as it doesn't seem useful. Most but not all IPv6 unicast addresses have a 64-bit Interface ID field. In particular, addresses starting with the bit pattern 000 are not required to have 64-bit IID fields. Examples are the embedded NSAP address format [RFC-1888] and IPv4-compatible IPv6 addresses. >Section 4 Page 17 >ipAddressPrefixOrigin: Besides DHCP and router advertisements, >are there any plans to include other possible sources? >An example would be AAA: should we include this in "other(1)"? >Could anyone provide another example of the wellknown origin for >IPv6 prefixes? The only available example is for IPv4 autoconfig. Perhaps "manual-config"? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 11:40:14 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57IdVK00057 for ipng-dist; Thu, 7 Jun 2001 11:39:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57IdSe00050; Thu, 7 Jun 2001 11:39:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10017; Thu, 7 Jun 2001 11:39:34 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08119; Thu, 7 Jun 2001 11:39:33 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f57IdXU29599; Thu, 7 Jun 2001 11:39:34 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAS27296; Thu, 7 Jun 2001 11:39:28 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: Date: Thu, 7 Jun 2001 11:39:28 -0700 To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Steve Deering Subject: IPv6 Interim Meeting attendance list Cc: 3GPP_TSG_SA_WG2@LIST.ETSI.FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f57IdSf00051 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At the IPngwg/NGtrans/3GPP meeting in Redmond last week, the attendance sheet that was circulated on the first two days disappeared, so we circulated a second sheet on the third day, but that meant we missed some of the folks who didn't stay through to the last day. Therefore, if you were at the meeting at any time but are not on the following list, please send me private email so we can have a more accurate list. (Collecting attendance lists is required by the IETF process.) Also, if you are on the list but *weren't* there, or if you know of colleagues or others who should to be added or deleted from the list of attendees, please let me know that as well. Thanks, and sorry for the bureaucratic interruption. Steve ------- (alphabetical by first name) Alain Baudot Alain Durand Alex Conta Atsushi Onoe Bernard Aboba Bonnie Chen Brian Zill Carl Williams Christian Hahn Christian Huitema Cyndi Jung Dave Thaler David Kessens Erik Nordmark Eugene Kim Francis Dupont Fred Templin Gerard Gastaud Glenn Morrow Hesham Soliman Hiroshi Kitamura Howard Herbert Ileana Leuca Jasminko Mulahusic Jim Bound Jim Filreis Jim Martin Jochen Metzler John Loughney John Spence Jonne Soininen Joo-Chul Lee Jordi Palet Josh Littlefield Jun-ichiro Hagino Jussi Laukkanen Kazuaki TSUCHIYA Koichi KUNITAKE Margaret Wasserman Markku Savela Melissa Johnson Mohammad Mahloujian Myung-Ki Shin Nathan Lutchansky Ole Troan Pat Calhoun Paul Francis Peter Barany Phil Roberts Rahul Bahadur Randy Bush Régis Desmeules Richard Draves Robert Fink Robert Hinden Shabnam Sultana Stella Kwong Steve Deering Takumi Segawa Tatuya Jinmei Thomas Narten Tony Hain Tsuyoshi Momose Yanick Pouffary Yoshinori Maeda -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 16:41:19 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f57Neev01242 for ipng-dist; Thu, 7 Jun 2001 16:40:40 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57Nece01235 for ; Thu, 7 Jun 2001 16:40:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f57NakM10153 for ipng@sunroof.eng.sun.com; Thu, 7 Jun 2001 16:36:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f57Htke29914 for ; Thu, 7 Jun 2001 10:55:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28785 for ; Thu, 7 Jun 2001 10:55:53 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA05954 for ; Thu, 7 Jun 2001 11:56:26 -0600 (MDT) Received: from localhost ([127.0.0.1]:61700 "EHLO hactrn.net" ident: "IDENT-NOT-QUERIED [port 61700]") by thrintun.hactrn.net with ESMTP id <23567-219>; Thu, 7 Jun 2001 13:55:41 -0400 To: Ravikanth Samprathi cc: ipng@sunroof.eng.sun.com Subject: Re: NAT-PT for linux In-Reply-To: Message from Ravikanth Samprathi dated "Wed, 06 Jun 2001 20:40:26 PDT" <4.3.2.7.2.20010606203803.02a6b900@mira-sjc5-7.cisco.com> References: <4.3.2.7.2.20010606203803.02a6b900@mira-sjc5-7.cisco.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Thu, 07 Jun 2001 13:55:36 -0400 From: Rob Austein Message-Id: <20010607175548Z23567-219+1773@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 06 Jun 2001 20:40:26 -0700 From: Ravikanth Samprathi My question is the following:- Is it possible that the dns servers for both ipv4 and ipv6 to run in the same border gateway as the NAT-PT? Or in other words, Can we run, NAT-PT, ipv4-dns-server and ipv6-dns-server in the same border gateway?? And can we have NAT-PT's dns-alg use the ipv4 and ipv6 dns servers from the servers running the same border gateway machine? Yes. One has to pay careful attention to which piece of DNS code ends up processing which packets, but InterNetShare's "AER" implementation has two-faced DNS and the DNS-ALG all running on the NAT-PT box. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 17:40:36 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f580dwV01432 for ipng-dist; Thu, 7 Jun 2001 17:39:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f580dte01425 for ; Thu, 7 Jun 2001 17:39:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22770 for ; Thu, 7 Jun 2001 17:40:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA02026 for ; Thu, 7 Jun 2001 17:40:02 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA21348; Thu, 7 Jun 2001 17:40:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f580e0I26719; Thu, 7 Jun 2001 17:40:00 -0700 X-mProtect: Thu, 7 Jun 2001 17:40:00 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpd39mkpe; Thu, 07 Jun 2001 17:39:59 PDT Message-Id: <4.3.2.7.2.20010607173856.021419c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Jun 2001 17:39:58 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft Minutes for IPng Interim Meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft minutes and most of the presentation materials from last weeks interim IPng working group meeting can be found at: http://playground.sun.com/ipng/meetings.html Please send corrections and updates to me. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 21:03:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5842so01721 for ipng-dist; Thu, 7 Jun 2001 21:02:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5842oe01714 for ; Thu, 7 Jun 2001 21:02:50 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12544 for ; Thu, 7 Jun 2001 21:02:58 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA13772; Thu, 7 Jun 2001 21:02:56 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5842uZ16138; Thu, 7 Jun 2001 21:02:56 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f5842ub18465; Thu, 7 Jun 2001 21:02:56 -0700 Message-Id: <200106080402.f5842ub18465@zed.isi.edu> Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt To: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Thu, 7 Jun 2001 21:02:56 -0700 (PDT) Cc: Alain.Durand@sun.com (Alain Durand), bmanning@ISI.EDU (Bill Manning), fink@es.net, ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.1.20010606174617.03582ed0@mail.viagenie.qc.ca> from "Marc Blanchet" at Jun 06, 2001 05:48:07 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What you seem to be asking for is something like the v4 delegation 192.0.2.0/24. It was set aside for documentation. My thought is/was that we might reuse the 5f:: prefix that predates the 6bone. % % there was suggestion to not use 3ffe::/16 space so that it can be later % (humm, do not know how many years...) reclaimed and reused as part of the % 001b/3 current addressing architecture. So may be something out of % 2000::/3 is the right thing, I don't know, and actually, I don't care. My % point was to reserve a space, any space, for documentation/examples/... % purposes. % % Marc. % % At/À 12:08 2001-06-06 -0700, Alain Durand you wrote/vous écriviez: % >At 11:50 AM 6/6/2001 -0700, Bill Manning wrote: % > % >> Strong Objections to this tactic. If you want a 6bone prefix, % >> you should follow the process. Hijacking is bad form. I'm % >> sure Bob would be amenable to making the delegation, but % >> asking is appropriate. % > % >This is the reason why I had Cced Bob to this thread. % > % >Bob: % >- do you think it would be appropriate to use a 6bone ptla for that purpose? % >- what should be the formal process to follow? % >- would you have any preferences? 3ffe:ff00::/24, 3ffe:5550::/28, anything % >else? % > % > - Alain. % > % >-------------------------------------------------------------------- % >IETF IPng Working Group Mailing List % >IPng Home Page: http://playground.sun.com/ipng % >FTP archive: ftp://playground.sun.com/pub/ipng % >Direct all administrative requests to majordomo@sunroof.eng.sun.com % >-------------------------------------------------------------------- % % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 21:17:43 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f584H7u01785 for ipng-dist; Thu, 7 Jun 2001 21:17:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f584H2e01778 for ; Thu, 7 Jun 2001 21:17:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA13915 for ; Thu, 7 Jun 2001 21:17:10 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA18820 for ; Thu, 7 Jun 2001 21:17:08 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:bd4f:bf7c:7fbf:8bd1]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id NAA25391; Fri, 8 Jun 2001 13:17:21 +0900 (JST) Date: Fri, 08 Jun 2001 13:14:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <4.3.2.7.2.20010607173856.021419c0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20010607173856.021419c0@mailhost.iprg.nokia.com> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 07 Jun 2001 17:39:58 -0700, >>>>> Bob Hinden said: > The draft minutes and most of the presentation materials from last weeks > interim IPng working group meeting can be found at: > http://playground.sun.com/ipng/meetings.html > Please send corrections and updates to me. I couldn't see it. (probably due to lack of a link to the file...?) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 7 21:32:08 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f584VRU01826 for ipng-dist; Thu, 7 Jun 2001 21:31:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f584VNe01819 for ; Thu, 7 Jun 2001 21:31:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06399 for ; Thu, 7 Jun 2001 21:31:30 -0700 (PDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA07204; Thu, 7 Jun 2001 22:32:04 -0600 (MDT) Received: from jim (ip-20-150-224.chicago-n.navipath.net [64.20.150.224]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f584VOk73974; Fri, 8 Jun 2001 00:31:24 -0400 From: "JIM FLEMING" To: "Bill Manning" , "Marc Blanchet" Cc: "Alain Durand" , , Subject: Where's the BEEF ? Date: Thu, 7 Jun 2001 23:32:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200106080402.f5842ub18465@zed.isi.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In my opinion, 10.x.x.x from IPv4 is widely recognized as local space. Why waste more IPv4 space on special purpose addresses ? Now that "IPv8-style" addressing is being more widely used***, one might consider.... 2002:10.x.x.x:0000:0000:10.x.x.x:0000 For IPv16...the more popular examples may be... FEED:10.x.x.x:0000 CAFE:10.x.x.x:0000 BABE:10.x.x.x:0000 BEEF:10.x.x.x:0000 Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of itojun@iijlab.net Sent: Thursday, May 31, 2001 1:17 PM To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com Subject: Re: IPv6 @ interim meeting *** ------------------------------------------------ > as a temporary measure I have configured tunnel to IIJ Palo Alto device. > the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. > > it would be, of course, better to have ipv6 prefix from microsoft > research :-) today we've got a router operated by MS research guys, using 6to4. so my router have went away. 2002:836b:2505:5::/64 itojun -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bill Manning Sent: Thursday, June 07, 2001 11:03 PM To: Marc Blanchet Cc: Alain Durand; Bill Manning; fink@es.net; ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt What you seem to be asking for is something like the v4 delegation 192.0.2.0/24. It was set aside for documentation. My thought is/was that we might reuse the 5f:: prefix that predates the 6bone. % % there was suggestion to not use 3ffe::/16 space so that it can be later % (humm, do not know how many years...) reclaimed and reused as part of the % 001b/3 current addressing architecture. So may be something out of % 2000::/3 is the right thing, I don't know, and actually, I don't care. My % point was to reserve a space, any space, for documentation/examples/... % purposes. % % Marc. % % At/À 12:08 2001-06-06 -0700, Alain Durand you wrote/vous écriviez: % >At 11:50 AM 6/6/2001 -0700, Bill Manning wrote: % > % >> Strong Objections to this tactic. If you want a 6bone prefix, % >> you should follow the process. Hijacking is bad form. I'm % >> sure Bob would be amenable to making the delegation, but % >> asking is appropriate. % > % >This is the reason why I had Cced Bob to this thread. % > % >Bob: % >- do you think it would be appropriate to use a 6bone ptla for that purpose? % >- what should be the formal process to follow? % >- would you have any preferences? 3ffe:ff00::/24, 3ffe:5550::/28, anything % >else? % > % > - Alain. % > % >-------------------------------------------------------------------- % >IETF IPng Working Group Mailing List % >IPng Home Page: http://playground.sun.com/ipng % >FTP archive: ftp://playground.sun.com/pub/ipng % >Direct all administrative requests to majordomo@sunroof.eng.sun.com % >-------------------------------------------------------------------- % % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 02:07:25 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f5896jt02124 for ipng-dist; Fri, 8 Jun 2001 02:06:46 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5896ge02117 for ; Fri, 8 Jun 2001 02:06:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17063 for ; Fri, 8 Jun 2001 02:06:50 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24927; Fri, 8 Jun 2001 03:06:45 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5896Ml02132; Fri, 8 Jun 2001 16:06:23 +0700 (ICT) From: Robert Elz To: Marc Blanchet cc: ipng@sunroof.eng.sun.com, fink@es.net, Alain Durand Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> References: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2001 16:06:22 +0700 Message-ID: <2130.991991182@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 07 Jun 2001 08:42:28 -0400 From: Marc Blanchet Message-ID: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> | but anything outside of 2000::/3 has _no_ structure defined, | so choosing something outside of 2000::/3 is worst. No, there is structure defined at both ends of the address space already, 0000::/whatever already has the IPv4 , and ::1 addresses in it. FE00::/7 already has multicast, and link locals, and stuff. We can easily define another small (as small or big as needed) piece at either end there, almost as easily as we can define a piece inside the 2000::/3 space (perhaps not quite as easily, as the former requires an RFC, and the latter just a registry entry - but what you're writing will become an RFC anyway won't it? So, your doc can be the one that makes the assignment, then it can be incorporated in the next rev of the IPv6 addressing doc, whenever that happens). | (but only "experts" will filter anyway, no? Yes, but that's the idea. If the address is well defined enough, the filtering can be in the code, rather than in the user's configuration. Then only the experts need to do it, and everyone reaps the benefit. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 02:38:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f589bjb02324 for ipng-dist; Fri, 8 Jun 2001 02:37:45 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f589bee02317 for ; Fri, 8 Jun 2001 02:37:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19353 for ; Fri, 8 Jun 2001 02:37:49 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12282 for ; Fri, 8 Jun 2001 03:37:46 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 6B0987BB; Fri, 8 Jun 2001 18:37:24 +0900 (JST) To: Bob Hinden , ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Fri, 08 Jun 2001 13:14:25 +0900. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft Minutes for IPng Interim Meeting From: Jun-ichiro itojun Hagino Date: Fri, 08 Jun 2001 18:37:24 +0900 Message-Id: <20010608093724.6B0987BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The draft minutes and most of the presentation materials from last weeks >> interim IPng working group meeting can be found at: >> http://playground.sun.com/ipng/meetings.html >> Please send corrections and updates to me. >I couldn't see it. (probably due to lack of a link to the file...?) if you access the above URL over IPv6, you will see an obsolete content (because there actually are two web servers). try contacting the URL using IPv4 :-< itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 03:06:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58A65t02391 for ipng-dist; Fri, 8 Jun 2001 03:06:05 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58A61e02384 for ; Fri, 8 Jun 2001 03:06:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26093 for ; Fri, 8 Jun 2001 03:06:06 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09257; Fri, 8 Jun 2001 03:06:04 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f58A4El02566; Fri, 8 Jun 2001 17:04:18 +0700 (ICT) From: Robert Elz To: Bill Manning cc: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet), Alain.Durand@sun.com (Alain Durand), fink@es.net, ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <200106080402.f5842ub18465@zed.isi.edu> References: <200106080402.f5842ub18465@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Jun 2001 17:04:14 +0700 Message-ID: <2564.991994654@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 7 Jun 2001 21:02:56 -0700 (PDT) From: Bill Manning Message-ID: <200106080402.f5842ub18465@zed.isi.edu> | My thought is/was that we might reuse the 5f:: prefix that | predates the 6bone. That's a possibility, if we can reserve it forever (though I assume you mean 5f00:: and not the 005f:: that you wrote...). It doesn't have to be at the ends of the address space, I just have a tendency to prefer it there to leave all the big unused middle free. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 07:12:29 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58EBZ702691 for ipng-dist; Fri, 8 Jun 2001 07:11:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58EBVe02684 for ; Fri, 8 Jun 2001 07:11:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03350 for ; Fri, 8 Jun 2001 07:11:36 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27657 for ; Fri, 8 Jun 2001 08:11:35 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f58EBZZ17967; Fri, 8 Jun 2001 07:11:35 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f58EBZQ19279; Fri, 8 Jun 2001 07:11:35 -0700 Message-Id: <200106081411.f58EBZQ19279@zed.isi.edu> Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 8 Jun 2001 07:11:35 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), Marc.Blanchet@viagenie.qc.ca (Marc Blanchet), Alain.Durand@sun.com (Alain Durand), fink@es.net, ipng@sunroof.eng.sun.com In-Reply-To: <2564.991994654@brandenburg.cs.mu.OZ.AU> from "Robert Elz" at Jun 08, 2001 05:04:14 PM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Date: Thu, 7 Jun 2001 21:02:56 -0700 (PDT) % From: Bill Manning % Message-ID: <200106080402.f5842ub18465@zed.isi.edu> % % | My thought is/was that we might reuse the 5f:: prefix that % | predates the 6bone. % % That's a possibility, if we can reserve it forever (though I assume % you mean 5f00:: and not the 005f:: that you wrote...). Yes. And thats always been a problem w/ the way IPv6 addresses are written. When do you pad and where? % It doesn't have to be at the ends of the address space, I just have % a tendency to prefer it there to leave all the big unused middle free. It would be an easier choice if: ) the addressing formats actually gel'ed. ) we do this before the IESG hands off the task of addressing formats to the RIRs. % % kre % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 08:06:07 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58F5RC02745 for ipng-dist; Fri, 8 Jun 2001 08:05:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58F5Oe02738 for ; Fri, 8 Jun 2001 08:05:24 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23665 for ; Fri, 8 Jun 2001 08:05:29 -0700 (PDT) Received: from polaris.lgsi.co.in ([202.54.13.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23912 for ; Fri, 8 Jun 2001 08:05:27 -0700 (PDT) Received: from prashanth ([202.54.13.195]) by polaris.lgsi.co.in (Netscape Messaging Server 4.15) with ESMTP id GEMA7700.VND; Fri, 8 Jun 2001 20:41:31 +0530 From: "Basavaraj Unnibhavi" To: "Ipng" Cc: "Erik Nordmark" Subject: ND6 RFC-STALE state Date: Fri, 8 Jun 2001 20:35:55 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have got querry regarding State machine for the reachability state (RFC 2461) If reachability state is STALE, no attempt is made to Clear the cache entry. Why is that ? If no packets are sent to Neighbor whose state is STALE then entry in cache remains forever. This allows cache to grow indefinately ???? Thanks in advance for any clarifications Basavaraj -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 09:45:58 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58GjBK02922 for ipng-dist; Fri, 8 Jun 2001 09:45:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58Gj7e02915 for ; Fri, 8 Jun 2001 09:45:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20416 for ; Fri, 8 Jun 2001 09:45:13 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14646 for ; Fri, 8 Jun 2001 10:45:12 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA01454; Fri, 8 Jun 2001 09:45:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58GjBp21704; Fri, 8 Jun 2001 09:45:11 -0700 X-mProtect: Fri, 8 Jun 2001 09:45:11 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdoNBn17; Fri, 08 Jun 2001 09:45:09 PDT Message-Id: <4.3.2.7.2.20010608093738.0285e288@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 09:45:07 -0700 To: Jun-ichiro itojun Hagino , jinmei@isl.rdc.toshiba.co.jp From: Bob Hinden Subject: Re: Draft Minutes for IPng Interim Meeting Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20010608093724.6B0987BB@starfruit.itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tatuya, Itojun, You discovered that we have been working with Sun to bring up an IPv6 version of the IPng w.g. web pages. It is a new machine and the content had not yet been synchronized. Once this was done, we were going to announce it. It will be easy to have some special IPv6 only reachable content. Please send me your suggestions! Bob At 06:37 PM 6/8/2001 +0900, Jun-ichiro itojun Hagino wrote: > >> The draft minutes and most of the presentation materials from last weeks > >> interim IPng working group meeting can be found at: > >> http://playground.sun.com/ipng/meetings.html > >> Please send corrections and updates to me. > >I couldn't see it. (probably due to lack of a link to the file...?) > > if you access the above URL over IPv6, you will see an obsolete > content (because there actually are two web servers). > try contacting the URL using IPv4 :-< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 10:00:35 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58GxlP02950 for ipng-dist; Fri, 8 Jun 2001 09:59:47 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58Gxhe02943 for ; Fri, 8 Jun 2001 09:59:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14633 for ; Fri, 8 Jun 2001 09:59:49 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28065 for ; Fri, 8 Jun 2001 10:59:48 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id LAA23187 for ; Fri, 8 Jun 2001 11:58:32 -0500 (CDT) Message-Id: <200106081658.LAA23187@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Draft Minutes for IPng Interim Meeting Date: Fri, 08 Jun 2001 11:58:32 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I suggest that discussion of DNS, which was not on the advance agenda, be considered not to have taken place. Some people with informed viewpoints were not present to correct various misstatements which, as far as the minutes show, went unchallenged. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 12:40:34 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58Jd8406026 for ipng-dist; Fri, 8 Jun 2001 12:39:08 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58Jd4e06019 for ; Fri, 8 Jun 2001 12:39:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08819 for ; Fri, 8 Jun 2001 12:39:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12587 for ; Fri, 8 Jun 2001 13:39:46 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17568; Fri, 8 Jun 2001 12:39:08 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f58Jd8706628; Fri, 8 Jun 2001 12:39:08 -0700 X-mProtect: Fri, 8 Jun 2001 12:39:08 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdvZOfod; Fri, 08 Jun 2001 12:39:06 PDT Message-Id: <4.3.2.7.2.20010608122632.0285e288@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Jun 2001 12:39:04 -0700 To: "Matt Crawford" From: Bob Hinden Subject: Re: Draft Minutes for IPng Interim Meeting Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200106081658.LAA23187@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, >I suggest that discussion of DNS, which was not on the advance >agenda, be considered not to have taken place. Some people with >informed viewpoints were not present to correct various misstatements >which, as far as the minutes show, went unchallenged. It it's in the minutes it must have taken place. I don't usually take notes on things that didn't take place :-) The presentation was intended to be a report from the DNS directorate on their discussion and recommendations on A6, DNAME, and bit-string labels. The DNS directorate, like other directorates in the IETF, doesn't have any official standing. It will make a recommendation to the DNSEXT working group where a real discussion should happen. As you point out, people with potentially differing views were not at the IPng interim meeting. Would you like the minutes to be updated to make this clearer? Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 8 15:31:46 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f58MUuA06347 for ipng-dist; Fri, 8 Jun 2001 15:30:56 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f58MUpe06340 for ; Fri, 8 Jun 2001 15:30:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05927 for ; Fri, 8 Jun 2001 15:30:56 -0700 (PDT) Received: from starfruit.itojun.org (dialup0.itojun.org [210.160.95.108]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08353 for ; Fri, 8 Jun 2001 15:30:54 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 725977BB; Sat, 9 Jun 2001 07:30:36 +0900 (JST) To: Bob Hinden Cc: ipng@sunroof.eng.sun.com In-reply-to: hinden's message of Fri, 08 Jun 2001 09:45:07 MST. <4.3.2.7.2.20010608093738.0285e288@mailhost.iprg.nokia.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft Minutes for IPng Interim Meeting From: Jun-ichiro itojun Hagino Date: Sat, 09 Jun 2001 07:30:36 +0900 Message-Id: <20010608223036.725977BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Tatuya, Itojun, >You discovered that we have been working with Sun to bring up an IPv6 >version of the IPng w.g. web pages. It is a new machine and the content >had not yet been synchronized. Once this was done, we were going to >announce it. i see, no problem (and it is a great effort!). >It will be easy to have some special IPv6 only reachable content. Please >send me your suggestions! dancing steve:-) (just like IPv6-only dancing kame on www.kame.net) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 9 08:26:44 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f59FQ6v07494 for ipng-dist; Sat, 9 Jun 2001 08:26:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f59FQ2e07487 for ; Sat, 9 Jun 2001 08:26:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23935 for ; Sat, 9 Jun 2001 08:26:09 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA08622 for ; Sat, 9 Jun 2001 08:26:08 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB04866; Sat, 9 Jun 2001 11:26:05 -0400 Date: Sat, 9 Jun 2001 11:26:05 -0400 (EDT) From: Jim Bound To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <200106081658.LAA23187@gungnir.fnal.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I challenge any notion of altering the long effort of A6 but at the meeting it was made clear to several of my questions that any input from any directorate will have discussion and technical analysis by the WG once the work is presented from the DNS directorate. So I let it go for now. So politically I was shutdown and no details were presented in any depth for discussion. That is the next step I presume. There was no opportunity to challenge as nothing of details were presented. I do question why though why you, and others like Bob Halley, Bill Manning, Paul Vixie, David Conrad et al were not part of this directorate who architected and implemented A6 with running code were not part of this directorates deliberations. And will be looking carefully at the technical details from the directorate with great anticipation. I agree that it should have been noted on the agenda so you and others who were authors / implementors of A6 knew ahead of time that it was to be presented. IMO that was an unfortuneate oversight in listing the agenda. regards, /jim On Fri, 8 Jun 2001, Matt Crawford wrote: > I suggest that discussion of DNS, which was not on the advance > agenda, be considered not to have taken place. Some people with > informed viewpoints were not present to correct various misstatements > which, as far as the minutes show, went unchallenged. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 9 08:53:20 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f59Fqka07526 for ipng-dist; Sat, 9 Jun 2001 08:52:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f59Fqhe07519 for ; Sat, 9 Jun 2001 08:52:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25182 for ; Sat, 9 Jun 2001 08:52:49 -0700 (PDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14468 for ; Sat, 9 Jun 2001 08:52:48 -0700 (PDT) Received: from jim (ip-20-150-72.chicago-n.navipath.net [64.20.150.72]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f59Fqik145280; Sat, 9 Jun 2001 11:52:44 -0400 From: "JIM FLEMING" To: "Jim Bound" , "Matt Crawford" Cc: Subject: RE: Draft Minutes for IPng Interim Meeting Date: Sat, 9 Jun 2001 10:54:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When you say "politically shutdown", do you mean censored ? Where were you shutdown ? Has this list been shutdown ? Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Jim Bound Sent: Saturday, June 09, 2001 10:26 AM To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting Matt, I challenge any notion of altering the long effort of A6 but at the meeting it was made clear to several of my questions that any input from any directorate will have discussion and technical analysis by the WG once the work is presented from the DNS directorate. So I let it go for now. So politically I was shutdown and no details were presented in any depth for discussion. That is the next step I presume. There was no opportunity to challenge as nothing of details were presented. I do question why though why you, and others like Bob Halley, Bill Manning, Paul Vixie, David Conrad et al were not part of this directorate who architected and implemented A6 with running code were not part of this directorates deliberations. And will be looking carefully at the technical details from the directorate with great anticipation. I agree that it should have been noted on the agenda so you and others who were authors / implementors of A6 knew ahead of time that it was to be presented. IMO that was an unfortuneate oversight in listing the agenda. regards, /jim On Fri, 8 Jun 2001, Matt Crawford wrote: > I suggest that discussion of DNS, which was not on the advance > agenda, be considered not to have taken place. Some people with > informed viewpoints were not present to correct various misstatements > which, as far as the minutes show, went unchallenged. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 9 08:57:48 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f59FvSJ07544 for ipng-dist; Sat, 9 Jun 2001 08:57:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f59FvPe07537 for ; Sat, 9 Jun 2001 08:57:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07462 for ; Sat, 9 Jun 2001 08:57:31 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15462 for ; Sat, 9 Jun 2001 08:57:31 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 158l7A-000L8G-00; Sat, 09 Jun 2001 08:57:28 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting References: <200106081658.LAA23187@gungnir.fnal.gov> Message-Id: Date: Sat, 09 Jun 2001 08:57:28 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I challenge any notion of altering the long effort of A6 may i suggest that it might be more productive to discuss the engineering need (or not) for it, and stick to principles not personalities? e.g. in the absense of rapid renumbering and gse or other non-v4 routing, what need is sufficiently important to justify a6? if there is none currently, but one arises in the future (and i sure hope something does arise for at least routing), then, if dns mechanisms are needed, appropriate ones can be specified. and those could be a6, i can't prejudge. in the meantime, it would be a real bummer if the current a6 spec, for which there seems to be little documented actual need, was to prejudice designs for critical problems such as routing because some interesting approach would not work with a6. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 9 09:13:49 2001 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) id f59GDGB07568 for ipng-dist; Sat, 9 Jun 2001 09:13:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f59GDDe07561 for ; Sat, 9 Jun 2001 09:13:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25997 for ; Sat, 9 Jun 2001 09:13:19 -0700 (PDT) Received: from pimout2-int.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25289 for ; Sat, 9 Jun 2001 10:13:53 -0600 (MDT) Received: from jim (ip-20-150-72.chicago-n.navipath.net [64.20.150.72]) by pimout2-int.prodigy.net (8.11.0/8.11.0) with SMTP id f59GCtk192922; Sat, 9 Jun 2001 12:12:56 -0400 From: "JIM FLEMING" To: "Jim Bound" , "Randy Bush" Cc: "karl@cavebear. com" , "vint cerf" , "Lynn" , Subject: RE: Draft Minutes for IPng Interim Meeting Date: Sat, 9 Jun 2001 11:14:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A6 and IPv6 seem to fit together. IPv8 and IPv16 only use AAAA. Maybe the ICANN Board needs to "take this offline" ? ...in my opinion, ICANN can take all of IPv6 offline... Jim Fleming http://www.unir.com http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Randy Bush Sent: Saturday, June 09, 2001 10:57 AM To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting > I challenge any notion of altering the long effort of A6 may i suggest that it might be more productive to discuss the engineering need (or not) for it, and stick to principles not personalities? e.g. in the absense of rapid renumbering and gse or other non-v4 routing, what need is sufficiently important to justify a6? if there is none currently, but one arises in the future (and i sure hope something does arise for at least routing), then, if dns mechanisms are needed, appropriate ones can be specified. and those could be a6, i can't prejudge. in the meantime, it would be a real bummer if the current a6 spec, for which there seems to be little documented actual need, was to prejudice designs for critical problems such as routing because some interesting approach would not work with a6. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 03:08:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AA8UWi008742 for ; Sun, 10 Jun 2001 03:08:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AA8U1c008741 for ipng-dist; Sun, 10 Jun 2001 03:08:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AA8RWi008734 for ; Sun, 10 Jun 2001 03:08:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA10416 for ; Sun, 10 Jun 2001 03:08:32 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07658 for ; Sun, 10 Jun 2001 04:08:29 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5AA7Mf02572; Sun, 10 Jun 2001 17:07:22 +0700 (ICT) From: Robert Elz To: Randy Bush cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: References: <200106081658.LAA23187@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jun 2001 17:07:22 +0700 Message-ID: <2570.992167642@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 09 Jun 2001 08:57:28 -0700 From: Randy Bush Message-ID: | e.g. in the absense of rapid renumbering and gse or other non-v4 routing, | what need is sufficiently important to justify a6? Unless something happened to routing I'm not aware of (which is certainly possible), we still need rapid renumbering. So, it isn't in the absence of that... | if there is none | currently, but one arises in the future (and i sure hope something does | arise for at least routing), then, if dns mechanisms are needed, appropriate | ones can be specified. and those could be a6, i can't prejudge. You're proposing that once we get millions of real operational nets running v6, that we'll be able to go change the format of the DNS record that is used to find them all? What mechanism would you suggest exists that makes that feasible? | in the meantime, it would be a real bummer if the current a6 spec, for which | there seems to be little documented actual need, was to prejudice designs | for critical problems such as routing because some interesting approach | would not work with a6. It truly would indeed. Especially as anything that works with AAAA works with A6, given that A6 0 and AAAA are isomorphic. So you're suggesting the possibility of something which wouldn't work with any proposed DNS lookup mechanism - that would be a pain. But to me this looks like FUD? Where's the documented actual design that is being prejudiced by A6? The reason for switching to A6 now, even if we tell people to only ever put A6 0 in their zone files, is because it makes it possible to use it later. If it turns out to be unecessary, then we end up carrying around one extra byte with each address in DNS packets (a 6% overhead on the addresses themselves, less than that once all the rest of the DNS overheads are added (TTL, class, record type, ...) are included in the RDATA). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 03:24:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AAOrWi008801 for ; Sun, 10 Jun 2001 03:24:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AAOrpL008800 for ipng-dist; Sun, 10 Jun 2001 03:24:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AAOoWi008793 for ; Sun, 10 Jun 2001 03:24:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01469 for ; Sun, 10 Jun 2001 03:24:55 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12672 for ; Sun, 10 Jun 2001 04:24:54 -0600 (MDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 1592Og-0000iD-00; Sun, 10 Jun 2001 03:24:42 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting References: <200106081658.LAA23187@gungnir.fnal.gov> <2570.992167642@brandenburg.cs.mu.OZ.AU> Message-Id: Date: Sun, 10 Jun 2001 03:24:42 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> e.g. in the absense of rapid renumbering and gse or other non-v4 routing, >> what need is sufficiently important to justify a6? > Unless something happened to routing I'm not aware of (which is > certainly possible), we still need rapid renumbering. we NEED both, and, imiho, routing far more than rapid renumbering. but, in reality we seem to HAVE neither. > The reason for switching to A6 now, even if we tell people to only ever > put A6 0 in their zone files, is because it makes it possible to use it > later. the set of fun ideas which meet such design criteria may be countable, but its size is large by even astronomers' standards. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 03:48:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AAmJWi008825 for ; Sun, 10 Jun 2001 03:48:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AAmIit008824 for ipng-dist; Sun, 10 Jun 2001 03:48:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AAmFWi008817 for ; Sun, 10 Jun 2001 03:48:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25418 for ; Sun, 10 Jun 2001 03:48:21 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19899 for ; Sun, 10 Jun 2001 04:48:18 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5AAm2f02931; Sun, 10 Jun 2001 17:48:02 +0700 (ICT) From: Robert Elz To: Randy Bush cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: References: <200106081658.LAA23187@gungnir.fnal.gov> <2570.992167642@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Jun 2001 17:48:02 +0700 Message-ID: <2929.992170082@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 10 Jun 2001 03:24:42 -0700 From: Randy Bush Message-ID: | we NEED both, and, imiho, routing far more than rapid renumbering. but, | in reality we seem to HAVE neither. I agree. Which is why I wonder at why you're not supporting A6, as while a DNS record can't possibly affect how routing is done, it can certainly help renumbering, and it is beyond question that A6 can make renumbering happen faster (if I only have to change one RR to renumber my net, I can do that faster than if I have to change 100, even assuming that I am able to do the latter via some kind of global change over a single zone file, which is not necessarily true). And if you only have to fetch one updated RR to know that all my nodes have renumbered, you can do that faster than fetching 100 (or 10,000). Most of the people who aren't supporting A6 seem to be taking the position that renumbering doesn't matter anyway. If that were true, then I'd be more inclined to not bother with A6, even though it might make net admin easier (that side of it can probably mostly be handled by smarter zonefile generation). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 07:39:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AEdAWi008949 for ; Sun, 10 Jun 2001 07:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AEdA7M008948 for ipng-dist; Sun, 10 Jun 2001 07:39:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AEd4Wi008941 for ; Sun, 10 Jun 2001 07:39:05 -0700 (PDT) Received: from lillen (gbl-rem-37 [129.157.174.37]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA00367; Sun, 10 Jun 2001 16:39:05 +0200 (MET DST) Date: Sun, 10 Jun 2001 16:38:57 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: ND6 RFC-STALE state To: Basavaraj Unnibhavi Cc: Ipng , Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have got querry regarding State machine for the reachability state (RFC > 2461) > If reachability state is STALE, no attempt is made to Clear the cache entry. > Why is that ? > If no packets are sent to Neighbor whose state is STALE then entry in cache > remains forever. This allows cache to grow indefinately ???? See section 5.3 in RFC 2461. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 10:07:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AH7CWi009052 for ; Sun, 10 Jun 2001 10:07:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AH7CV9009051 for ipng-dist; Sun, 10 Jun 2001 10:07:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AH78Wi009044 for ; Sun, 10 Jun 2001 10:07:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08558 for ; Sun, 10 Jun 2001 10:07:15 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13160 for ; Sun, 10 Jun 2001 11:07:13 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA12581; Mon, 11 Jun 2001 02:07:32 +0900 (JST) Date: Mon, 11 Jun 2001 01:48:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Lori Napoli" Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6_UNICAST_HOPS and IPV6_HOPLIMT In-Reply-To: References: User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 25 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 5 Jun 2001 12:45:31 -0400, >>>>> "Lori Napoli" said: > Can someone explain how the two options IPv6_UNICAST_HOPS and IPv6_HOPLIMIT > work together. Does IPv6_UNICAST_HOPS override IPV6_HOPLIMIT ? And > IPv6_HOPLIMIT overrides the system configured default? IPV6_HOPLIMIT overrides both IPV6_UNICAST_HOPS and the system configured default. 6.3. Specifying/Receiving the Hop Limit The outgoing hop limit is normally specified with either the IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket option, both of which are described in [RFC-2553]. Specifying the hop limit as ancillary data lets the application override either the kernel's default or a previously specified value, for either a unicast destination or a multicast destination, for a single output operation. (draft-ietf-ipngwg-rfc2292bis-02.txt, which has already expired...) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 10:56:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AHutWi009114 for ; Sun, 10 Jun 2001 10:56:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AHusIV009113 for ipng-dist; Sun, 10 Jun 2001 10:56:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AHuoWi009106 for ; Sun, 10 Jun 2001 10:56:50 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29303 for ; Sun, 10 Jun 2001 10:56:56 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23606 for ; Sun, 10 Jun 2001 10:56:54 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA12811; Mon, 11 Jun 2001 02:57:05 +0900 (JST) Date: Mon, 11 Jun 2001 02:49:58 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <20010608223036.725977BB@starfruit.itojun.org> User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <20010608223036.725977BB@starfruit.itojun.org> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 09 Jun 2001 07:30:36 +0900, >>>>> Jun-ichiro itojun Hagino said: >> You discovered that we have been working with Sun to bring up an IPv6 >> version of the IPng w.g. web pages. It is a new machine and the content >> had not yet been synchronized. Once this was done, we were going to >> announce it. > i see, no problem (and it is a great effort!). me, either. I'm looking forward to seeing the official announce soon. >> It will be easy to have some special IPv6 only reachable content. Please >> send me your suggestions! > dancing steve:-) (just like IPv6-only dancing kame on www.kame.net) that would be nice, although making the content should be much harder than the dancing kame... I also think a collection of mascot characters for each IPv6 implementation would be good (if any, and if they can freely distributed.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 12:13:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AJDRWi009197 for ; Sun, 10 Jun 2001 12:13:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5AJDRwo009196 for ipng-dist; Sun, 10 Jun 2001 12:13:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AJDOWi009189 for ; Sun, 10 Jun 2001 12:13:24 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13886 for ; Sun, 10 Jun 2001 12:13:30 -0700 (PDT) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05674 for ; Sun, 10 Jun 2001 12:13:30 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA78140 for ; Sun, 10 Jun 2001 15:03:30 -0500 Received: from d04mc300.raleigh.ibm.com (d04mc300.raleigh.ibm.com [9.67.228.190]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5AJDT826788 for ; Sun, 10 Jun 2001 15:13:29 -0400 Importance: Normal Subject: Re: IPv6_UNICAST_HOPS and IPV6_HOPLIMT To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Sun, 10 Jun 2001 15:11:35 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/10/2001 03:13:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I should have been more specific with my question. I agree the ancillary data will override the setsockopt. I was really asking what happens if an application does a setsockopt for IPV6_UNICAST_HOPS and IPV6_HOPLIMIT? Does the IPV6_HOPLIMIT replace the value specified by the IPV6_UNICAST_HOPS or are they separate values? Lets say IPV6_UNICAST_HOPS = x, kernel default = z and IPV6_HOPLIMIT = y. Would 'y' be the hoplimit used for a unicast send? Then suppose the application clears the IPV6_HOPLIMIT value. Do we fall back to 'x' (the value specified on IPV6_UNICAST_HOPS) or 'z' (kernel default)? Thanks Lori >>>>> On Tue, 5 Jun 2001 12:45:31 -0400, >>>>> "Lori Napoli" said: > Can someone explain how the two options IPv6_UNICAST_HOPS and IPv6_HOPLIMIT > work together. Does IPv6_UNICAST_HOPS override IPV6_HOPLIMIT ? And > IPv6_HOPLIMIT overrides the system configured default? IPV6_HOPLIMIT overrides both IPV6_UNICAST_HOPS and the system configured default. 6.3. Specifying/Receiving the Hop Limit The outgoing hop limit is normally specified with either the IPV6_UNICAST_HOPS socket option or the IPV6_MULTICAST_HOPS socket option, both of which are described in [RFC-2553]. Specifying the hop limit as ancillary data lets the application override either the kernel's default or a previously specified value, for either a unicast destination or a multicast destination, for a single output operation. (draft-ietf-ipngwg-rfc2292bis-02.txt, which has already expired...) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 10 19:55:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5B2tHWi009561 for ; Sun, 10 Jun 2001 19:55:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5B2tHxt009560 for ipng-dist; Sun, 10 Jun 2001 19:55:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5B2tEWi009553 for ; Sun, 10 Jun 2001 19:55:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29468 for ; Sun, 10 Jun 2001 19:55:21 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA06944 for ; Sun, 10 Jun 2001 19:55:19 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02638; Sun, 10 Jun 2001 22:55:12 -0400 Date: Sun, 10 Jun 2001 22:55:12 -0400 (EDT) From: Jim Bound To: Randy Bush Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I challenge any notion of altering the long effort of A6 > > may i suggest that it might be more productive to discuss the engineering > need (or not) for it, and stick to principles not personalities? principles will be easier once we see a draft for sure. comment on personalities was my input to experts I felt missing from the directorate. just my opinion which I am free to state here. > e.g. in the absense of rapid renumbering and gse or other non-v4 routing, > what need is sufficiently important to justify a6? if there is none > currently, but one arises in the future (and i sure hope something does > arise for at least routing), then, if dns mechanisms are needed, appropriate > ones can be specified. and those could be a6, i can't prejudge. A6 was built, achieved consensus, and is being implemented to verify it works for rapid renumbering. > in the meantime, it would be a real bummer if the current a6 spec, for which > there seems to be little documented actual need, was to prejudice designs > for critical problems such as routing because some interesting approach > would not work with a6. I cannot see A6 doing the above but I await the draft/report eagerly to here the logic why this is valid. I will respond with technical commentary to the technical issues the Directorate states to warrant over-turning the consensus of the IPng working group to make several important DNS IPng specs historic or experimental. Maybe I will be surprised. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 05:53:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BCr3Wi009970 for ; Mon, 11 Jun 2001 05:53:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BCr3DG009969 for ipng-dist; Mon, 11 Jun 2001 05:53:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BCqxWi009962 for ; Mon, 11 Jun 2001 05:52:59 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18191 for ; Mon, 11 Jun 2001 05:53:06 -0700 (PDT) Received: from fw1-a.osis.gov (fw1-a.osis.gov [204.178.104.233]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA16632; Mon, 11 Jun 2001 05:53:05 -0700 (PDT) Received: from neptune.jioc.osis.gov by fw1-a.osis.gov with ESMTP id IAA19664 (InterLock SMTP Gateway 4.2 for osis.gov); Mon, 11 Jun 2001 08:52:53 -0400 (EDT) Received: by neptune.jioc.osis.gov with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Jun 2001 07:51:49 -0500 Message-ID: From: "SESVOLD, DALE" To: "'JIM FLEMING'" , Bill Manning , Marc Blanchet Cc: Alain Durand , fink@es.net, ipng@sunroof.eng.sun.com Subject: RE: Where's the BEEF ? Date: Mon, 11 Jun 2001 07:12:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F275.44D5B130" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0F275.44D5B130 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Would this force all stack developers and application developers to = support more parsing methods? Does this make sense? D -----Original Message----- From: JIM FLEMING [mailto:jfleming@anet.com] Sent: Thursday, June 07, 2001 11:32 PM To: Bill Manning; Marc Blanchet Cc: Alain Durand; fink@es.net; ipng@sunroof.eng.sun.com Subject: Where's the BEEF ? In my opinion, 10.x.x.x from IPv4 is widely recognized as local space. = Why waste more IPv4 space on special purpose addresses ? Now that "IPv8-style" addressing is being more widely used***, one might consider.... 2002:10.x.x.x:0000:0000:10.x.x.x:0000 For IPv16...the more popular examples may be... FEED:10.x.x.x:0000 CAFE:10.x.x.x:0000 BABE:10.x.x.x:0000 BEEF:10.x.x.x:0000 Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of itojun@iijlab.net Sent: Thursday, May 31, 2001 1:17 PM To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com Subject: Re: IPv6 @ interim meeting *** ------------------------------------------------ > as a temporary measure I have configured tunnel to IIJ Palo Alto device. > the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. > > it would be, of course, better to have ipv6 prefix from microsoft > research :-) today we've got a router operated by MS research guys, using 6to4. so my router have went away. 2002:836b:2505:5::/64 itojun -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bill Manning Sent: Thursday, June 07, 2001 11:03 PM To: Marc Blanchet Cc: Alain Durand; Bill Manning; fink@es.net; ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt What you seem to be asking for is something like the v4 delegation 192.0.2.0/24. It was set aside for documentation. My thought is/was that we might reuse the 5f:: prefix that predates the 6bone. % % there was suggestion to not use 3ffe::/16 space so that it can be = later % (humm, do not know how many years...) reclaimed and reused as part of = the % 001b/3 current addressing architecture. So may be something out of % 2000::/3 is the right thing, I don't know, and actually, I don't = care. My % point was to reserve a space, any space, for = documentation/examples/... % purposes. % % Marc. % % At/=C0 12:08 2001-06-06 -0700, Alain Durand you wrote/vous = =E9criviez: % >At 11:50 AM 6/6/2001 -0700, Bill Manning wrote: % > % >> Strong Objections to this tactic. If you want a 6bone = prefix, % >> you should follow the process. Hijacking is bad form. I'm % >> sure Bob would be amenable to making the delegation, but % >> asking is appropriate. % > % >This is the reason why I had Cced Bob to this thread. % > % >Bob: % >- do you think it would be appropriate to use a 6bone ptla for that purpose? % >- what should be the formal process to follow? % >- would you have any preferences? 3ffe:ff00::/24, 3ffe:5550::/28, anything % >else? % > % > - Alain. % > % >-------------------------------------------------------------------- % >IETF IPng Working Group Mailing List % >IPng Home Page: http://playground.sun.com/ipng % >FTP archive: ftp://playground.sun.com/pub/ipng % >Direct all administrative requests to majordomo@sunroof.eng.sun.com % >-------------------------------------------------------------------- % % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C0F275.44D5B130 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Where's the BEEF ?

Would this force all stack developers and application = developers to support more parsing methods?  Does this make = sense?

D

-----Original Message-----
From: JIM FLEMING [mailto:jfleming@anet.com]
Sent: Thursday, June 07, 2001 11:32 PM
To: Bill Manning; Marc Blanchet
Cc: Alain Durand; fink@es.net; = ipng@sunroof.eng.sun.com
Subject: Where's the BEEF ?



In my opinion, 10.x.x.x from IPv4 is widely = recognized as local space. Why
waste more IPv4
space on special purpose addresses ?

Now that "IPv8-style" addressing is being = more
widely used***, one might consider....

2002:10.x.x.x:0000:0000:10.x.x.x:0000


For IPv16...the more popular examples may = be...

FEED:10.x.x.x:0000
CAFE:10.x.x.x:0000
BABE:10.x.x.x:0000
BEEF:10.x.x.x:0000


Jim Fleming
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail= /unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpip= v6/start.asp


-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof= .eng.sun.com]On Behalf Of itojun@iijlab.net
Sent: Thursday, May 31, 2001 1:17 PM
To: ipng@sunroof.eng.sun.com; = ngtrans@sunroof.eng.sun.com
Subject: Re: IPv6 @ interim meeting


*** = ------------------------------------------------
>       as a = temporary measure I have configured tunnel to IIJ Palo Alto = device.
>       the IPv6 = prefix for the meeting room is 3ffe:507:1ff::/64.
>
>       it would = be, of course, better to have ipv6 prefix from microsoft
>       research = :-)

        today = we've got a router operated by MS research guys, using 6to4.
        so my = router have went away.
        2002:836b:2505:5::/64

itojun
-----Original Message-----
From: owner-ipng@sunroof.eng.sun.com
[mailto:owner-ipng@sunroof= .eng.sun.com]On Behalf Of Bill Manning
Sent: Thursday, June 07, 2001 11:03 PM
To: Marc Blanchet
Cc: Alain Durand; Bill Manning; fink@es.net; = ipng@sunroof.eng.sun.com
Subject: Re: wrt: = draft-blanchet-ipngwg-testadd-00.txt


        What you = seem to be asking for is something like the v4
        delegation 192.0.2.0/24.  It was set aside for = documentation.

        My thought = is/was that we might reuse the 5f:: prefix that
        predates = the 6bone.




%
% there was suggestion to not use 3ffe::/16 space so = that it can be later
% (humm, do not know how many years...) reclaimed = and reused as part of the
% 001b/3 current addressing architecture.  So = may be something out of
% 2000::/3 is the right thing, I don't know, and = actually, I don't care. My
% point was to reserve a space, any space, for = documentation/examples/...
% purposes.
%
% Marc.
%
% At/=C0 12:08 2001-06-06 -0700, Alain Durand you = wrote/vous =E9criviez:
% >At 11:50 AM 6/6/2001 -0700, Bill Manning = wrote:
% >
% = >>         Strong = Objections to this tactic.  If you want a 6bone prefix,
% = >>         you should = follow the process. Hijacking is bad form. I'm
% = >>         sure Bob would = be amenable to making the delegation, but
% = >>         asking is = appropriate.
% >
% >This is the reason why I had Cced Bob to this = thread.
% >
% >Bob:
% >- do you think it would be appropriate to use = a 6bone ptla for that
purpose?
% >- what should be the formal process to = follow?
% >- would you have any preferences? = 3ffe:ff00::/24, 3ffe:5550::/28,
anything
% >else?
% >
% = >         - Alain.
% >
% = >--------------------------------------------------------------------=
% >IETF IPng Working Group Mailing List
% >IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
% >FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
% >Direct all administrative requests to = majordomo@sunroof.eng.sun.com
% >-----------------------------------------------= ---------------------
%
%


--
--bill
---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C0F275.44D5B130-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 06:50:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BDoDWi010022 for ; Mon, 11 Jun 2001 06:50:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BDoDAg010021 for ipng-dist; Mon, 11 Jun 2001 06:50:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BDo9Wi010014 for ; Mon, 11 Jun 2001 06:50:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20903 for ; Mon, 11 Jun 2001 06:50:17 -0700 (PDT) Received: from pimout3-int.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01063; Mon, 11 Jun 2001 07:50:53 -0600 (MDT) Received: from jim (ip-111-152-204.chicago-n.navipath.net [64.111.152.204]) by pimout3-int.prodigy.net (8.11.0/8.11.0) with SMTP id f5BDoAg195854; Mon, 11 Jun 2001 09:50:10 -0400 From: "JIM FLEMING" To: "SESVOLD, DALE" , "Marc Blanchet" Cc: "Alain Durand" , , Subject: RE: Where's the BEEF ? Date: Mon, 11 Jun 2001 08:51:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In any stack I have ever worked with, the addresses are already in binary. I am not sure what "parsing" means in that context. As for the 2002 IPv8-style encapsulation trick...that is now a given... http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp As for education....many people now know about IPv4 dotted quads... ...therefore...they can easily learn... 2002:10.9.8.7:0000:0000:10.1.2.3:0000 ...the 10s sort of jump out as "local" addresses the hex 0000s indicate "legacy" and the 2002 follows 2001 a space oddysey... Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -----Original Message----- From: SESVOLD, DALE [mailto:dale.sesvold@jioc.osis.gov] Sent: Monday, June 11, 2001 7:13 AM To: 'JIM FLEMING'; Bill Manning; Marc Blanchet Cc: Alain Durand; fink@es.net; ipng@sunroof.eng.sun.com Subject: RE: Where's the BEEF ? Would this force all stack developers and application developers to support more parsing methods? Does this make sense? D -----Original Message----- From: JIM FLEMING [mailto:jfleming@anet.com] Sent: Thursday, June 07, 2001 11:32 PM To: Bill Manning; Marc Blanchet Cc: Alain Durand; fink@es.net; ipng@sunroof.eng.sun.com Subject: Where's the BEEF ? In my opinion, 10.x.x.x from IPv4 is widely recognized as local space. Why waste more IPv4 space on special purpose addresses ? Now that "IPv8-style" addressing is being more widely used***, one might consider.... 2002:10.x.x.x:0000:0000:10.x.x.x:0000 For IPv16...the more popular examples may be... FEED:10.x.x.x:0000 CAFE:10.x.x.x:0000 BABE:10.x.x.x:0000 BEEF:10.x.x.x:0000 Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of itojun@iijlab.net Sent: Thursday, May 31, 2001 1:17 PM To: ipng@sunroof.eng.sun.com; ngtrans@sunroof.eng.sun.com Subject: Re: IPv6 @ interim meeting *** ------------------------------------------------ > as a temporary measure I have configured tunnel to IIJ Palo Alto device. > the IPv6 prefix for the meeting room is 3ffe:507:1ff::/64. > > it would be, of course, better to have ipv6 prefix from microsoft > research :-) today we've got a router operated by MS research guys, using 6to4. so my router have went away. 2002:836b:2505:5::/64 itojun -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Bill Manning Sent: Thursday, June 07, 2001 11:03 PM To: Marc Blanchet Cc: Alain Durand; Bill Manning; fink@es.net; ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt What you seem to be asking for is something like the v4 delegation 192.0.2.0/24. It was set aside for documentation. My thought is/was that we might reuse the 5f:: prefix that predates the 6bone. % % there was suggestion to not use 3ffe::/16 space so that it can be later % (humm, do not know how many years...) reclaimed and reused as part of the % 001b/3 current addressing architecture. So may be something out of % 2000::/3 is the right thing, I don't know, and actually, I don't care. My % point was to reserve a space, any space, for documentation/examples/... % purposes. % % Marc. % % At/À 12:08 2001-06-06 -0700, Alain Durand you wrote/vous écriviez: % >At 11:50 AM 6/6/2001 -0700, Bill Manning wrote: % > % >> Strong Objections to this tactic. If you want a 6bone prefix, % >> you should follow the process. Hijacking is bad form. I'm % >> sure Bob would be amenable to making the delegation, but % >> asking is appropriate. % > % >This is the reason why I had Cced Bob to this thread. % > % >Bob: % >- do you think it would be appropriate to use a 6bone ptla for that purpose? % >- what should be the formal process to follow? % >- would you have any preferences? 3ffe:ff00::/24, 3ffe:5550::/28, anything % >else? % > % > - Alain. % > % >-------------------------------------------------------------------- % >IETF IPng Working Group Mailing List % >IPng Home Page: http://playground.sun.com/ipng % >FTP archive: ftp://playground.sun.com/pub/ipng % >Direct all administrative requests to majordomo@sunroof.eng.sun.com % >-------------------------------------------------------------------- % % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 16:47:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BNlqWi011322 for ; Mon, 11 Jun 2001 16:47:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5BNlqTv011321 for ipng-dist; Mon, 11 Jun 2001 16:47:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5BNlnWi011314 for ; Mon, 11 Jun 2001 16:47:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06059 for ; Mon, 11 Jun 2001 16:47:56 -0700 (PDT) From: Jonne.Soininen@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02787 for ; Mon, 11 Jun 2001 16:47:55 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5BNlu819512 for ; Mon, 11 Jun 2001 18:47:56 -0500 (CDT) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 11 Jun 2001 18:47:54 -0500 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Mon, 11 Jun 2001 18:47:54 -0500 Message-ID: To: ipng@sunroof.eng.sun.com Subject: RE: Draft Minutes for IPng Interim Meeting Date: Mon, 11 Jun 2001 18:47:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I guess I was supposed to check some issues that were brought up in the interim meeting. I noticed that in Bob's minutes (that are very good BTW) was a question about the attributes in the Traffic Flow Template and if the protocol number was missing. I checked this from 23.060 and the protocol number is not missing. In the following is an extract from 23.060: 15.3.2 Packet Filter Attributes Each valid packet filter contains a unique identifier within a given TFT, an evaluation precedence index that is unique within all TFTs for one PDP address, and at least one of the following attributes: - Source Address and Subnet Mask. - Protocol Number (IPv4) / Next Header (IPv6). - Destination Port Range. - Source Port Range. - IPSec Security Parameter Index (SPI). - Type of Service (TOS) (IPv4) / Traffic class (IPv6) and Mask. - Flow Label (IPv6). You can check 23.060 for further information on the usage of TFT as well. I'm sorry (and really embarrassed) that I did not remember this during the meeting, but had to check it... Cheers, Jonne. -----Original Message----- From: ext Bob Hinden [mailto:hinden@iprg.nokia.com] Sent: Thursday, June 07, 2001 5:40 PM To: ipng@sunroof.eng.sun.com Subject: Draft Minutes for IPng Interim Meeting The draft minutes and most of the presentation materials from last weeks interim IPng working group meeting can be found at: http://playground.sun.com/ipng/meetings.html Please send corrections and updates to me. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 18:25:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C1P1Wi011721 for ; Mon, 11 Jun 2001 18:25:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5C1P114011720 for ipng-dist; Mon, 11 Jun 2001 18:25:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C1OxWi011713 for ; Mon, 11 Jun 2001 18:24:59 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id f5C1L3U11815 for ipng@sunroof.eng.sun.com; Mon, 11 Jun 2001 18:21:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5AJxiWi009225 for ; Sun, 10 Jun 2001 12:59:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05573 for ; Sun, 10 Jun 2001 12:59:48 -0700 (PDT) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA09087 for ; Sun, 10 Jun 2001 13:59:47 -0600 (MDT) Received: from localhost ([127.0.0.1]:62220 "EHLO hactrn.net" ident: "IDENT-NOT-QUERIED [port 62220]") by thrintun.hactrn.net with ESMTP id <23573-219>; Sun, 10 Jun 2001 15:59:42 -0400 To: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: Message from Robert Elz dated "Sun, 10 Jun 2001 17:48:02 +0700" <2929.992170082@brandenburg.cs.mu.OZ.AU> References: <2929.992170082@brandenburg.cs.mu.OZ.AU> <200106081658.LAA23187@gungnir.fnal.gov> <2570.992167642@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: Sun, 10 Jun 2001 15:59:42 -0400 From: Rob Austein Message-Id: <20010610195947Z23573-219+1834@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The basic problem is that neither the IPv6 community nor the DNS community has reached a clear consensus on whether the extra features of A6 over AAAA are worth the extra cost. That's not a euphemism for "have decided that they're not", I really mean that we have people advocating each side in each group and have not answered the question. So we attempted to approach the question from the angle of "what does IPv6 need the DNS to do?" Since that question also appears to be a potential rathole, we tried to focus on the specific areas in which A6 would allow us to do things that can't be done with just AAAA and some preprocessing during zone file generation. All the cases we thought of that would justify A6 appeared to boil down to situations where the DNS data would have to change so fast that it isn't practical to update the DNS that quickly (eg, rapid renumbering, or GSE-like routing). So the question to the IPv6 WGs is: is IPv6 going to be doing these things? If so, AAAA probably is not sufficient, and A6 may be the answer. If not, AAAA may or may not be sufficient, but the new features that A6 provides don't appear to be justified by IPv6's requirements. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 19:03:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C23iWi011924 for ; Mon, 11 Jun 2001 19:03:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5C23iF4011923 for ipng-dist; Mon, 11 Jun 2001 19:03:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C23eWi011916 for ; Mon, 11 Jun 2001 19:03:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27010 for ; Mon, 11 Jun 2001 19:03:45 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA04097 for ; Mon, 11 Jun 2001 19:03:45 -0700 (PDT) Received: from 157.54.9.100 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Jun 2001 18:48:41 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 11 Jun 2001 18:48:38 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Mon, 11 Jun 2001 18:48:33 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Jun 2001 18:47:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft Minutes for IPng Interim Meeting Date: Mon, 11 Jun 2001 18:47:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes for IPng Interim Meeting Thread-Index: AcDy3rSrKFciDf7BSnWa68pDpFM0uwAAmwvw From: "Christian Huitema" To: "Rob Austein" , X-OriginalArrivalTime: 12 Jun 2001 01:47:17.0441 (UTC) FILETIME=[9C8CCB10:01C0F2E1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5C23eWi011917 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I for one believe that we should assume rapid renumbering as a feature of IPv6. The argument for that is the classic "fire escape" analogy. If you don't practice frequent exercises, you find one the day of the actual fire that a clutter of boxes blocks the escape. If we want to be able to renumber when needed, then we should assume that we will renumber frequently. Note however that the window of opportunity is closing fast. In the absence of a strong endorsement of A6, we will start deploying stacks that only do AAAA. Once millions of these have shipped, the issue will be moot. -- Christian Huitema > -----Original Message----- > From: Rob Austein [mailto:sra@hactrn.net] > Sent: Sunday, June 10, 2001 1:00 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: Draft Minutes for IPng Interim Meeting > > The basic problem is that neither the IPv6 community nor the DNS > community has reached a clear consensus on whether the extra features > of A6 over AAAA are worth the extra cost. That's not a euphemism for > "have decided that they're not", I really mean that we have people > advocating each side in each group and have not answered the question. > > So we attempted to approach the question from the angle of "what does > IPv6 need the DNS to do?" Since that question also appears to be a > potential rathole, we tried to focus on the specific areas in which A6 > would allow us to do things that can't be done with just AAAA and some > preprocessing during zone file generation. > > All the cases we thought of that would justify A6 appeared to boil > down to situations where the DNS data would have to change so fast > that it isn't practical to update the DNS that quickly (eg, rapid > renumbering, or GSE-like routing). > > So the question to the IPv6 WGs is: is IPv6 going to be doing these > things? If so, AAAA probably is not sufficient, and A6 may be the > answer. If not, AAAA may or may not be sufficient, but the new > features that A6 provides don't appear to be justified by IPv6's > requirements. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 19:40:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C2e3Wi011991 for ; Mon, 11 Jun 2001 19:40:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5C2e28m011990 for ipng-dist; Mon, 11 Jun 2001 19:40:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C2dwWi011983 for ; Mon, 11 Jun 2001 19:39:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA00630 for ; Mon, 11 Jun 2001 19:40:04 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA17712 for ; Mon, 11 Jun 2001 19:40:03 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 159e66-000CJN-00; Mon, 11 Jun 2001 19:40:02 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Christian Huitema" Cc: ipng@sunroof.eng.sun.com Subject: RE: Draft Minutes for IPng Interim Meeting References: Message-Id: Date: Mon, 11 Jun 2001 19:40:02 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I for one believe that we should assume rapid renumbering as a feature > of IPv6. great! how does it work? not broad desires, but the devilish details please. as i participated in what was possibly the largest renumbering exercise ever conducted O(10^4) *sites*, many of them non-trivial and some rather large, i am quite interested in this. but i am also quite sceptical whether rapid renumbering is really supported in v6. steve d et al. seem less glib about it. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 11 19:52:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C2qoWi012067 for ; Mon, 11 Jun 2001 19:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5C2qnZo012066 for ipng-dist; Mon, 11 Jun 2001 19:52:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C2qjWi012059 for ; Mon, 11 Jun 2001 19:52:45 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-30.EBay.Sun.COM [129.150.4.30]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5C2qjQ354931; Mon, 11 Jun 2001 19:52:45 -0700 (PDT) Message-Id: <5.1.0.14.0.20010611193607.02281c38@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 11 Jun 2001 19:58:16 -0700 To: "Christian Huitema" , "Rob Austein" , From: Alain Durand Subject: RE: Draft Minutes for IPng Interim Meeting In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:47 PM 6/11/2001 -0700, Christian Huitema wrote: >I for one believe that we should assume rapid renumbering as a feature >of IPv6. The argument for that is the classic "fire escape" analogy. If >you don't practice frequent exercises, you find one the day of the >actual fire that a clutter of boxes blocks the escape. If we want to be >able to renumber when needed, then we should assume that we will >renumber frequently. It all depend on the definition of "rapid". If rapid means every "hours" or every "day", I find it very unlikely. Previous experiences in renumbering even small sites have shown me that the overall process can takes weeks, and that there are unavoidable non-technical dependencies and administrative steps that must take place and they consume most of the time. It does not mean that we should stop working on renumbering, however it means that we should have realistic goals, and renumbering every hours or even every day seems to me unrealistic for now.Yes, IPv6, with stateless autoconf and Router Renumbering, has features that help renumbering, but this does not make the event painless nor rapid. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 00:28:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C7SlWi012461 for ; Tue, 12 Jun 2001 00:28:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5C7SlUa012460 for ipng-dist; Tue, 12 Jun 2001 00:28:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5C7SiWi012453 for ; Tue, 12 Jun 2001 00:28:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24841 for ; Tue, 12 Jun 2001 00:28:51 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27474; Tue, 12 Jun 2001 01:28:47 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5C7SWs01765; Tue, 12 Jun 2001 14:28:33 +0700 (ICT) From: Robert Elz To: Alain Durand cc: "Christian Huitema" , "Rob Austein" , ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <5.1.0.14.0.20010611193607.02281c38@jurassic> References: <5.1.0.14.0.20010611193607.02281c38@jurassic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Jun 2001 14:28:32 +0700 Message-ID: <1763.992330912@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 11 Jun 2001 19:58:16 -0700 From: Alain Durand Message-ID: <5.1.0.14.0.20010611193607.02281c38@jurassic> | It all depend on the definition of "rapid". | If rapid means every "hours" or every "day", I find it very unlikely. You're actually talking about the frequency of renumbering there, rather than how quickly a renumbering can be accomplished. Clearly the frequency can't be more than once per renumbering event duration, but it can be much less (if I could renumber in an hour, that doesn't mean I will renumber every hour - but it certainly means I can't renumber faster than that). | Previous experiences in renumbering even small sites have shown me | that the overall process can takes weeks, and that there are unavoidable | non-technical dependencies and administrative steps that must take place | and they consume most of the time. This is the "we don't need good brakes on cars, we know cars don't do faster than people's walking speed, because there has to be someone walking in front of each one waving a red flag" argument ... What we have to work towards, and assume that we will achieve is the ideal target, until it is clear that cannot be reached - rather than assuming that because we haven't achieved it yet, we never will. It used to be that configuring an IP node took considerable time and expertise - then bootp was invented, which made it easier (then that turned into dhcp) - but that (either) still required someone with experience to configure the server. IPv6 has autoconf which makes it easier still. We can do the same with renumbering - that it has been difficult in the past doesn't mean that it must remain so. I want to have it so that once I know a new prefix is available to me, I can have it in use on all my nodes (say 20K of them) in 5 minutes. And simultaneously deprecate an old prefix, if that is appropriate. And then when an old prefix is done with, delete it from all nodes in the same kind of timespan. Note that for the DNS, each of those two is a renumbering event (though if the second (delete) is known when the first (new prefix) is arranged, they might be collapsed into one). From the outside the whole thing may take a month, and be considered to be one long renumbering process (from new prefix appearing to old one vanishing) - to the DNS however there are two separate events that each need to happen rapidly... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 03:19:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CAJSWi012631 for ; Tue, 12 Jun 2001 03:19:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CAJSca012630 for ipng-dist; Tue, 12 Jun 2001 03:19:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CAJOWi012623 for ; Tue, 12 Jun 2001 03:19:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08425 for ; Tue, 12 Jun 2001 03:19:29 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11671 for ; Tue, 12 Jun 2001 04:20:08 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id CA2264B20; Tue, 12 Jun 2001 19:19:24 +0900 (JST) To: Alain Durand Cc: "Christian Huitema" , "Rob Austein" , ipng@sunroof.eng.sun.com In-reply-to: Alain.Durand's message of Mon, 11 Jun 2001 19:58:16 MST. <5.1.0.14.0.20010611193607.02281c38@jurassic> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft Minutes for IPng Interim Meeting From: itojun@iijlab.net Date: Tue, 12 Jun 2001 19:19:24 +0900 Message-ID: <29330.992341164@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>I for one believe that we should assume rapid renumbering as a feature >>of IPv6. The argument for that is the classic "fire escape" analogy. If >>you don't practice frequent exercises, you find one the day of the >>actual fire that a clutter of boxes blocks the escape. If we want to be >>able to renumber when needed, then we should assume that we will >>renumber frequently. > >It all depend on the definition of "rapid". >If rapid means every "hours" or every "day", I find it very unlikely. >Previous experiences in renumbering even small sites have shown me >that the overall process can takes weeks, and that there are unavoidable >non-technical dependencies and administrative steps that must take place >and they consume most of the time. there are a couple of analysis on IPv6 network renumbering available: - Fred Baker's draft (where?) - Jinmei's presentation at IETF49? - I have covered some essentials in draft-ietf-dnsext-aaaa-a6-00. we really need to resurrect Fred's draft. the bottom line is that you cannot renumber more frequently than (DNS TTL * 2), so if you set DNS TTL to 1 day, you can only renumber every other day. every hardcoded address parmeteres in every router/ host will bite you. renumbering is not an easy task. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 04:05:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CB5HWi012665 for ; Tue, 12 Jun 2001 04:05:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CB5GUu012664 for ipng-dist; Tue, 12 Jun 2001 04:05:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CB5CWi012657 for ; Tue, 12 Jun 2001 04:05:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24033 for ; Tue, 12 Jun 2001 04:05:18 -0700 (PDT) Received: from mailrelay1.chek.com (plotnick.chek.com [208.197.227.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA03924 for ; Tue, 12 Jun 2001 05:05:56 -0600 (MDT) Received: (qmail 5852 invoked from network); 12 Jun 2001 11:05:17 -0000 Received: from ninelives.chek.com (208.197.227.14) by mailrelay1.chek.com with SMTP; 12 Jun 2001 11:05:17 -0000 Received: (qmail 29074 invoked by uid 99); 12 Jun 2001 11:02:45 -0000 Date: 12 Jun 2001 11:02:45 -0000 Message-ID: <20010612110245.29073.qmail@ninelives.chek.com> From: "Emanuel Moreira" To: ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org X-MASSMAIL: 1.0 X-Originating-IP: [193.137.173.132] Subject: Advertisements on Cisco/Windows Network Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! I'm using a cisco 1600 router and a windows 2000 PC where I'm trying to configure a 6to4 router so its something like: [IPv6 network]----[Cisco 1600 - 12.03T]----[PC 6to4 router - Tech Preview]--[IPv4 network] So when I configure the two routers I was expecting that the two routers would apprehend the advertisements made by each other but that didn't happen. Can anyone tell me Why? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 05:36:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CCaBWi012816 for ; Tue, 12 Jun 2001 05:36:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CCaBC8012815 for ipng-dist; Tue, 12 Jun 2001 05:36:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CCa8Wi012808 for ; Tue, 12 Jun 2001 05:36:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19324 for ; Tue, 12 Jun 2001 05:36:15 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA26626 for ; Tue, 12 Jun 2001 06:36:53 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA10751; Tue, 12 Jun 2001 08:36:08 -0400 Date: Tue, 12 Jun 2001 08:36:07 -0400 (EDT) From: Jim Bound To: Rob Austein Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <20010610195947Z23573-219+1834@thrintun.hactrn.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rob, Can you give us an idea of when the report will be out? p.s. AAAA is deployed too fyi. thanks /jim On Sun, 10 Jun 2001, Rob Austein wrote: > The basic problem is that neither the IPv6 community nor the DNS > community has reached a clear consensus on whether the extra features > of A6 over AAAA are worth the extra cost. That's not a euphemism for > "have decided that they're not", I really mean that we have people > advocating each side in each group and have not answered the question. > > So we attempted to approach the question from the angle of "what does > IPv6 need the DNS to do?" Since that question also appears to be a > potential rathole, we tried to focus on the specific areas in which A6 > would allow us to do things that can't be done with just AAAA and some > preprocessing during zone file generation. > > All the cases we thought of that would justify A6 appeared to boil > down to situations where the DNS data would have to change so fast > that it isn't practical to update the DNS that quickly (eg, rapid > renumbering, or GSE-like routing). > > So the question to the IPv6 WGs is: is IPv6 going to be doing these > things? If so, AAAA probably is not sufficient, and A6 may be the > answer. If not, AAAA may or may not be sufficient, but the new > features that A6 provides don't appear to be justified by IPv6's > requirements. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 05:38:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CCcOWi012836 for ; Tue, 12 Jun 2001 05:38:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CCcOJs012835 for ipng-dist; Tue, 12 Jun 2001 05:38:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CCcLWi012828 for ; Tue, 12 Jun 2001 05:38:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01061 for ; Tue, 12 Jun 2001 05:38:28 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id FAA18084 for ; Tue, 12 Jun 2001 05:38:27 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11931; Tue, 12 Jun 2001 08:38:24 -0400 Date: Tue, 12 Jun 2001 08:38:23 -0400 (EDT) From: Jim Bound To: Christian Huitema Cc: Rob Austein , ipng@sunroof.eng.sun.com Subject: RE: Draft Minutes for IPng Interim Meeting In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, Excellent point sir. In fact the rate of deployment is increasing right now. The curve is at at initial slope which is TBD but the market will not wait for us to discuss this for two years and deploy AAAA. /jim On Mon, 11 Jun 2001, Christian Huitema wrote: > I for one believe that we should assume rapid renumbering as a feature > of IPv6. The argument for that is the classic "fire escape" analogy. If > you don't practice frequent exercises, you find one the day of the > actual fire that a clutter of boxes blocks the escape. If we want to be > able to renumber when needed, then we should assume that we will > renumber frequently. > > Note however that the window of opportunity is closing fast. In the > absence of a strong endorsement of A6, we will start deploying stacks > that only do AAAA. Once millions of these have shipped, the issue will > be moot. > > -- Christian Huitema > > > -----Original Message----- > > From: Rob Austein [mailto:sra@hactrn.net] > > Sent: Sunday, June 10, 2001 1:00 PM > > To: ipng@sunroof.eng.sun.com > > Subject: Re: Draft Minutes for IPng Interim Meeting > > > > The basic problem is that neither the IPv6 community nor the DNS > > community has reached a clear consensus on whether the extra features > > of A6 over AAAA are worth the extra cost. That's not a euphemism for > > "have decided that they're not", I really mean that we have people > > advocating each side in each group and have not answered the question. > > > > So we attempted to approach the question from the angle of "what does > > IPv6 need the DNS to do?" Since that question also appears to be a > > potential rathole, we tried to focus on the specific areas in which A6 > > would allow us to do things that can't be done with just AAAA and some > > preprocessing during zone file generation. > > > > All the cases we thought of that would justify A6 appeared to boil > > down to situations where the DNS data would have to change so fast > > that it isn't practical to update the DNS that quickly (eg, rapid > > renumbering, or GSE-like routing). > > > > So the question to the IPv6 WGs is: is IPv6 going to be doing these > > things? If so, AAAA probably is not sufficient, and A6 may be the > > answer. If not, AAAA may or may not be sufficient, but the new > > features that A6 provides don't appear to be justified by IPv6's > > requirements. > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 07:06:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CE61Wi012938 for ; Tue, 12 Jun 2001 07:06:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CE61R5012937 for ipng-dist; Tue, 12 Jun 2001 07:06:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CE5uWi012930 for ; Tue, 12 Jun 2001 07:05:57 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09359 for ; Tue, 12 Jun 2001 07:06:02 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01635 for ; Tue, 12 Jun 2001 07:06:02 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA04178; Tue, 12 Jun 2001 09:05:49 -0500 (CDT) Message-Id: <200106121405.JAA04178@gungnir.fnal.gov> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Draft Minutes for IPng Interim Meeting In-reply-to: Your message of Tue, 12 Jun 2001 19:19:24 +0900. <29330.992341164@itojun.org> Date: Tue, 12 Jun 2001 09:05:49 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the bottom line is that you cannot renumber more frequently than > (DNS TTL * 2), so if you set DNS TTL to 1 day, you can only renumber > every other day. And this is true no matter what sort of records you are storing your addresses in. However, consider a large site using two-level A6 records, one for a prefix and one for, say, SLA+IID. For renumbering the site, it's only the TTL of the prefix record that limits the speed of renumbering. If a communicating site talks to many nodes in the potentially-renumbering site, there's only one short-lifetime RR it needs to keep fetching. And recall that ipngwg and the registries have accepted the idea that a person may carry a whole site. The person may be moving at a couple of hundred km/h and while continuous renumbering may not be the preferred mode of maintaining ongoing communication, renumbering at the departure and arrival points is quite plausible. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 08:43:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CFh3Wi013206 for ; Tue, 12 Jun 2001 08:43:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CFh39N013205 for ipng-dist; Tue, 12 Jun 2001 08:43:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CFgxWi013198 for ; Tue, 12 Jun 2001 08:42:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19290 for ; Tue, 12 Jun 2001 08:43:06 -0700 (PDT) Received: from hebe.or.intel.com (jffdns02.or.intel.com [134.134.248.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10484 for ; Tue, 12 Jun 2001 09:43:05 -0600 (MDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by hebe.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id PAA22275; Tue, 12 Jun 2001 15:43:02 GMT Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 12 Jun 2001 15:43:02 0000 (GMT) Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Jun 2001 08:42:59 -0700 Message-ID: From: "Dollinger, MatthewX" To: "'Emanuel Moreira'" , ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org Subject: RE: Advertisements on Cisco/Windows Network Date: Tue, 12 Jun 2001 08:32:12 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I know that the Cisco router needs IOS version 12.2 to handle Ipv6 traffic properly. 12.03 may not give you the results you want, or weird results in general. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 t/122t2/ipv6/index.htm "You know, sometimes it is the artist's task to find out how much music you can still make with what you have left." --- Itzhak Perlman (Nov. 18, 1995,) Matthew Dollinger NQL CDI/Intel -----Original Message----- From: Emanuel Moreira [mailto:emanramor@portugalmail.com] Sent: Tuesday, June 12, 2001 4:03 AM To: ipng@sunroof.eng.sun.com; msripv6-users@list.research.microsoft.com; users@ipv6.org Subject: Advertisements on Cisco/Windows Network Hi! I'm using a cisco 1600 router and a windows 2000 PC where I'm trying to configure a 6to4 router so its something like: [IPv6 network]----[Cisco 1600 - 12.03T]----[PC 6to4 router - Tech Preview]--[IPv4 network] So when I configure the two routers I was expecting that the two routers would apprehend the advertisements made by each other but that didn't happen. Can anyone tell me Why? Thanks Emanuel Moreira _____________________________________________________________ O e-mail preferido dos portugueses http://www.portugalmail.pt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 09:10:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CGAWWi013256 for ; Tue, 12 Jun 2001 09:10:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CGAVwL013255 for ipng-dist; Tue, 12 Jun 2001 09:10:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CGASWi013248 for ; Tue, 12 Jun 2001 09:10:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03622 for ; Tue, 12 Jun 2001 09:10:35 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA07454 for ; Tue, 12 Jun 2001 10:10:31 -0600 (MDT) Received: from 157.54.9.104 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 12 Jun 2001 08:57:59 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 12 Jun 2001 08:57:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 12 Jun 2001 08:57:46 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 12 Jun 2001 08:56:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft Minutes for IPng Interim Meeting Date: Tue, 12 Jun 2001 08:56:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft Minutes for IPng Interim Meeting Thread-Index: AcDy6NQ4wMulhZNoQ/6WOUjJ2RTqvQAawB5Q From: "Christian Huitema" To: "Randy Bush" Cc: X-OriginalArrivalTime: 12 Jun 2001 15:56:29.0552 (UTC) FILETIME=[3E5FEF00:01C0F358] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5CGASWi013249 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I for one believe that we should assume rapid renumbering as a feature > > of IPv6. > > great! how does it work? not broad desires, but the devilish details > please. This is a perfectly reasonable request. I believe that the correct answer is "draft the scenarios, plan the technology, demonstrate and drill." So, lets first agree on a set of scenarios. I propose the following five: Scenario 1, first connection: A site is currently isolated. The internal subnets have been numbered using "site local" addresses. The site joins the IPv6 Internet. The site managers use "Router Renumbering for IPv6" (RFC 2894) to automatically inform the internal routers that they should start advertising the new prefix. The hosts receive a router advertisement and automatically create a global address as specified in "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 2, disconnection: A site is currently connected to the Internet. The site managers plan to disconnect. This occurs in two phases, first deprecating the old prefix, then removing it. Both phases are implemented using "Router Renumbering for IPv6" (RFC 2894) and "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 3, multi-homing: A site is connected to the Internet through a single provider. The site managers set a contract with another provider, and obtain a new prefix. The site managers use "Router Renumbering for IPv6" (RFC 2894) to automatically inform the internal routers that they should start advertising the new prefix. The hosts receive a router advertisement and automatically create a second global address as specified in "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 4, removing a provider: A site is connected to the Internet through two providers. The site managers want to terminate the contract with one of these providers. This occurs in two phases, first deprecating the old prefix, then removing it. Both phases are implemented using "Router Renumbering for IPv6" (RFC 2894) and "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 5, time-of-day preference: A site is connected to the Internet through two providers. These providers use different tariffs. The site managers desire that one of the providers be preferred during working hours, say from 9:00 am to 5:00 pm, and another be preferred during the rest of the day. They use "Router Renumbering for IPv6" (RFC 2894) at critical times (9:00 am, 6:00 pm) to deprecate one of the global prefixes and promote the other. The hosts receive router advertisements and heed them as specified in "IPv6 Stateless Address Autoconfiguration" (RFC 2462). You will indeed notice that these scenarios are broadly sketched. The purpose of the scenarios is indeed to discover whatever is missing in our toolbox. For example, we say nothing of "static address filters" used for QoS and security purposes; we may guess that these could be updated as a side effect of router renumbering, but we would be better offwith a real specification. More to the point, we say nothing about DNS interaction. We know the requirement, as Itojun pointed it: addresses should remain valid for as long as the TTL of the DNS record; this is addressed in the scenarios 2 and 4 through a two phase approach, first deprecate a prefix, then at the end of the TTL remove it. When it comes to creating new addresses, or deprecating them, we really have two choices. One possibility is to let the hosts use dynamic DNS updates to create or update AAAA or A6 records on the fly; another possibility is to have the site managers update the AAAA or A6 records in a reference file. We have to analyse the benefit/cost of AAAA/A6 in this context. But first, let's agree on the scenarios. Do we believe that they are realistic? Can we qualify them with a "frequency indicator," e.g. once in a life-time, once a year, once a month, once a day? Is there a big scenario that we are missing, such as maybe provider mandated renumbering, or the merging of independent sites? -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 10:02:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CH2iWi013411 for ; Tue, 12 Jun 2001 10:02:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CH2iSM013410 for ipng-dist; Tue, 12 Jun 2001 10:02:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CH2eWi013403 for ; Tue, 12 Jun 2001 10:02:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07058 for ; Tue, 12 Jun 2001 10:02:48 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19509 for ; Tue, 12 Jun 2001 10:02:46 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5CH2Is03277; Wed, 13 Jun 2001 00:02:18 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: "Randy Bush" , ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 00:02:18 +0700 Message-ID: <3275.992365338@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 12 Jun 2001 08:56:29 -0700 From: "Christian Huitema" Message-ID: | But first, let's agree on the scenarios. Do we believe that they are | realistic? They look reasonable to me. | Can we qualify them with a "frequency indicator," e.g. once | in a life-time, once a year, once a month, once a day? Given that #5 needs to be N times a day (twice as stated), if we can handle that one, then we should be able to handle all the others up to at least once a day frequency, even if they're not likely to occur nearly that often. | Is there a big scenario that we are missing, I'm sure there are other rationales for renumbering that can be invented, but (other than as noted below) they all turn into add a prefix and/or delete a prefix, and those seem to be covered... | such as maybe provider mandated renumbering, Aside from having less other (unrelated to addressing) configuration changes to manage (no new leased lines, or changed phone numbers, etc) this is no different from changing providers. So it is covered. But ... | or the merging of independent sites? This one is the noticeably different case. That's where the internal numbering of a site may need to be radically altered (there isn't one change that applies everywhere). So, this one can be noticeably harder, at the very least, a new addressing plan needs to be created. That's not needed for any kind of external prefix change (another of the benefits of having fixed sized address block allocations from all providers). Fortunately though, this one generally is a rare event, is usually known and can be planned for well in advance, and the disruptions that occur are usually occurring in all kinds of other fields as well, not just the network, so people tend to be a little more forgiving (eg: people are more likely to curse when the merged payroll division doesn't manage to get anyone's salary paid on time, than when the net is flaky for half a day due to the numbering changes not having propagated properly). Lots of other internal renumbering events follow much the same pattern. These ones are the ones least worth worrying about (not that making them easier won't be a benefit, just they're not the highest priority). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 10:04:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CH4dWi013434 for ; Tue, 12 Jun 2001 10:04:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CH4cYJ013433 for ipng-dist; Tue, 12 Jun 2001 10:04:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CH4ZWi013426 for ; Tue, 12 Jun 2001 10:04:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16428 for ; Tue, 12 Jun 2001 10:04:43 -0700 (PDT) Received: from cisco.com (europe.cisco.com [144.254.52.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA20739 for ; Tue, 12 Jun 2001 10:04:41 -0700 (PDT) Received: from PGROSSET-W2K.cisco.com (pgrosset-isdn-home.cisco.com [10.49.89.26]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id TAA03577; Tue, 12 Jun 2001 19:04:30 +0200 (MET DST) Message-Id: <4.3.2.7.2.20010612190300.03b23c60@europe.cisco.com> X-Sender: pgrosset@europe.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Jun 2001 19:04:27 +0200 To: "Dollinger, MatthewX" From: Patrick Grossetete Subject: RE: Advertisements on Cisco/Windows Network Cc: "'Emanuel Moreira'" , ipng@sunroof.eng.sun.com, msripv6-users@list.research.microsoft.com, users@ipv6.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Appropriate release to get IPv6 support is Cisco IOS 12.2(2)T now available on CCO (www.cisco.com) software center. Note that 12.2(2)T was previously referred as 12.2(1)T. Regards Patrick At 08:32 AM 12-06-01 -0700, Dollinger, MatthewX wrote: >I know that the Cisco router needs IOS version 12.2 to handle Ipv6 traffic >properly. 12.03 may not give you the results you want, or weird results in >general. >http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122 >t/122t2/ipv6/index.htm > > > >"You know, sometimes it is the artist's task to find out how much music you >can still make with what you have left." --- Itzhak Perlman (Nov. 18, >1995,) >Matthew Dollinger >NQL >CDI/Intel > > -----Original Message----- >From: Emanuel Moreira [mailto:emanramor@portugalmail.com] >Sent: Tuesday, June 12, 2001 4:03 AM >To: ipng@sunroof.eng.sun.com; msripv6-users@list.research.microsoft.com; >users@ipv6.org >Subject: Advertisements on Cisco/Windows Network > >Hi! > >I'm using a cisco 1600 router and a windows 2000 PC where I'm trying to >configure a 6to4 router so its something like: >[IPv6 network]----[Cisco 1600 - 12.03T]----[PC 6to4 router - Tech >Preview]--[IPv4 network] >So when I configure the two routers I was expecting that the two routers >would apprehend the advertisements made by each other but that didn't >happen. Can anyone tell me Why? > >Thanks > >Emanuel Moreira > >_____________________________________________________________ >O e-mail preferido dos portugueses http://www.portugalmail.pt >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 11:13:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CIDYWi013651 for ; Tue, 12 Jun 2001 11:13:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5CIDYW4013650 for ipng-dist; Tue, 12 Jun 2001 11:13:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5CIDUWi013643 for ; Tue, 12 Jun 2001 11:13:30 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20512; Tue, 12 Jun 2001 14:13:35 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.3+Sun/8.11.3) with ESMTP id f5CID5C08494; Tue, 12 Jun 2001 14:13:05 -0400 (EDT) Message-Id: <200106121813.f5CID5C08494@thunk.east.sun.com> From: Bill Sommerfeld To: Robert Elz cc: "Christian Huitema" , "Randy Bush" , ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-reply-to: Your message of "Wed, 13 Jun 2001 00:02:18 +0700." <3275.992365338@brandenburg.cs.mu.OZ.AU> Reply-to: sommerfeld@east.sun.com Date: Tue, 12 Jun 2001 14:13:04 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Can we qualify them with a "frequency indicator," e.g. once > | in a life-time, once a year, once a month, once a day? > > Given that #5 needs to be N times a day (twice as stated), if we can > handle that one, then we should be able to handle all the others up to > at least once a day frequency, even if they're not likely to occur > nearly that often. One additional concern I've heard raised is the interaction between renumbering, AAAA, and dnssec -- specifically, the cost of re-signing a zone with new addresses. The careful sysadmin would do this after the new prefix was known, but before the new prefix started to be used. How much compute power does this take? A fair amount, for large zones. As an unscientific test, during the dnsext meeting in minneapolis I took the mit.edu zone (with about 82000 hosts), synthesized AAAA records for all hosts, and signed it using the tools included with a recent bind 9 release. The effort required to re-sign scales linearly with the number of RR's changed. Fortunately, this task is paralleizeable; however, the processors doing the work must be trusted with the zone's private key. Folks with appropriate levels of paranoia likely won't want to do much else with this hardware besides maintain the zone(s). In the absence of DNAME, a roughly similar re-signing effort is required for PTR zones. My recollection was that signing the synthesized zone took roughly 90 minutes on my laptop -- a 333mhz celeron. so, for a rough order-of-magnitude guesstimate, 1000 signatures per minute on this system. Since you need two signatures per address (one on AAAA, one on PTR), figure on being able to re-sign 1500 addresses per minute per GHz of cpu. Renumbering a million-address network would take a bit over 11 GHz-hours of cpu time just for the dnssec signatures alone. Note that resigning needs to be complete before the RR's can be replaced -- i.e., the time for renumbering to be complete is the resigning time plus the TTL... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 17:08:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D084Wi014465 for ; Tue, 12 Jun 2001 17:08:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D084Vn014464 for ipng-dist; Tue, 12 Jun 2001 17:08:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D07wWi014457 for ; Tue, 12 Jun 2001 17:07:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA25981 for ; Tue, 12 Jun 2001 17:08:04 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29701 for ; Tue, 12 Jun 2001 18:08:03 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id DF5214B20; Wed, 13 Jun 2001 09:07:58 +0900 (JST) To: sommerfeld@east.sun.com Cc: ipng@sunroof.eng.sun.com In-reply-to: sommerfeld's message of Tue, 12 Jun 2001 14:13:04 -0400. <200106121813.f5CID5C08494@thunk.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft Minutes for IPng Interim Meeting From: itojun@iijlab.net Date: Wed, 13 Jun 2001 09:07:58 +0900 Message-ID: <5700.992390878@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Since you need two signatures per address (one on AAAA, one on PTR), >figure on being able to re-sign 1500 addresses per minute per GHz of >cpu. Renumbering a million-address network would take a bit over 11 >GHz-hours of cpu time just for the dnssec signatures alone. the signing cost consideration really depends on two parameters: - how often do we want to renumber - how large is the network to get renumbered both must carefully be considered to diagnose if A6 gives you more benefits or more costs. because of other constraints like below, i don't think i (of any admin) ever want try to renumber a site with million nodes. renumber is a major task which needs a lot of planning. - if you have hardcoded address in any of your router/host configs, you will be in trouble (example: IBGP peer settings, /etc/named.conf for zone transfer, packet filtering, anything that is written by numeric IPv6 address). - to avoid canopener-in-can situation for records pointed to by NS records, nameservers basically has to have "A6 0" records. so for these records we don't have benefit from fragmented A6 records. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 12 17:27:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D0RqWi014539 for ; Tue, 12 Jun 2001 17:27:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D0RqKl014538 for ipng-dist; Tue, 12 Jun 2001 17:27:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D0RmWi014531 for ; Tue, 12 Jun 2001 17:27:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19628 for ; Tue, 12 Jun 2001 17:27:56 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10283 for ; Tue, 12 Jun 2001 18:27:54 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 96CA94B20; Wed, 13 Jun 2001 09:27:50 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Tue, 12 Jun 2001 14:28:32 +0700. <1763.992330912@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft Minutes for IPng Interim Meeting From: itojun@iijlab.net Date: Wed, 13 Jun 2001 09:27:50 +0900 Message-ID: <5906.992392070@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | It all depend on the definition of "rapid". > | If rapid means every "hours" or every "day", I find it very unlikely. >You're actually talking about the frequency of renumbering there, rather >than how quickly a renumbering can be accomplished. Clearly the frequency >can't be more than once per renumbering event duration, but it can be much >less (if I could renumber in an hour, that doesn't mean I will renumber >every hour - but it certainly means I can't renumber faster than that). i don't understand what is the point in this sentence... yeah, the following invariant is true: frequency of renumbering >= the time needed for renumbering but what's the point? for the purpose of analysis of A6, are you suggesting which parameter is more important than which? could you clarify if possible? (or, if it is not the point please forget about this note) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 01:13:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D8DpWi015017 for ; Wed, 13 Jun 2001 01:13:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D8Dpd3015016 for ipng-dist; Wed, 13 Jun 2001 01:13:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D8DlWi015009 for ; Wed, 13 Jun 2001 01:13:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11185 for ; Wed, 13 Jun 2001 01:13:53 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA17217 for ; Wed, 13 Jun 2001 01:13:51 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5D8DOm01228; Wed, 13 Jun 2001 15:13:27 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <5906.992392070@itojun.org> References: <5906.992392070@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 15:13:24 +0700 Message-ID: <1226.992420004@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 13 Jun 2001 09:27:50 +0900 From: itojun@iijlab.net Message-ID: <5906.992392070@itojun.org> | i don't understand what is the point in this sentence... yeah, Sorry about that, it is a common complaint about my writing, I shall try to do better. | for the purpose of analysis of A6, | are you suggesting which parameter is more important than which? | could you clarify if possible? (or, if it is not the point please | forget about this note) What I was trying to say was that people often look at renumbering and say "I am never going to want to renumber every day, if I do it once a year it will be too frequent" which may well turn out to be true. However, it isn't the frequency of renumbering that matters really here, what counts is how rapidly I can renumber when I need to - how much work do I have to do to complete the renumbering sequence, and how long is that going to take me? If I can get the renumbering down to the state where I can complete the whole thing in under a day, then I could renumber every day if I had to, but this doesn't mean that is what I will ever do. On the other hand, saying "no-one will need to renumber more frequently than once a month, as we'll always be able to let people keep their old addresses that long during a transition" doesn't mean that the renumbering event can be allowed take a month to be completed (a transition is usually going to be two renumbering events, neither of which should take anything like a half month even). In your reply to Bill Sommerfeld you pointed out two other issues ... - if you have hardcoded address in any of your router/host configs, you will be in trouble (example: IBGP peer settings, /etc/named.conf for zone transfer, packet filtering, anything that is written by numeric IPv6 address). This is absolutely true, and a reason we must strive to avoid all such numerically encoded configurations. Even if it just means writing the relevant config files using names, and then pre-processing them with a script that does DNS lookups and converts the names to numbers, and while doing so, remembers the minimum TTL it encountered, and re-schedules itself to be run after that many seconds - and then any time the resulting numerically encoded files change, causing them to be reloaded into the appropriate router/process. This is something of a crude and inefficient way to avoid configuring static addresses anywhere, but it is better than the alternatives. - to avoid canopener-in-can situation for records pointed to by NS records, nameservers basically has to have "A6 0" records. so for these records we don't have benefit from fragmented A6 records. Yes, the NS records are (at the very least in the medium term, and perhaps forever) going to have to be associated with names where the benefits of A6 are unlikely to be achieved. For some truly huge organisations there may be 30 or 40 systems running as published nameservers (nameservers running not listed in any NS records don't count of course). Each of those may have half a dozen A6 0 records associated with them perhaps (just guessing at averages). So, there could be 200-300 records in addition to a few "prefix" A6 records to be updated when a prefix changes. This still seems manageable to me, and still a big win over having to update tens of thousands of AAAA records. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 02:14:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D9EFWi015088 for ; Wed, 13 Jun 2001 02:14:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D9EF52015087 for ipng-dist; Wed, 13 Jun 2001 02:14:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D9EBWi015080 for ; Wed, 13 Jun 2001 02:14:11 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06193 for ; Wed, 13 Jun 2001 02:14:20 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11004 for ; Wed, 13 Jun 2001 02:14:18 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 559A14B20; Wed, 13 Jun 2001 18:14:14 +0900 (JST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Wed, 13 Jun 2001 15:13:24 +0700. <1226.992420004@brandenburg.cs.mu.OZ.AU> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Draft Minutes for IPng Interim Meeting From: itojun@iijlab.net Date: Wed, 13 Jun 2001 18:14:14 +0900 Message-ID: <12614.992423654@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >On the other hand, saying "no-one will need to renumber more frequently than >once a month, as we'll always be able to let people keep their old addresses >that long during a transition" doesn't mean that the renumbering event can be >allowed take a month to be completed (a transition is usually going to be two >renumbering events, neither of which should take anything like a half month >even). sorry if any of my past draft/presentations/postings/whatever sounded like that. i was trying to analyze the minimal possible frequency for renumber, so that we can understand what is the true requirement to IPv6 DNS records. i should make it clearer next time. the fact i've learned is that, once we advertise a DNS record (with old /48 prefix we are trying to get rid of), we cannot remove them till TTL for these record expires (since the record may be cached somewhere in the world). the "frequency of renumber" analysis is the extreme case for this. if we are going to use fragmented A6 records, we really need to diagnose relationship between the following items: - minimal possible frequency for renumber event - timing parameter for DNS, including record TTL, (accumulated) query delays for each fragments, and such. the delay analysis is highly critical, IMHO (there were clarification from Rob, but it still does worry me and i plan to do more diagonsis). >Yes, the NS records are (at the very least in the medium term, and perhaps >forever) going to have to be associated with names where the benefits of >A6 are unlikely to be achieved. For some truly huge organisations there >may be 30 or 40 systems running as published nameservers (nameservers >running not listed in any NS records don't count of course). Each of those >may have half a dozen A6 0 records associated with them perhaps (just guessing >at averages). So, there could be 200-300 records in addition to a few >"prefix" A6 records to be updated when a prefix changes. This still seems >manageable to me, and still a big win over having to update tens of thousands >of AAAA records. to help signing zone file with mixture of "A6 0" and "A6 x" (x != 0) we at least need a better signing tool... with the current BIND9 tool we can only sign the whole zone. and again, zone signing cost analysis has to take a lot of things into account, like timing constraints, deployment issues and reality in needs of renumber... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 02:59:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D9xeWi015118 for ; Wed, 13 Jun 2001 02:59:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5D9xdUI015117 for ipng-dist; Wed, 13 Jun 2001 02:59:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5D9xaWi015110 for ; Wed, 13 Jun 2001 02:59:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08984 for ; Wed, 13 Jun 2001 02:59:43 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19600 for ; Wed, 13 Jun 2001 02:59:40 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5D9xIm01927; Wed, 13 Jun 2001 16:59:22 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: Draft Minutes for IPng Interim Meeting In-Reply-To: <12614.992423654@itojun.org> References: <12614.992423654@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Jun 2001 16:59:18 +0700 Message-ID: <1925.992426358@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 13 Jun 2001 18:14:14 +0900 From: itojun@iijlab.net Message-ID: <12614.992423654@itojun.org> | sorry if any of my past draft/presentations/postings/whatever sounded | like that. i was trying to analyze the minimal possible frequency | for renumber, so that we can understand what is the true requirement | to IPv6 DNS records. i should make it clearer next time. It isn't so much your writings as a general attitude that I seem to be detecting sometimes - that in practice renumbering isn't going to be needed as frequently as some feared in the early IPng discussions, and that consequently, renumbering isn't so important, and stuff which is there to support it really isn't needed after all. Incidentally, while I doubt anyone has any difficulty understanding what you mean, you really mean the minimum period (or duration) of renumbering, or the maximum frequency, discovering the minimum frequency wouldn't be an interesting thing to look for ... | the fact i've learned is that, once we advertise a DNS record | (with old /48 prefix we are trying to get rid of), we cannot remove | them till TTL for these record expires (since the record may be | cached somewhere in the world). We can't remove the prefix until the TTL on any record that includes the prefix has expired (TTL + zone refresh time to be even more accurate), that's for sure. Though, of course we can, and people do that kind of thing every day - it just breaks things for a while in mysterious ways that just "fix themselves" eventually - but it is not good at all. In general we're probably going to want to leave prefixes listed and deprecated for even longer than required by DNS TTLs, so open connections using the things can keep on working - but there's certainly a relationship between the value of the TTL, and how quickly an address can (safely) go away completely. | to help signing zone file with mixture of "A6 0" and "A6 x" (x != 0) | we at least need a better signing tool... I have no doubt but that we need a whole bunch of all kinds of better tools. This doesn't surprise me in the least. I would be the last to claim that we're anywhere near being able to do quick renumbering today. I just don't want to erect barriers that will prevent us from getting there someday. Software can be written and distributed to those who need it (you have plenty of experience with that...) But people's operational habits are extremely hard to alter, as is getting someone else to support something new because it will be easier for me (or you). | and again, zone signing cost analysis has to take a lot of things | into account, Yes, but it isn't only signing costs that are relevant here (though they are certainly one factor). There's also how effective the DNS caches are to be allowed to be. That is, when you are planning to renumber a common way is to reduce the TTLs on all the old records first, so that when the change hits things won't be so affected by the "wait for old records to expire" factor you referred to. So, what is usually a one day TTL might become a 30 minute TTL for the records to be changed. (That is going to require re-signing as well...) Then when the change happens the old addresses don't need to be kept around as long. But of course, now all the DNS caches all over are fetching data from the servers much more frequently than they used to - that's what we wanted of course when the TTL was decreased, but it is an extra load on the net, and longer delays for name lookups. With just a few records with short TTLs (the ones that contain the prefix, rather than all of those that refer to the prefix) that problem ought to be able to be reduced, while still reaping the benefits. With IPv6's ability to have multiple addresses (with the effects of that properly defined, etc) this probably isn't as big an issue as it could have been - as it is OK if others keep using deprecated addresses to reach us, so there should tend to be less "old address works until time N, after that new address works" that usually happens with IPv4 renumberings. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 07:36:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DEaDWi015398 for ; Wed, 13 Jun 2001 07:36:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DEaD9G015397 for ipng-dist; Wed, 13 Jun 2001 07:36:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DEa9Wi015390 for ; Wed, 13 Jun 2001 07:36:09 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15240 for ; Wed, 13 Jun 2001 07:36:15 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08557 for ; Wed, 13 Jun 2001 08:36:14 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA07287; Wed, 13 Jun 2001 09:35:59 -0500 (CDT) Message-Id: <200106131435.JAA07287@gungnir.fnal.gov> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Draft Minutes for IPng Interim Meeting In-reply-to: Your message of Wed, 13 Jun 2001 09:07:58 +0900. <5700.992390878@itojun.org> Date: Wed, 13 Jun 2001 09:35:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the signing cost consideration really depends on two parameters: > - how often do we want to renumber No, not the frequency, the latency. That is, how quickly from the word "go" do you want to have a change in the set of prefixes be implemented? > because of other constraints like below, i don't think i (of any admin) > ever want try to renumber a site with million nodes. The *node* count had just better not matter, because we should expect the number of nodes per {person, house, site, corporation, network} to increase amazingly during the intended lifetime of IPv6, even if we can't describe just what all those new nodes will do. > renumber is a major task which needs a lot of planning. But do we commit ourselves to *making* it impossible forever, or do we do what we can toward easing it? > - if you have hardcoded address in any of your router/host configs, > you will be in trouble (example: IBGP peer settings, /etc/named.conf > for zone transfer, packet filtering, anything that is written by > numeric IPv6 address). I agree that if we have hardcoded addresses in *hosts*, the game is over. Eliminating them is an interesting problem, and eliminating them from routers is even more so. > - to avoid canopener-in-can situation for records pointed to by NS > records, nameservers basically has to have "A6 0" records. > so for these records we don't have benefit from fragmented A6 records. You could do the same thing that's suggested for glue in section 5.1.2. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 07:51:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DEpbWi015417 for ; Wed, 13 Jun 2001 07:51:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DEpbJH015416 for ipng-dist; Wed, 13 Jun 2001 07:51:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DEpWWi015409 for ; Wed, 13 Jun 2001 07:51:33 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA17094 for ; Wed, 13 Jun 2001 07:51:39 -0700 (PDT) Received: from drugs.dv.isc.org (drugs.dv.isc.org [130.155.191.236]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13128 for ; Wed, 13 Jun 2001 07:51:37 -0700 (PDT) Received: from nominum.com (localhost.dv.isc.org [127.0.0.1]) by drugs.dv.isc.org (8.11.3/8.11.2) with ESMTP id f5DEoru01528; Thu, 14 Jun 2001 00:50:53 +1000 (EST) (envelope-from marka@nominum.com) Message-Id: <200106131450.f5DEoru01528@drugs.dv.isc.org> To: Robert Elz Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com From: Mark.Andrews@nominum.com Subject: Re: Draft Minutes for IPng Interim Meeting In-reply-to: Your message of "Wed, 13 Jun 2001 16:59:18 +0700." <1925.992426358@brandenburg.cs.mu.OZ.AU> Date: Thu, 14 Jun 2001 00:50:52 +1000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So, what is usually a one day > TTL might become a 30 minute TTL for the records to be changed. (That > is going to require re-signing as well...) Actually you don't need to resign so long as the TTL stays within the original ttl value when the record was signed. This property is required for caches and there is no reason why authoritative servers can't take advantage of it. Mark -- Mark Andrews, Nominum Inc. 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark.Andrews@nominum.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 08:01:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DF1SWi015442 for ; Wed, 13 Jun 2001 08:01:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DF1Rv0015441 for ipng-dist; Wed, 13 Jun 2001 08:01:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DF1NWi015434 for ; Wed, 13 Jun 2001 08:01:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18450 for ; Wed, 13 Jun 2001 08:01:30 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19461 for ; Wed, 13 Jun 2001 08:01:30 -0700 (PDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.2/8.11.2) with ESMTP id f5DF1PZ20844; Wed, 13 Jun 2001 08:01:25 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f5DF1Pa15776; Wed, 13 Jun 2001 08:01:25 -0700 Message-Id: <200106131501.f5DF1Pa15776@zed.isi.edu> Subject: Re: Draft Minutes for IPng Interim Meeting To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 13 Jun 2001 08:01:25 -0700 (PDT) Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: <200106131435.JAA07287@gungnir.fnal.gov> from "Matt Crawford" at Jun 13, 2001 09:35:59 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % > - if you have hardcoded address in any of your router/host configs, % > you will be in trouble (example: IBGP peer settings, /etc/named.conf % > for zone transfer, packet filtering, anything that is written by % > numeric IPv6 address). % % I agree that if we have hardcoded addresses in *hosts*, the game is % over. Eliminating them is an interesting problem, and eliminating % them from routers is even more so. dont forget your friendly neighborhood SNMP. (most of this was discussed in the long dead PIER wg) -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 08:06:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DF6UWi015481 for ; Wed, 13 Jun 2001 08:06:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DF6UFd015480 for ipng-dist; Wed, 13 Jun 2001 08:06:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DF6QWi015473 for ; Wed, 13 Jun 2001 08:06:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07345 for ; Wed, 13 Jun 2001 08:06:33 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04943 for ; Wed, 13 Jun 2001 09:06:31 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA07403; Wed, 13 Jun 2001 09:59:40 -0500 (CDT) Message-Id: <200106131459.JAA07403@gungnir.fnal.gov> To: Robert Elz Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Draft Minutes for IPng Interim Meeting In-reply-to: Your message of Wed, 13 Jun 2001 16:59:18 +0700. <1925.992426358@brandenburg.cs.mu.OZ.AU> Date: Wed, 13 Jun 2001 09:59:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > , you really mean the minimum period (or duration) of renumbering, > or the maximum frequency, discovering the minimum frequency wouldn't be > an interesting thing to look for ... Oh, but it would be! What is the minimum frequency of renumbering that would be required to keep routing functional with current BGP technology and aggregation techniques? Unfortunately, I don't think we have a good handle on the information needed to answer this question. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 09:28:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DGS2Wi015740 for ; Wed, 13 Jun 2001 09:28:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DGS2qN015739 for ipng-dist; Wed, 13 Jun 2001 09:28:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DGRwWi015732 for ; Wed, 13 Jun 2001 09:27:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06040 for ; Wed, 13 Jun 2001 09:28:06 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19551 for ; Wed, 13 Jun 2001 10:25:22 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA73020 for ; Wed, 13 Jun 2001 12:18:34 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5DGPMY70156 for ; Wed, 13 Jun 2001 12:25:22 -0400 Subject: getsockopt() for IPV6_HOPLIMIT To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Wed, 13 Jun 2001 12:24:31 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/13/2001 12:25:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm struggling to get my hands around the interaction between IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, and IPV6_MULTICAST_HOPS. It seems pretty straight forward if IPV6_HOPLIMIT is specified as ancilliary data - IPV6_HOPLIMIT overrides the current hoplimit for that packet only. But what about when IPV6_HOPLIMIT is set using setsockopt()? Using setsockopt() calls, I think the behavior would be as follows: Unicast Hop Limit Multicast Hop Limit ----------------- ------------------- default 255 1 IPV6_HOPLIMIT=100 100 100 IPV6_MULTICAST_HOPS=5 100 5 IPV6_UNICAST_HOPS=50 50 5 IPV6_HOPLIMIT=3 3 3 The question is, what should be returned for a getsockopt() on IPV6_HOPLIMIT when the unicast and multicast hop limits are different? Take the default case for instance. What is the correct value to return on the getsockopt() call, 255 or 1? And what should be returned after setting IPV6_HOPLIMIT to 100 and following it with setting IPV6_MULTICAST_HOPS to 5, 100 or 5? All of this would be *much* simpler if the advanced API only allowed IPV6_HOPLIMIT to be specified as ancillary data and required the use of IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and getsockopt() calls. Unfortunately, that isn't the case as 2292 allows IPV6_HOPLIMIT to be specified as a sticky option. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 13 12:02:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ2gWi016197 for ; Wed, 13 Jun 2001 12:02:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) id f5DJ2gAA016196 for ipng-dist; Wed, 13 Jun 2001 12:02:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta11+Sun/8.12.0.Beta11) with ESMTP id f5DJ2bWi016189 for ; Wed, 13 Jun 2001 12:02:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08832 for ; Wed, 13 Jun 2001 12:02:44 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11315 for ; Wed, 13 Jun 2001 13:02:43 -0600 (MDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.11.2/8.11.2) with ESMTP id f5DJ2fG18932; Wed, 13 Jun 2001 12:02:41 -0700 (PDT) Message-Id: <200106131902.f5DJ2fG18932@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 3122 on Extensions to IPv6 Neighbor Discovery Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 13 Jun 2001 12:02:41 -0700 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3122 Title: Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification Author(s): A. Conta Status: Standards Track Date: June 2001 Mailbox: aconta@txc.com Pages: 21 Characters: 40416 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ion-ipv6-ind-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3122.txt This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to determine and advertise an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. The Inverse Neighbor Discovery (IND) was originally developed for Frame Relay networks, but may also apply to other networks with similar behavior. This document is a product of the IPng Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <010613115954.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3122 --OtherAccess Content-Type: Message/External-body; name="rfc3122.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <010613115954.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 07:44:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEi342020383 for ; Fri, 15 Jun 2001 07:44:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FEi3cn020382 for ipng-dist; Fri, 15 Jun 2001 07:44:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEhx42020375 for ; Fri, 15 Jun 2001 07:43:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01521 for ; Fri, 15 Jun 2001 07:44:06 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07063 for ; Fri, 15 Jun 2001 08:44:04 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5FEi3i27246 for ; Fri, 15 Jun 2001 16:44:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA28101 for ; Fri, 15 Jun 2001 16:44:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5FEi2O31457 for ; Fri, 15 Jun 2001 16:44:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106151444.f5FEi2O31457@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: IPv6 over UDP/IPv4 Date: Fri, 15 Jun 2001 16:44:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We know that IPv6 over UDP/IPv4 is very useful for some users. This is very easy to do too (see the PS) but an advantage to have a document which specifies it is we can get a standard port... Do you believe we should write an Internet Draft about it? Francis.Dupont@enst-bretagne.fr PS: on FreeBSD 4.3 with Netgraph a little variation of the /usr/share/examples/netgraph/udp.tunnel script does the job. With if_tun (for systems without a netgraph-like facility) this takes one page of trivial code... or nothing if the user mode PPP has both UDP and IPv6 supports. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 07:46:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEkV42020400 for ; Fri, 15 Jun 2001 07:46:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FEkUDl020399 for ipng-dist; Fri, 15 Jun 2001 07:46:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEkR42020392 for ; Fri, 15 Jun 2001 07:46:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11205 for ; Fri, 15 Jun 2001 07:46:34 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03901 for ; Fri, 15 Jun 2001 08:47:15 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5FEkND02990 for ; Fri, 15 Jun 2001 21:46:23 +0700 (ICT) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> References: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 21:46:23 +0700 Message-ID: <2988.992616383@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There doesn't seem to be anything happening one way or the other, with regard to picking a prefix for this purpose. So, I am going to make a specific proposal, and then let it be shot down if it isn't liked ... otherwise at least there will be something that can be used. Please, if you are going to object to this, give reasons (that should be obvious) and suggest an alternative. The suggestion is FE::/9 That uses the rest of the FE:: space after the link & site locals have their share. It is big enough that it is possible to make examples of TLA looking things, far enough out of the way of any real likely address allocation that the future world should never need to make exceptions to work around it, and easily recognisable as a special address, just like the various local formats, and multicast. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 07:54:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEsU42020466 for ; Fri, 15 Jun 2001 07:54:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FEsUL4020465 for ipng-dist; Fri, 15 Jun 2001 07:54:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEsQ42020455 for ; Fri, 15 Jun 2001 07:54:26 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13737 for ; Fri, 15 Jun 2001 07:54:33 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22877 for ; Fri, 15 Jun 2001 07:54:31 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5FEsOD03190 for ; Fri, 15 Jun 2001 21:54:24 +0700 (ICT) From: Robert Elz cc: ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <2988.992616383@brandenburg.cs.mu.OZ.AU> References: <2988.992616383@brandenburg.cs.mu.OZ.AU> <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <2619.989410096@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 15 Jun 2001 21:54:24 +0700 Message-ID: <3188.992616864@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 15 Jun 2001 21:46:23 +0700 From: Robert Elz Message-ID: <2988.992616383@brandenburg.cs.mu.OZ.AU> | The suggestion is FE::/9 Ugh - I corrected Bill Manning for making that mistake a week or two ago, and then I go and do it!! I meant, of course, to suggest using FE00::/9 ... kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 07:54:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEsR42020463 for ; Fri, 15 Jun 2001 07:54:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FEsRvH020459 for ipng-dist; Fri, 15 Jun 2001 07:54:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FEsN42020448 for ; Fri, 15 Jun 2001 07:54:23 -0700 (PDT) Received: from hogwart.Central.Sun.COM (hogwart.Central.Sun.COM [129.153.128.110]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10394; Fri, 15 Jun 2001 08:54:30 -0600 (MDT) Received: (from davemq@localhost) by hogwart.Central.Sun.COM (8.11.4+Sun/8.11.4) id f5FEsTU17892; Fri, 15 Jun 2001 09:54:29 -0500 (CDT) X-Authentication-Warning: hogwart.Central.Sun.COM: davemq set sender to Dave.Marquardt@Sun.COM using -f To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: wrt: draft-blanchet-ipngwg-testadd-00.txt References: <5.1.0.14.1.20010607084023.04a7e3c8@mail.viagenie.qc.ca> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <5.1.0.14.0.20010606111548.03c015d0@jurassic> <2619.989410096@brandenburg.cs.mu.OZ.AU> <2988.992616383@brandenburg.cs.mu.OZ.AU> From: Dave Marquardt Date: 15 Jun 2001 09:54:28 -0500 In-Reply-To: <2988.992616383@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 9 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "kre" == Robert Elz writes: kre> The suggestion is FE::/9 Don't you mean FE00::/9? FE::/9 is 00FE::/9, isn't it? -- Dave Marquardt Sun Microsystems, Inc. Austin, TX +1 512 401-1077 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 10:11:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FHB242020755 for ; Fri, 15 Jun 2001 10:11:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FHB1E4020754 for ipng-dist; Fri, 15 Jun 2001 10:11:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FHAv42020747 for ; Fri, 15 Jun 2001 10:10:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12765 for ; Fri, 15 Jun 2001 10:11:05 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA03354 for ; Fri, 15 Jun 2001 10:11:05 -0700 (PDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Jun 2001 09:14:00 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 15 Jun 2001 09:13:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 15 Jun 2001 09:13:53 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 15 Jun 2001 09:12:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 over UDP/IPv4 Date: Fri, 15 Jun 2001 09:12:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 over UDP/IPv4 Thread-Index: AcD1qb5IfdBFrzN0T6K3CA1rt+A8ogACTalw From: "Christian Huitema" To: "Francis Dupont" , X-OriginalArrivalTime: 15 Jun 2001 16:12:32.0492 (UTC) FILETIME=[FB922AC0:01C0F5B5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5FHAw42020748 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The UDP tunneling scenario aims at solving the NAT crossing problem. This is fine, but we need more than just a pot number and a payload format to make this work. Since the origin of the tunnel is located behind a NAT, and possibly many, you cannot predict the port number and the IP address that it will use. Also, it is fair to assume that the tunnel will probably not be offered by the local ISP -- if this ISP wished to provide IPv6 service, it could just enable native IPv6, or possibly native tunneling. I think we must meet the following requirements: 1) There is no way to "pre-configure" the connection. The association between a given "user prefix" and a pair of natted address and port must be discovered in real-time. 2) There must be a way to verify the identity of the party requesting the tunnel, to mitigate the risk of traffic highjacking, and possibly to ensure that only authorized parties are using the service. 3) There must be some way to verify the origin of the traffic, in order to avoid denial of service attacks. 4) There must be a way to "qualify" the tunnel, and check that traffic is indeed flowing in both directions -- NAT configurations are prone to bizarre cases of failure. We should also note that IPv6 over UDP should be designed to work with all NATs, including those that use "destination specific" port mappings. The design, and the port discovery, should be focused on bilateral tunnels. -- Christian Huitema > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Friday, June 15, 2001 7:44 AM > To: ipng@sunroof.eng.sun.com > Subject: IPv6 over UDP/IPv4 > > We know that IPv6 over UDP/IPv4 is very useful for some users. > This is very easy to do too (see the PS) but an advantage to > have a document which specifies it is we can get a standard port... > Do you believe we should write an Internet Draft about it? > > Francis.Dupont@enst-bretagne.fr > > PS: on FreeBSD 4.3 with Netgraph a little variation of > the /usr/share/examples/netgraph/udp.tunnel script does the job. > With if_tun (for systems without a netgraph-like facility) this takes > one page of trivial code... or nothing if the user mode PPP has both > UDP and IPv6 supports. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 10:28:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FHSx42020855 for ; Fri, 15 Jun 2001 10:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FHSxrC020854 for ipng-dist; Fri, 15 Jun 2001 10:28:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FHSt42020847 for ; Fri, 15 Jun 2001 10:28:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26956 for ; Fri, 15 Jun 2001 10:29:04 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08572 for ; Fri, 15 Jun 2001 11:29:00 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5FHScD13754; Sat, 16 Jun 2001 00:28:39 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: "Francis Dupont" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 over UDP/IPv4 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 16 Jun 2001 00:28:38 +0700 Message-ID: <13752.992626118@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 15 Jun 2001 09:12:32 -0700 From: "Christian Huitema" Message-ID: | I think we must meet the following requirements: If all that is to be done, then it would probably be easier to just use TCP. That doesn't, of itself, satisfy all the requirements, but it makes it a lot easier to handle them (eg: it pretty much handles the two way data problem, and it allows some kind of authentication that doesn't have to be repeated for every packet). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 10:36:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FHaK42020882 for ; Fri, 15 Jun 2001 10:36:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FHaKbC020880 for ipng-dist; Fri, 15 Jun 2001 10:36:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FHaG42020873 for ; Fri, 15 Jun 2001 10:36:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27341 for ; Fri, 15 Jun 2001 10:36:25 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15322 for ; Fri, 15 Jun 2001 10:36:23 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5FHaKi50763; Fri, 15 Jun 2001 19:36:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA29821; Fri, 15 Jun 2001 19:36:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5FHaJO32012; Fri, 15 Jun 2001 19:36:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106151736.f5FHaJO32012@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Huitema" cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 over UDP/IPv4 In-reply-to: Your message of Fri, 15 Jun 2001 09:12:32 PDT. Date: Fri, 15 Jun 2001 19:36:19 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The UDP tunneling scenario aims at solving the NAT crossing problem. => I'd like to say IPv6 over UDP is useful in other cases but I am afraid that you are right: this is useful when there is a NAT or a firewall or both. This is fine, but we need more than just a port number and a payload format to make this work. => this covers some cases so this is perhaps not enough but still useful (port number: to be allocated by IANA, payload format: one IPv6 packet == one UDP packet). Since the origin of the tunnel is located behind a NAT, and possibly many, you cannot predict the port number and the IP address that it will use. Also, it is fair to assume that the tunnel will probably not be offered by the local ISP -- if this ISP wished to provide IPv6 service, it could just enable native IPv6, or possibly native tunneling. => there are two common cases where we aren't hurt by this issue: - there is only one NAT and it is locally managed - the ISP filters out "unknown" protocols (including 41) I think we must meet the following requirements: 1) There is no way to "pre-configure" the connection. The association between a given "user prefix" and a pair of natted address and port must be discovered in real-time. => a known port is still useful if NATs don't nat both source and destination. 2) There must be a way to verify the identity of the party requesting the tunnel, to mitigate the risk of traffic highjacking, and possibly to ensure that only authorized parties are using the service. 3) There must be some way to verify the origin of the traffic, in order to avoid denial of service attacks. => 2 and 3 have the same solution: some kind of IPsec... An option should be something like [IPv4][UDP][ESP][IPv6]. I believe there are such things in the IPsec mailing list for NAT tranversal. 4) There must be a way to "qualify" the tunnel, and check that traffic is indeed flowing in both directions -- NAT configurations are prone to bizarre cases of failure. => ah! IPv6 has already the right tool: NUD! We should also note that IPv6 over UDP should be designed to work with all NATs, including those that use "destination specific" port mappings. => I can't see the exact implication of this. The design, and the port discovery, should be focused on bilateral tunnels. Thanks Francis.Dupont@enst-bretagne.fr PS (1): the idea is to send a magic packet to the destination at the known port. If only the source is natted then the peer address and port will be available in the encapsulated stuff. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 15 11:16:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FIG742021162 for ; Fri, 15 Jun 2001 11:16:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5FIG7UC021161 for ipng-dist; Fri, 15 Jun 2001 11:16:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5FIG342021154 for ; Fri, 15 Jun 2001 11:16:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15301 for ; Fri, 15 Jun 2001 11:16:10 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA04732 for ; Fri, 15 Jun 2001 11:16:10 -0700 (PDT) Received: from 157.54.1.52 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 15 Jun 2001 10:46:57 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 15 Jun 2001 10:49:06 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 15 Jun 2001 10:48:48 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 15 Jun 2001 10:47:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: IPv6 over UDP/IPv4 Date: Fri, 15 Jun 2001 10:47:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 over UDP/IPv4 Thread-Index: AcD1wHa2YMRNna6YRoKVsvvGXx9OZwAAQkIQ From: "Christian Huitema" To: "Robert Elz" Cc: "Francis Dupont" , X-OriginalArrivalTime: 15 Jun 2001 17:47:24.0820 (UTC) FILETIME=[3C767D40:01C0F5C3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5FIG442021155 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Robert Elz [mailto:kre@munnari.OZ.AU] > From: "Christian Huitema" > > | I think we must meet the following requirements: > > If all that is to be done, then it would probably be easier to > just use TCP. That doesn't, of itself, satisfy all the requirements, > but it makes it a lot easier to handle them (eg: it pretty much handles > the two way data problem, and it allows some kind of authentication that > doesn't have to be repeated for every packet). In fact, if you really want to maximize the chances of going through "hostile territory", you probably want to use IPv6 > HTTP > TLS > TCP. And yes, I do mean "https"; using a different port would allow the network police to see you and catch you. This would get you through firewalls as well as NAT. OTOH, shipping this kind of solution will also get you "interesting" comments from network managers. Also, you may have a small problem with the packets' latencies. Seriously, I believe that most of the requirements can be met pretty easily. You need to design a protocol that starts with a formal handshake, probably similar in nature to the PPP control protocol: provide credentials in a format that is compatible with a Radius back-end. You want the handshake to be at least a three ways handshake, so has to ensure that the connection actually works. You may want to negotiate something like ESP or TLS. As Franci points out, once the connection is set and the identities have been validated, then we probably are home free -- use autoconfig if needed, use NUD, etc. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 17 05:31:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5HCVUdP023040 for ; Sun, 17 Jun 2001 05:31:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5HCVUpc023039 for ipng-dist; Sun, 17 Jun 2001 05:31:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5HCVQdP023032 for ; Sun, 17 Jun 2001 05:31:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23848 for ; Sun, 17 Jun 2001 05:31:33 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23984 for ; Sun, 17 Jun 2001 06:31:31 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5HCSoi36172; Sun, 17 Jun 2001 14:28:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA07540; Sun, 17 Jun 2001 14:28:50 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5HCSmO38782; Sun, 17 Jun 2001 14:28:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106171228.f5HCSmO38782@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Huitema" cc: "Robert Elz" , ipng@sunroof.eng.sun.com Subject: Re: IPv6 over UDP/IPv4 In-reply-to: Your message of Fri, 15 Jun 2001 10:47:24 PDT. Date: Sun, 17 Jun 2001 14:28:48 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Seriously, I believe that most of the requirements can be met pretty easily. You need to design a protocol that starts with a formal handshake, probably similar in nature to the PPP control protocol: => are you suggesting to use the UDP optional encapsulation of the FreeBSD/OpenBSD user-mode PPP tool (aka http://www.Awfulhak.org/ppp.html)? It has no IPv6 support but this is easy to fix (some patches are already available for previous versions). This can do the job for BSD boxes (so we had only to do this for Linux (port) and Windowses (someone from Microsoft :-)). provide credentials in a format that is compatible with a Radius back-end. You want the handshake to be at least a three ways handshake, so has to ensure that the connection actually works. You may want to negotiate something like ESP or TLS. => I am strongly in favor of ESP because TLS protected connections are too easily killed by junk RSTs (not a real problem for the web but here we'd like to get long term connections). As Francis points out, once the connection is set and the identities have been validated, then we probably are home free -- use autoconfig if needed, use NUD, etc. => IPv6 has a superior design, just be convinced outselves (:-)! Thanks Francis.Dupont@enst-bretagne.fr PS: BSD user PPP uses synchronous serial line encapsulation for UDP (ie. the IP packet is put directly into an UDP packet) and asynchronous one for TCP (ie. TCP provides an octet stream). This seems reasonnable and simple (maximal reuse of the code for serial lines). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 17 12:40:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5HJeodP023251 for ; Sun, 17 Jun 2001 12:40:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5HJeo5d023250 for ipng-dist; Sun, 17 Jun 2001 12:40:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5HJekdP023243 for ; Sun, 17 Jun 2001 12:40:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03880 for ; Sun, 17 Jun 2001 12:40:49 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08323 for ; Sun, 17 Jun 2001 12:40:48 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5HJcxa04061; Sun, 17 Jun 2001 22:38:59 +0300 Date: Sun, 17 Jun 2001 22:38:58 +0300 (EEST) From: Pekka Savola To: Robert Elz cc: Christian Huitema , Francis Dupont , Subject: Re: IPv6 over UDP/IPv4 In-Reply-To: <13752.992626118@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 16 Jun 2001, Robert Elz wrote: > Date: Fri, 15 Jun 2001 09:12:32 -0700 > From: "Christian Huitema" > Message-ID: > > | I think we must meet the following requirements: > > If all that is to be done, then it would probably be easier to > just use TCP. That doesn't, of itself, satisfy all the requirements, > but it makes it a lot easier to handle them (eg: it pretty much handles > the two way data problem, and it allows some kind of authentication that > doesn't have to be repeated for every packet). Tunneling TCP over TCP can get you into "interesting" situations if the packet loss is significant due to timers etc. activating on both layers. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 18 05:38:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5ICcidP024125 for ; Mon, 18 Jun 2001 05:38:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5ICciQa024124 for ipng-dist; Mon, 18 Jun 2001 05:38:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5ICccdP024117 for ; Mon, 18 Jun 2001 05:38:39 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA03913; Mon, 18 Jun 2001 14:38:37 +0200 (MET DST) Date: Mon, 18 Jun 2001 14:38:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 over UDP/IPv4 To: Francis Dupont Cc: Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200106151736.f5FHaJO32012@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS (1): the idea is to send a magic packet to the destination > at the known port. If only the source is natted then the peer > address and port will be available in the encapsulated stuff. I've observed that, even if there is traffic every few seconds, the NAT box I have will change the UDP source port occasionally for UDP traffic. Thus it isn't sufficient to send the magic packet once. Erik PS. The above is based on operational experience for IPv4 over UDP/IPv4 to enable IPsec tunnels on top of that. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 18 06:22:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IDMidP024180 for ; Mon, 18 Jun 2001 06:22:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5IDMiQL024179 for ipng-dist; Mon, 18 Jun 2001 06:22:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IDMedP024172 for ; Mon, 18 Jun 2001 06:22:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12080; Mon, 18 Jun 2001 06:22:47 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07311; Mon, 18 Jun 2001 07:22:45 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5IDMii21151; Mon, 18 Jun 2001 15:22:44 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA05535; Mon, 18 Jun 2001 15:22:44 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5IDMhO56819; Mon, 18 Jun 2001 15:22:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106181322.f5IDMhO56819@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: IPv6 over UDP/IPv4 In-reply-to: Your message of Mon, 18 Jun 2001 14:38:32 +0200. Date: Mon, 18 Jun 2001 15:22:43 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS (1): the idea is to send a magic packet to the destination > at the known port. If only the source is natted then the peer > address and port will be available in the encapsulated stuff. I've observed that, even if there is traffic every few seconds, the NAT box I have will change the UDP source port occasionally for UDP traffic. => argh! This mandates a IPv6 over TCP/IPv4 too because the NAT cannot do this for a TCP connection... PS. The above is based on operational experience for IPv4 over UDP/IPv4 to enable IPsec tunnels on top of that. => and can IPsec work with such a (broken) NAT? Francis.Dupont@enst-bretagne.fr PS: something like the BSD user-PPP is more and more attractive! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 18 06:38:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IDcNdP024217 for ; Mon, 18 Jun 2001 06:38:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5IDcNNX024216 for ipng-dist; Mon, 18 Jun 2001 06:38:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.france (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5IDcHdP024209 for ; Mon, 18 Jun 2001 06:38:18 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.france (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA09038; Mon, 18 Jun 2001 15:38:18 +0200 (MET DST) Date: Mon, 18 Jun 2001 15:38:12 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPv6 over UDP/IPv4 To: Francis Dupont Cc: Erik Nordmark , Christian Huitema , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200106181322.f5IDMhO56819@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS. The above is based on operational experience for IPv4 over UDP/IPv4 > to enable IPsec tunnels on top of that. > > => and can IPsec work with such a (broken) NAT? IPsec doesn't run directly over it. There are two layers of tunneling: 1. Create fixed public IP address for the machine behind the NAT box by tunneling IPv4 over UDP/IPv4. 2. Just run regular IPsec tunnel mode on top of the above. Apart from the tunnel overhead (IPv4 UDP IPv4 IPv4 ESP IPv4 ...) it appears to be working fine. But I've only used this heavily for a few weeks so I don't yet understand how often there has to be packets from behind the NAT to make sure that tunnel #1 gets the updated UDP port numbers. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 19 06:33:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JDXKdP025521 for ; Tue, 19 Jun 2001 06:33:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5JDXK0B025520 for ipng-dist; Tue, 19 Jun 2001 06:33:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5JDXGdP025513 for ; Tue, 19 Jun 2001 06:33:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02148 for ; Tue, 19 Jun 2001 06:33:24 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20972 for ; Tue, 19 Jun 2001 07:34:08 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA71156 for ; Tue, 19 Jun 2001 09:26:24 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5JDXJu59206 for ; Tue, 19 Jun 2001 09:33:19 -0400 Subject: Re: getsockopt() for IPV6_HOPLIMIT To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Tue, 19 Jun 2001 09:32:31 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/19/2001 09:33:19 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I actually went back and read the existing RFC2292 - probably something I should have done originally - and I think I have a handle on this. Based on the current RFC and the -02 draft my interpretation is that: - IPV6_HOPLIMIT should not be allowed on a getsockopt() or setsockopt() call, but instead IPV6_RECVHOPLIMIT should be used. IPV6_HOPLIMIT can still be sent/received as ancillary ancillary data. - IPV6_RECVHOPLIMIT should be used on setsockopt() to request that the IPV6_HOPLIMIT be returned as ancillary data. Does this sound correct, or am I missing something? Also, I see that the current 2292bis draft has expired. Are there any plans to produce an updated version? From previous postings back in November regarding the -02 draft there appear to be some incompatible changes which are being proposed, such as changing IPV6_PATHMTU to return an ip6_mtuinfo structure instead of an int, not to mention the changes I listed above (plus several others). I'd like to have our implementation track to the ID as it progresses, but if there aren't any new drafts coming then we should be implementing to the RFC. Roy On Wednesday, 06/13/2001 at 12:24 EDT, rbrabson@us.ibm.com wrote: > I'm struggling to get my hands around the interaction between > IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, and IPV6_MULTICAST_HOPS. It > seems pretty straight forward if IPV6_HOPLIMIT is specified as > ancilliary data - IPV6_HOPLIMIT overrides the current hoplimit > for that packet only. But what about when IPV6_HOPLIMIT is > set using setsockopt()? > > Using setsockopt() calls, I think the behavior would be as follows: > > Unicast Hop Limit Multicast Hop Limit > ----------------- ------------------- > default 255 1 > IPV6_HOPLIMIT=100 100 100 > IPV6_MULTICAST_HOPS=5 100 5 > IPV6_UNICAST_HOPS=50 50 5 > IPV6_HOPLIMIT=3 3 3 > > The question is, what should be returned for a getsockopt() on > IPV6_HOPLIMIT when the unicast and multicast hop limits are different? > Take the default case for instance. What is the correct value to return > on the getsockopt() call, 255 or 1? And what should be returned after > setting IPV6_HOPLIMIT to 100 and following it with setting > IPV6_MULTICAST_HOPS to 5, 100 or 5? > > All of this would be *much* simpler if the advanced API only allowed > IPV6_HOPLIMIT to be specified as ancillary data and required the use of > IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and > getsockopt() calls. Unfortunately, that isn't the case as 2292 allows > IPV6_HOPLIMIT to be specified as a sticky option. > > Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 19 18:14:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K1EMdP026148 for ; Tue, 19 Jun 2001 18:14:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5K1EMZS026147 for ipng-dist; Tue, 19 Jun 2001 18:14:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K1EIdP026140 for ; Tue, 19 Jun 2001 18:14:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03289 for ; Tue, 19 Jun 2001 18:14:27 -0700 (PDT) Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA03758 for ; Tue, 19 Jun 2001 19:15:12 -0600 (MDT) Received: (qmail 16362 invoked from network); 20 Jun 2001 05:33:39 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.74.92) by gate-int.alliedtelesyn.co.nz with SMTP; 20 Jun 2001 05:33:39 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 20 Jun 01 13:13:48 +1200 Received: from SpoolDir by ASLAN (Mercury 1.47); 20 Jun 01 13:13:34 +1200 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: ipng@sunroof.eng.sun.com Date: Wed, 20 Jun 2001 13:13:26 +1200 (NZT) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: ipv6 performance measurement Reply-to: mtl23@student.canterbury.ac.nz, sean.lin@alliedtelesyn.co.nz Message-ID: <3B30A113.22753.196C746F@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know if there is an ipv6 version for ttcp, netperf or netpipe? regards, Sean ------------------------------------------------------------- Sean Lin 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 19 23:18:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K6IPdP026328 for ; Tue, 19 Jun 2001 23:18:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5K6IPq2026327 for ipng-dist; Tue, 19 Jun 2001 23:18:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5K6IMdP026320 for ; Tue, 19 Jun 2001 23:18:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02715 for ; Tue, 19 Jun 2001 23:18:29 -0700 (PDT) Received: from sea-av1.zama.net (smtp1.zama.net [203.142.132.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26494 for ; Wed, 20 Jun 2001 00:18:27 -0600 (MDT) Received: from sea-av1.zama.net (localhost [127.0.0.1]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id XAA27823 for ; Tue, 19 Jun 2001 23:18:27 -0700 (PDT) Received: from postoff1.zama.net (sea-postoff1.zama.net [172.16.100.20]) by sea-av1.zama.net (8.9.3+Sun/8.9.3) with ESMTP id XAA27813 for ; Tue, 19 Jun 2001 23:18:27 -0700 (PDT) Received: from zama.net ([127.0.0.1]) by postoff1.zama.net (Netscape Messaging Server 4.15) with ESMTP id GF7TIR00.82C; Tue, 19 Jun 2001 23:18:27 -0700 From: "Brad McNamara" To: mtl23@student.canterbury.ac.nz, sean.lin@alliedtelesyn.co.nz Cc: ipng@sunroof.eng.sun.com Message-ID: <56f442e9.42e956f4@zama.net> Date: Tue, 19 Jun 2001 23:18:27 -0700 X-Mailer: Netscape Webmail MIME-Version: 1.0 Content-Language: en Subject: Re: ipv6 performance measurement X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There's a patch by the KAME group for NetPerf located at: ftp://ftp.kame.net/pub/kame/misc/ Brad McNamara ZAMA Networks, Inc. ----- Original Message ----- From: "Sean Lin" Date: Tuesday, June 19, 2001 6:13 pm Subject: ipv6 performance measurement > Does anyone know if there is an ipv6 version for ttcp, netperf or > netpipe? > regards, > Sean > > ------------------------------------------------------------- > Sean Lin 27 Nazareth Avenue > Software Engineer PO Box 8011 > Allied Telesyn Research Christchurch > phone +64 3 339 3000 New Zealand > fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz > web: http://www.alliedtelesyn.co.nz/ > ------------------------------------------------------------- > > ------------------------------------------------------------------- > - > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------- > - > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 20 04:54:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KBsZdP026616 for ; Wed, 20 Jun 2001 04:54:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5KBsYd6026615 for ipng-dist; Wed, 20 Jun 2001 04:54:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KBsVdP026608 for ; Wed, 20 Jun 2001 04:54:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28331 for ; Wed, 20 Jun 2001 04:54:37 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14570 for ; Wed, 20 Jun 2001 05:54:35 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5KBsTi13611; Wed, 20 Jun 2001 13:54:30 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA19937; Wed, 20 Jun 2001 13:54:29 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5KBsTO64265; Wed, 20 Jun 2001 13:54:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106201154.f5KBsTO64265@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Roy Brabson" cc: ipng@sunroof.eng.sun.com Subject: Re: getsockopt() for IPV6_HOPLIMIT In-reply-to: Your message of Tue, 19 Jun 2001 09:32:31 EDT. Date: Wed, 20 Jun 2001 13:54:28 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I actually went back and read the existing RFC2292 - probably something I should have done originally - and I think I have a handle on this. Based on the current RFC and the -02 draft my interpretation is that: - IPV6_HOPLIMIT should not be allowed on a getsockopt() or setsockopt() call, but instead IPV6_RECVHOPLIMIT should be used. IPV6_HOPLIMIT can still be sent/received as ancillary data. - IPV6_RECVHOPLIMIT should be used on setsockopt() to request that the IPV6_HOPLIMIT be returned as ancillary data. Does this sound correct, or am I missing something? => no, IPV6_HOPLIMIT is the hop limit to use and IPV6_RECVHOPLIMIT is a flag saying that the received hop limit must be provided to the user. IPV6_HOPLIMIT can be sticky or ancillary, IPV6_RECVHOPLIMIT must be sticky. Also, I see that the current 2292bis draft has expired. Are there any plans to produce an updated version? From previous postings back in November regarding the -02 draft there appear to be some incompatible changes which are being proposed => RFC2292 has many bugs (for instance IPV6_RECVPKTINFO is missing and IPV6_PKTINFO is badly overloaded). I'd like to have our implementation track to the ID as it progresses, but if there aren't any new drafts coming then we should be implementing to the RFC. => you should not because of the bugs... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 20 07:07:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KE7ZdP026737 for ; Wed, 20 Jun 2001 07:07:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5KE7Y9N026736 for ipng-dist; Wed, 20 Jun 2001 07:07:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5KE7VdP026729 for ; Wed, 20 Jun 2001 07:07:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25914 for ; Wed, 20 Jun 2001 07:07:37 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA14635 for ; Wed, 20 Jun 2001 07:07:24 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA78180; Wed, 20 Jun 2001 10:00:26 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5KE7Mr36306; Wed, 20 Jun 2001 10:07:22 -0400 Subject: Re: getsockopt() for IPV6_HOPLIMIT To: Francis Dupont Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Wed, 20 Jun 2001 10:06:33 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/20/2001 10:07:22 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, 06/20/2001 at 01:54 ZE2, Francis Dupont wrote: > In your previous mail you wrote: > > I actually went back and read the existing RFC2292 - probably > something I should have done originally - and I think I have > a handle on this. Based on the current RFC and the -02 draft > my interpretation is that: > > - IPV6_HOPLIMIT should not be allowed on a getsockopt() or > setsockopt() call, but instead IPV6_RECVHOPLIMIT should be > used. IPV6_HOPLIMIT can still be sent/received as ancillary data. > - IPV6_RECVHOPLIMIT should be used on setsockopt() to request > that the IPV6_HOPLIMIT be returned as ancillary data. > > Does this sound correct, or am I missing something? > > => no, IPV6_HOPLIMIT is the hop limit to use and IPV6_RECVHOPLIMIT > is a flag saying that the received hop limit must be provided to the user. > IPV6_HOPLIMIT can be sticky or ancillary, IPV6_RECVHOPLIMIT must be > sticky. I'm still unsure what to return on getsockopt() for IPV6_HOPLIMIT when the unicast and multicast hop limits are different. This can happen in two cases. First, prior to any setsockopt() for IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, or IPV6_MULTICAST_HOPS. Second, a setsockopt() for IPV6_HOPLIMIT followed by a setsockopt() for either IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS. I can see several approaches to handling this: - Fail a getsockopt() for IPV6_HOPLIMIT if the unicast hoplimit and multicast hoplimit are different. This will require that the caller issue a setsockopt() for IPV6_HOPLIMIT before they can issue a getsockopt() (that is, there is no default value for IPV6_HOPLIMIT), and will also fail a getsockopt() for IPV6_HOPLIMIT if a subsequent setsockopt() for IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS is issued. - Always return the unicast hoplimit for a getsockopt() for IPV6_HOPLIMIT. This is a little strange when the unicast and multicast hoplimits are different, but at least it is predictable and provides a default value for IPV6_HOPLIMIT. - Some other approach which I haven't thought of. Hopefully an updated version of the draft (assuming there will be one) will spell out what the proper behavior is. I still think all of this is unnecessary, anyway. Applications can use IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for getsockopt() and setsockopt() and IPV6_HOPLIMIT for ancillary data and receive consistent and predictable results. Introducing IPV6_HOPLIMIT on getsockopt() and setsockopt() seems to provide little to no value and just seems to muddy the water. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 21 05:11:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LCBAdP027808 for ; Thu, 21 Jun 2001 05:11:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LCB9kY027807 for ipng-dist; Thu, 21 Jun 2001 05:11:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LCB6dP027800 for ; Thu, 21 Jun 2001 05:11:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24506 for ; Thu, 21 Jun 2001 05:11:13 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA27518 for ; Thu, 21 Jun 2001 05:11:11 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5LCB2i13716; Thu, 21 Jun 2001 14:11:02 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA02509; Thu, 21 Jun 2001 14:11:01 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5LCB0O68526; Thu, 21 Jun 2001 14:11:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106211211.f5LCB0O68526@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Roy Brabson" cc: ipng@sunroof.eng.sun.com Subject: Re: getsockopt() for IPV6_HOPLIMIT In-reply-to: Your message of Wed, 20 Jun 2001 10:06:33 EDT. Date: Thu, 21 Jun 2001 14:11:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm still unsure what to return on getsockopt() for IPV6_HOPLIMIT when the unicast and multicast hop limits are different. => there was already an old thread about this. If the socket is bound there is no ambiguity. I believe the conclusion was to return an error for unbound sockets (default hop limits are too different), this makes the choice between sticky parameters / parameters per sendmsg() call more sound (i.e. the source address is considered as a standard parameter). This can happen in two cases. First, prior to any setsockopt() for IPV6_HOPLIMIT, IPV6_UNICAST_HOPS, or IPV6_MULTICAST_HOPS. Second, a setsockopt() for IPV6_HOPLIMIT followed by a setsockopt() for either IPV6_UNICAST_HOPS or IPV6_MULTICAST_HOPS. => there is nothing about interaction between IPV6_HOPLIMIT and IPV6_XXXCAST_HOPS... I still think all of this is unnecessary, anyway. Applications can use IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for getsockopt() and setsockopt() and IPV6_HOPLIMIT for ancillary data and receive consistent and predictable results. => but the ancillary data coding style is considered as very painful to use in some cases so the options are defined for both the sticky and the ancillary styles. Introducing IPV6_HOPLIMIT on getsockopt() and setsockopt() seems to provide little to no value => the 6.3 section of last 2292bis I-D explicitely mentions sticky IPV6_HOPLIMIT... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 21 09:31:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LGVEdP027988 for ; Thu, 21 Jun 2001 09:31:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LGVEfp027987 for ipng-dist; Thu, 21 Jun 2001 09:31:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LGVAdP027980 for ; Thu, 21 Jun 2001 09:31:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19836 for ; Thu, 21 Jun 2001 09:31:17 -0700 (PDT) Received: from netmail.alcatel.com (netmail.alcatel.com [128.251.168.50]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29094 for ; Thu, 21 Jun 2001 10:32:06 -0600 (MDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA07060 for ; Thu, 21 Jun 2001 11:31:15 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f5LGVEp02478 for ; Thu, 21 Jun 2001 11:31:15 -0500 (CDT) Message-ID: <3B322151.636B9D1D@usa.alcatel.com> Date: Thu, 21 Jun 2001 11:31:13 -0500 From: Sridhar Gurivireddy Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Usage of Ip-redirect Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can I use ICMP-redirect message of Ipv6 to inform an arbitrary host in a netwok about an arbitrary next-hop for a particular desitnation? ICMP redirect is used by a router to inform a host about the better first hop? My Question is " Are there any restictions on where this first hop can be?" Thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 21 14:40:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LLefdP028325 for ; Thu, 21 Jun 2001 14:40:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LLefql028324 for ipng-dist; Thu, 21 Jun 2001 14:40:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LLebdP028317 for ; Thu, 21 Jun 2001 14:40:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28421 for ; Thu, 21 Jun 2001 14:40:46 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-068-077.vz.dsl.gtei.net [4.60.68.77]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA01485 for ; Thu, 21 Jun 2001 14:40:44 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 21 Jun 2001 14:40:40 -0700 Received: from eagleswings [4.60.71.107] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 332D5402647847A6B4DF99BB84009D39 for plus 1 more; Thu, 21 Jun 2001 14:40:40 -0700 Reply-To: From: "Tony Hain" To: "Sridhar Gurivireddy" , Subject: RE: Usage of Ip-redirect Date: Thu, 21 Jun 2001 14:40:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3B322151.636B9D1D@usa.alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-SLUIDL: 2172A415-9CEF43DD-A6269293-8C698414 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A redirect packet MUST NOT be forwarded through a router (hop limit is set to 255), and the new next hop MUST be an address on the link with the recipient (so ND is not required). Other than being contained within the context of a link, there are no restrictions. -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Sridhar Gurivireddy Sent: Thursday, June 21, 2001 9:31 AM To: ipng@sunroof.eng.sun.com Subject: Usage of Ip-redirect Can I use ICMP-redirect message of Ipv6 to inform an arbitrary host in a netwok about an arbitrary next-hop for a particular desitnation? ICMP redirect is used by a router to inform a host about the better first hop? My Question is " Are there any restictions on where this first hop can be?" Thanks -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 21 15:42:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LMgidP028396 for ; Thu, 21 Jun 2001 15:42:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LMgixG028395 for ipng-dist; Thu, 21 Jun 2001 15:42:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LMggdP028388 for ; Thu, 21 Jun 2001 15:42:42 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f5LMfji18786 for ipng@sunroof.eng.sun.com; Thu, 21 Jun 2001 15:41:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LLqUdP028366 for ; Thu, 21 Jun 2001 14:52:30 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01280 for ; Thu, 21 Jun 2001 14:52:38 -0700 (PDT) Received: from gnat.inet.org (inet.org [63.108.254.91] (may be forged)) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27134 for ; Thu, 21 Jun 2001 14:52:38 -0700 (PDT) Received: from mosquito.extremenetworks.com (rja-laptop [10.30.34.139]) by gnat.inet.org (Postfix) with ESMTP id 558DB8266E for ; Thu, 21 Jun 2001 17:52:27 -0400 (EDT) Message-Id: <5.1.0.14.2.20010621174016.00a0d330@10.30.15.2> X-Sender: rja@nowhere (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 21 Jun 2001 17:48:38 -0400 To: ipng@sunroof.eng.sun.com From: Ran Atkinson Subject: IPv6 over GigE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The IS-IS WG has a draft out on how IP over GigE jumbograms should work. This is online at: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-00.txt As this does have implications for IPv6 over GigE jumbograms, folks over here in IPv6-land might want to look over that document and participate in the discussions over on the IS-IS mailing list. Because all IS-IS WG documents are published as Informational RFCs (because ISO is the standards-body for IS-IS), many folks treat Informational RFCs from the IS-IS WG as carrying equal weight as a standards-track document. While it might not precisely *be* a standards-tack document, this tends to be the reality of output from that particular WG. For reference, one issue is how big an Ethernet Jumbogram is. The IEEE position is that there is only one Ethernet MTU size. Widely available GigE products support a frame size of ~9K bytes. The IS-IS WG, with its folks on POS interfaces that have been designed for FDDI MTU (4470 bytes) for historical reasons, might end up picking 4470 as their spec for Ethernet Jumbogram MTU. There is also the matter of how the IP packet is encapsulated into Ethernet/ 802.3 for the case of an Ethernet jumbogram and several opinions there also. If none of this matters to folks, fine. If it does matter, the discussion is occurring over on the IS-IS list and the time to review and comment is now... Cheers, Ran rja@extremenetworks.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 21 15:44:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LMiUdP028413 for ; Thu, 21 Jun 2001 15:44:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5LMiUxT028412 for ipng-dist; Thu, 21 Jun 2001 15:44:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5LMiQdP028405 for ; Thu, 21 Jun 2001 15:44:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11115 for ; Thu, 21 Jun 2001 15:44:33 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00280 for ; Thu, 21 Jun 2001 16:44:31 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5LMiDr13708; Fri, 22 Jun 2001 01:44:13 +0300 Date: Fri, 22 Jun 2001 01:44:13 +0300 (EEST) From: Pekka Savola To: Tony Hain cc: Sridhar Gurivireddy , Subject: RE: Usage of Ip-redirect In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Jun 2001, Tony Hain wrote: > A redirect packet MUST NOT be forwarded through a router (hop limit is set > to 255), and the new next hop MUST be an address on the link with the > recipient (so ND is not required). Other than being contained within the > context of a link, there are no restrictions. To be exact in about the first issue, nowhere is it said (or I missed it) that Redirects MUST not (or even SHOULD not) be forwarded. However, when receiving/sending the packet, source MUST be link-local address and hop limit MUST be 255, among others. So it basically means the same -- but who has to/is allowed to control this is obeyed (routers vs. end-nodes) is different. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 07:30:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MEUEdP029202 for ; Fri, 22 Jun 2001 07:30:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MEUDer029201 for ipng-dist; Fri, 22 Jun 2001 07:30:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MEUAdP029192 for ; Fri, 22 Jun 2001 07:30:10 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15696 for ; Fri, 22 Jun 2001 07:30:17 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15667 for ; Fri, 22 Jun 2001 07:30:04 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id BB8EF19675A; Fri, 22 Jun 2001 11:29:57 -0300 (ART) Date: Fri, 22 Jun 2001 11:29:57 -0300 To: ipng@sunroof.eng.sun.com Subject: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010622112957.A16787@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5MEUAdP029193 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2553 bind semantics harms the way to AF independence Horacio J. Peña RFC 2553 enforces the IPv4 mapped on IPv6 model for bind(2). This has had some very useful short term results, but harms very badly the way to AF independence, a goal that in my opinion we should try to reach. Main premise This paper is based on the premise that it's better writing AF independent programs than IPv6 centric ones. The basis for this is that we don't believe IPv6 is the cure-everything protocol and that any time in the future (probably in the far future) there would be a new transition from IPv6 to some other protocol. And we should do our best so that when that happens those who have to make that transition work can do it as easily as possible. We're experiencing the IPv4 to IPv6 transition, and it's painful. There's too much work to do, and the porting of the applications is responsible for much of that pain. Yes, porting an application is not so hard. But when you have so many, there is a problem. How many times have we heard that the IPv6 adoption is so slow because there is no support on the clients? How easier would have been getting that support if no change to the applications had have to be done? I believe that the answer is ``lots easier''. Porting the applications to use the AF independent way will make future transitions very much easier. I believe that's desired. What does RFC 2553 says Note: I'm talking about ``RFC 2553'' but meaning ``RFC 2553 and successors'', so i'll quote rfc2553bis-03 draft, not the RFC. Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6. A subset of this API could probably be designed for operation on systems that support only IPv6. However, this is not addressed in this memo. (from ``2. Design Considerations'') I.e., RFC 2553 applies to dual stack hosts. Applications may use PF_INET6 sockets to open TCP connections to IPv4 nodes, or send UDP packets to IPv4 nodes, by simply encoding the destination's IPv4 address as an IPv4-mapped IPv6 address, and passing that address, within a sockaddr_in6 structure, in the connect() or sendto() call. When applications use PF_INET6 sockets to accept TCP connections from IPv4 nodes, or receive UDP packets from IPv4 nodes, the system returns the peer's address to the application in the accept(), recvfrom(), or getpeername() call using a sockaddr_in6 structure encoded this way. (from ``3.7 Compatibility with IPv4 Nodes'') 5.3 IPV6_V6ONLY option for AF_INET6 Sockets This socket option restricts AF_INET6 sockets to IPv6 communications only. As stated in section <3.7 Compatibility with IPv4 Nodes>, AF_INET6 sockets may be used for both IPv4 and IPv6 communications. Some applications may want to restrict their use of an AF_INET6 socket to IPv6 communications only. For these applications the IPV6_V6ONLY socket option is defined. When this option is turned on, the socket can be used to send and receive IPv6 packets only. This is an IPPROTO_IPV6 level option. This option takes an int value. This is a boolean option. By default this option is turned off. This implies that when binding an INET6 socket to a port (without specifying an address to bind to) it will hear the IPv4 requests too unless the IPV6_V6ONLY option is set. That is done using the IPv4-mapped IPv6 addresses. How to program a server Let me digress a bit now. I'll show how a server is programmed in IPv4 only programs, in IPv6 centric ones, and in the AF independent way, so the rest of this paper can be understood. IPv4 server int listenfd, connfd; struct sockaddr_in cliaddr, servaddr; socklen_t clilen; listenfd = socket(AF_INET, SOCK_STREAM, 0); if(listenfd < 0) die(); memset(&servaddr, 0, sizeof(servaddr)); servaddr.sin_family = AF_INET; servaddr.sin_addr.s_addr = htonl(INADDR_ANY); servaddr.sin_port = htons(1000); if(bind(listenfd, &servaddr, sizeof(servaddr)) != 0) die(); if(listen(listenfd, 10) != 0) die(); connfd = accept(listenfd, (struct sockaddr *) &cliaddr, &clilen); if(connfd < 0) die(); /* do something with connfd */ This does work only with IPv4 connections, if anyone tries to connect to that box at the tcp port 1000 by IPv6 it will not connect. IPv6 centric server int listenfd, connfd; struct sockaddr_in6 cliaddr, servaddr; socklen_t clilen; listenfd = socket(AF_INET6, SOCK_STREAM, 0); if(listenfd < 0) die(); memset(&servaddr, 0, sizeof(servaddr)); servaddr.sin6_family = AF_INET6; servaddr.sin6_addr = in6addr_any; servaddr.sin6_port = htons(1000); if(bind(listenfd, &servaddr, sizeof(servaddr)) != 0) die(); if(listen(listenfd, 10) != 0) die(); connfd = accept(listenfd, (struct sockaddr *) &cliaddr, &clilen); if(connfd < 0) die(); /* do something with connfd */ Almost no changes from the IPv4 only server. Accepts both IPv4 and IPv6 connections. But it is not going to work in OS with IPv6 support compiled out (it is not going to work even for IPv4) AF independent server int listenfds[MAX_AF], connfd; struct addrinfo hints, *res, *ressave; struct sockaddr_storage ss; socklen_t sslen; int n, i, m; fd_set fdset; memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_PASSIVE; hints.ai_family = AF_UNSPEC; hints.ai_socktype = SOCK_STREAM; if(getaddrinfo(NULL, "1000", &hints, &res) != 0) die(); ressave = res; for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) { listenfds[n] = socket(res->ai_family, res->ai_socktype, res->ai_protocol); if(listenfds[n] < 0) continue; /* libc supports protocols that kernel don't */ if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0) die(); if(listen(listenfds[n], 10) != 0) die(); n++; } freeaddrinfo(ressave); m = 0; FD_ZERO(&fdset); for(i = 0; i < n; i++) { FD_SET(listenfds[i], &fdset); m = MAX(listenfds[i]+1,m); } if(select(m, &fdset, NULL, NULL, NULL) < 0) die(); for(i = 0; i < n; i++) { if(FD_ISSET(listenfds[i], &fdset)) { sslen = sizeof(ss); connfd = accept(listenfds[i], (struct sockaddr*) &ss, &sslen); break; } } if(connfd < 0) die(); /* do something with connfd */ Lots harder... A comment But that's not all. Nor the IPv6 centric nor the AF independent way work as cleanly as I presented them. The IPv6 centric way dies on OS where the IPv6 support is not compiled, so when programming the IPv6 centric way you should check if the socket call fails and then fall back to work as a pure IPv4 server (ie, duplication of code) And about the AF independent way... I'll talk about the problems it has on the following sections of this paper. But, even if both ways worked so great as the previous sections would make you believe, while the AF independent way is harder to do, it's a once in the life change, while the IPv6 centric way would have to be modified if any time in the future you want to handle anything that cannot be mapped to IPv6. End of the digression. Let's go back to RFC 2553. RFC 2553 implementations We classify the RFC 2553 implementations by how they implement the bind semantics. The non compliant ones These systems consider IPv4 and IPv6 as different protocols, so they don't let the IPv4 mapping to IPv6 work. The AF independent way works great. The IPv6 centric way works only for IPv6 connections and the INET6 sockets never catch an IPv4 connection. OpenBSD, NetBSD (by default) and MSR stack for Windows are some of the non compliant implementations. The buggy ones Warning: I talk about ``buggyness'' just about the issue on topic, the systems I qualify as ``buggy'' are the best I've worked with. And I like the ``buggy'' stacks better than the ``correct'' ones where trying to work without depending on AF is really hard. Moderns IPv4 stacks consider INADDR_ANY as meaning ``every address'', and not ``default for not bound addresses'', so they don't allow binding to an specific address when the wildcard address is bound in the same port. That is to avoid letting applications ``steal'' connections from other ones. The same way it shouldn't be allowed to ``steal'' the IPv4 connections from the IPv6 wildcard. Allowing that should be considered a bug. That behaviour lets the IPv6 centric way work ok, and the AF independent way work ok too. But it has a bug. FreeBSD, NetBSD (optionally) and BSDI has that buggy behaviour. Probably most propietary implementations do too. Compliant, non-buggy, but unworkable Warning: I amn't saying that Linux has not bugs. I'm just talking about bind semantics in this paper. That's Linux. Linux complies with the RFC letting the IPv6 sockets catch IPv4 connections, has not the bug mentioned before, but it is impossible to work with in an AF independent fashion. When doing the socket/bind/listen loop, the IPv4 bind call will fail because there is an IPv6 socket bound to the IPv6 wildcard address, so you should ignore bind errors, or croak only if none of the bind calls worked, but that will be the same that ignoring bind errors if a new protocol that has no mapping to the others exists. Ignoring these errors is a Bad Thing. Conclusion: there's no good implementations of RFC 2553 If my classification is not exhaustive and there is a non-buggy, fully compliant implementation of the RFC 2553 bind semantics that doesn't cause problems to programs written in an AF independent way, I'd be very pleased to know them and learn how they have avoided all that problems. But I believe that the cause is that the RFC is not very good on that point and should have more work done on that. Until then I can just suggest several possible ways of solving this problem. Possible solutions Any of the following possible solutions is good enough for me, being my objective to be able to program portable, AF-independent programs without having to add special cases for IPv6 (nor any other protocol, I'm an application programmer, I shouldn't care about what is running the network), something I cannot do now because the Linux way of implementing bind. I believe IPv4 mapped addresses will be deprecated sooner or later because IPv4 itself will be deprecated. And I believe that maybe now is the time to start that deprecation, not by disallowing them right now, but by allowing the existence of systems where the IPv4 and IPv6 stacks are isolated (like OBSD and Windows) That's what I call for, but any of the other possible solutions will be enough for me. Deprecate IPv4 mapped addresses Maybe the time for IPv4 mapped addresses is over, maybe that was a good mechanism to get things to start rolling but it's time to grow up and left them. Itojun has mentioned in their ipv6-transition-abuse draft many other problems that the IPv4 mapped addresses have. But, there is too much work done in the IPv6 centric way, so maybe it isn't prudent to throw them all at once. Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option Then the IPv6 sockets would have to be explicitly allowed to accept IPv4 connections. So the programs that use the IPv6 centric way have to be modified a bit, but the buggy implementations and the unworkable one could be corrected without losing features. Just making IPV6_V6ONLY default to on would have the same results. More magic to getaddrinfo Take the Linux approach as the good one (it's the only compliant and non buggy -again, talking just about the issue on topic, i won't judge the general buggyness of any stack here), add a bit more (yet more!) of magic to getaddrinfo so it only returns the INET wildcard sockaddr when the kernel has no support for IPv6, and then the buggy stacks could be corrected with no loss of features and the unworkable one would get workable. Add a provision for double stack implementations RFC 2553 targets the dual stack systems, where there is one stack that implements both IPv4 and IPv6 protocols. If the RFC had a little comment telling that there is allowed to have systems with two isolated stacks, and that the IPv4 to IPv6 mapping may be absent on these systems, the non compliant implementations would become compliant and we would have some implementations compliant, non buggy and easy to work with AF-independently. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 07:50:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MEo4dP029227 for ; Fri, 22 Jun 2001 07:50:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MEo4dZ029226 for ipng-dist; Fri, 22 Jun 2001 07:50:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MEnxdP029219 for ; Fri, 22 Jun 2001 07:50:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18243 for ; Fri, 22 Jun 2001 07:50:00 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03942 for ; Fri, 22 Jun 2001 07:49:59 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id DE4C17BB; Fri, 22 Jun 2001 23:48:37 +0900 (JST) To: horape@tinuviel.compendium.net.ar Cc: ipng@sunroof.eng.sun.com In-reply-to: horape's message of Fri, 22 Jun 2001 11:29:57 -0300. <20010622112957.A16787@tinuviel.compendium.net.ar> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Fri, 22 Jun 2001 23:48:37 +0900 Message-Id: <20010622144837.DE4C17BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > Then the IPv6 sockets would have to be explicitly allowed to accept > IPv4 connections. So the programs that use the IPv6 centric way have > to be modified a bit, but the buggy implementations and the unworkable > one could be corrected without losing features. Just making > IPV6_V6ONLY default to on would have the same results. I really love to see this happen (polarity change is enough). also, if IPv4 mapped address support becomes optional (explicitly) to OS implementers it would be much better. However, we need to be careful - after looking into IPV6_V6ONLY (or IPV6_ACCEPTV4MAPPED) more closer, I came to realize some mess in setsockopt(2) behavior. for example: - A issues bind(:: port 80). as IPV6_V6ONLY is turned on, it grabs IPv6 traffic only. - B issues bind(0.0.0.0 port 80). it grabs IPv4 traffic only. - now, turn off IPV6_V6ONLY on A. what should happen? (1) check if there's anyone listening to 0.0.0.0 port 80. since there is B, the setsockopt should fail. (2) doesn't matter. if there's B, IPv4 traffic goes into B as B gives better match than A to any IPv4 traffic. btw, there's no spec talks about how traffic should be routed to which socket! there are A LOT of combinations we need to think about. >More magic to getaddrinfo > > Take the Linux approach as the good one (it's the only compliant and > non buggy -again, talking just about the issue on topic, i won't judge > the general buggyness of any stack here), add a bit more (yet more!) > of magic to getaddrinfo so it only returns the INET wildcard sockaddr > when the kernel has no support for IPv6, and then the buggy stacks > could be corrected with no loss of features and the unworkable one > would get workable. please clarify. are you suggesting that, for getaddrinfo(3) AI_PASSIVE case: - on platforms that makes :: and 0.0.0.0 conflict on bind(2), dual stack kernel config: getaddrinfo(3) returns :: only. IPv6 only kernel config: getaddrinfo(3) returns :: only. IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. this case includes linux. - on platforms that makes :: and 0.0.0.0 do not conflict on bind(2), dual stack kernel config: getaddrinfo(3) returns :: and 0.0.0.0. IPv6 only kernel config: getaddrinfo(3) returns :: only. IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. this case includes OpenBSD, NetBSD, FreeBSD. or are you suggesting something else? note that getaddrinfo(3) cannot look at IPV6_V6ONLY status on socket, so we cannot implement behavior depending on IPV6_V6ONLY status. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 09:49:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MGnGdP029350 for ; Fri, 22 Jun 2001 09:49:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MGnGTt029349 for ipng-dist; Fri, 22 Jun 2001 09:49:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MGnCdP029342 for ; Fri, 22 Jun 2001 09:49:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13414 for ; Fri, 22 Jun 2001 09:49:20 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05236 for ; Fri, 22 Jun 2001 10:49:15 -0600 (MDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 75207196743; Fri, 22 Jun 2001 13:49:10 -0300 (ART) Date: Fri, 22 Jun 2001 13:49:10 -0300 To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010622134910.B12471@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20010622144837.DE4C17BB@starfruit.itojun.org> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5MGnDdP029343 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > Then the IPv6 sockets would have to be explicitly allowed to accept > > IPv4 connections. So the programs that use the IPv6 centric way have > > to be modified a bit, but the buggy implementations and the unworkable > > one could be corrected without losing features. Just making > > IPV6_V6ONLY default to on would have the same results. > I really love to see this happen (polarity change is enough). > also, if IPv4 mapped address support becomes optional (explicitly) > to OS implementers it would be much better. > However, we need to be careful - after looking into IPV6_V6ONLY (or > IPV6_ACCEPTV4MAPPED) more closer, I came to realize some mess in > setsockopt(2) behavior. > for example: > - A issues bind(:: port 80). as IPV6_V6ONLY is turned on, it grabs > IPv6 traffic only. > - B issues bind(0.0.0.0 port 80). it grabs IPv4 traffic only. > - now, turn off IPV6_V6ONLY on A. what should happen? > (1) check if there's anyone listening to 0.0.0.0 port 80. since > there is B, the setsockopt should fail. > (2) doesn't matter. if there's B, IPv4 traffic goes into B as > B gives better match than A to any IPv4 traffic. > btw, there's no spec talks about how traffic should be routed > to which socket! > there are A LOT of combinations we need to think about. My opinion on this is that IPV6_V6ONLY should be allowed to change only if no bind or connect has been called on that socket. > >More magic to getaddrinfo > > Take the Linux approach as the good one (it's the only compliant and > > non buggy -again, talking just about the issue on topic, i won't judge > > the general buggyness of any stack here), add a bit more (yet more!) > > of magic to getaddrinfo so it only returns the INET wildcard sockaddr > > when the kernel has no support for IPv6, and then the buggy stacks > > could be corrected with no loss of features and the unworkable one > > would get workable. > please clarify. are you suggesting that, for getaddrinfo(3) AI_PASSIVE > case: > - on platforms that makes :: and 0.0.0.0 conflict on bind(2), > dual stack kernel config: getaddrinfo(3) returns :: only. > IPv6 only kernel config: getaddrinfo(3) returns :: only. > IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. > this case includes linux. > - on platforms that makes :: and 0.0.0.0 do not conflict on bind(2), > dual stack kernel config: getaddrinfo(3) returns :: and 0.0.0.0. > IPv6 only kernel config: getaddrinfo(3) returns :: only. > IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. > this case includes OpenBSD, NetBSD, FreeBSD. That's exactly what I was talking about. It's for me the least desired of the proposed solutions, but it's enough for my purposes. > itojun HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 10:09:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MH9MdP029374 for ; Fri, 22 Jun 2001 10:09:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MH9MFg029373 for ipng-dist; Fri, 22 Jun 2001 10:09:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MH9EdP029366 for ; Fri, 22 Jun 2001 10:09:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17266 for ; Fri, 22 Jun 2001 10:09:22 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06109 for ; Fri, 22 Jun 2001 10:09:20 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA110354 for ; Fri, 22 Jun 2001 13:02:17 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5MH9Fi54812 for ; Fri, 22 Jun 2001 13:09:15 -0400 Importance: Normal Subject: IPv6 TCP/UDP MIBs To: "ipng" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kristine Adamson" Date: Fri, 22 Jun 2001 13:09:12 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/22/2001 01:09:15 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am an SNMP developer and have just subscribed to this mailing list, so I apologize if there has already been a discussion on this subject. I noticed that the IPv6 MIB Design Team internet drafts for the revised TCP and UDP MIBs, define version neutral MIB tables. For a server application that opens an AF_INET6 socket and binds to the unspecified address (without setting the IPv6_V6ONLY socket option), should there be two entries in these MIB tables, one with the local address as IPv4/INADDR_ANY and one with the local address as IPv6/unspecified? Or should there be one entry with the local address as IPv6/unspecified? What if the server application opened an AF_INET6 socket and bound to an IPv4-mapped address? Would there be one entry in the tables with the local address as IPv4/address or as IPv6/IPv4-mapped address? I think my real question is, are the table entries supposed to reflect the IP address type from the view of the flow of the packets on the network, or from the viewpoint of the address family of the socket with which the connection/listener is associated? Thanks, Kris Adamson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 10:59:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MHxtdP029420 for ; Fri, 22 Jun 2001 10:59:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MHxtUx029419 for ipng-dist; Fri, 22 Jun 2001 10:59:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MHxpdP029412 for ; Fri, 22 Jun 2001 10:59:51 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21618 for ; Fri, 22 Jun 2001 10:59:57 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08073 for ; Fri, 22 Jun 2001 10:59:55 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E16CE7BB; Sat, 23 Jun 2001 02:57:14 +0900 (JST) To: "Dave Thaler" Cc: ipng@sunroof.eng.sun.com In-reply-to: dthaler's message of Fri, 22 Jun 2001 10:37:18 MST. <2E33960095B58E40A4D3345AB9F65EC101671DDC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Sat, 23 Jun 2001 02:57:14 +0900 Message-Id: <20010622175714.E16CE7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I was under the impression that IPV6_V6ONLY after a bind() should just >plain fail, in which case the problem you describe above wouldn't >happen. that makes sense and eliminates many of scenarios i had in mind. thanks. i still need to go through a lot of cases... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 11:07:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MI7NdP029452 for ; Fri, 22 Jun 2001 11:07:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MI7N0q029451 for ipng-dist; Fri, 22 Jun 2001 11:07:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MI7LdP029444 for ; Fri, 22 Jun 2001 11:07:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f5MI6Ov19283 for ipng@sunroof.eng.sun.com; Fri, 22 Jun 2001 11:06:24 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MI2mdP029431 for ; Fri, 22 Jun 2001 11:02:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29963 for ; Fri, 22 Jun 2001 11:02:54 -0700 (PDT) Received: from tweety.fe.up.pt (serv01.fe.up.pt [193.136.33.231]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12246 for ; Fri, 22 Jun 2001 12:02:51 -0600 (MDT) Received: from lorosae.fe.up.pt (root@lorosae.fe.up.pt [193.136.28.35]) by tweety.fe.up.pt (8.9.3/8.9.3) with ESMTP id TAA25741; Fri, 22 Jun 2001 19:01:56 +0100 (WET DST) Received: from fe.up.pt (bean.fe.up.pt [192.168.51.144]) by lorosae.fe.up.pt (8.10.1/8.10.1) with ESMTP id f5MI3k721795; Fri, 22 Jun 2001 19:03:47 +0100 (WET DST) Message-ID: <3B3387C3.10CEE170@fe.up.pt> Date: Fri, 22 Jun 2001 19:00:35 +0100 From: "Tito Carlos S. Vieira" Organization: Faculdade de Engenharia da Universidade do Porto X-Mailer: Mozilla 4.7 [en-gb] (WinNT; U) X-Accept-Language: en,pt MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Routing header Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'm studing the IPv6 protocol and after reading the "Internet Protocol Verson 6 Specification" (RFC2460) i have some dificult to understand the information of routing header (extension header). In page 11 refer " ... The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination. This function is very similar to IPv4's Loose Source and Record Route option.... " and in page 14 refer "... A Routing header is not examined or processed until it reaches the node identified in the Destination Address field of the IPv6 header. ..." I understand routing header as a method to save part of, or entire path, to destination of a packet and all intermediate routers look the information of vector of "addresses " (when extension header exist) in routing header, and based on this information forward the packect to the next address in the vector of addresses of routing header. I suppose this need to examine and process routing header in all intermediate nodes but in page 14 i can see that ideia are incorrect and routing header is only examined in the Destination Address. Can anyone help me to understand very well the goal of Routing Header? Maybe this is one basic question but i'm begginer :) Thank you before Tito -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 11:41:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MIfidP029485 for ; Fri, 22 Jun 2001 11:41:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MIfhsR029484 for ipng-dist; Fri, 22 Jun 2001 11:41:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MIfddP029477 for ; Fri, 22 Jun 2001 11:41:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09246 for ; Fri, 22 Jun 2001 11:41:46 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04738 for ; Fri, 22 Jun 2001 11:41:44 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 07B3B7BB for ; Sat, 23 Jun 2001 03:38:48 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: horape's message of Fri, 22 Jun 2001 13:49:10 -0300. <20010622134910.B12471@tinuviel.compendium.net.ar> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Sat, 23 Jun 2001 03:38:47 +0900 Message-Id: <20010622183848.07B3B7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> please clarify. are you suggesting that, for getaddrinfo(3) AI_PASSIVE >> case: >> - on platforms that makes :: and 0.0.0.0 conflict on bind(2), >> dual stack kernel config: getaddrinfo(3) returns :: only. >> IPv6 only kernel config: getaddrinfo(3) returns :: only. >> IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. >> this case includes linux. >> - on platforms that makes :: and 0.0.0.0 do not conflict on bind(2), >> dual stack kernel config: getaddrinfo(3) returns :: and 0.0.0.0. >> IPv6 only kernel config: getaddrinfo(3) returns :: only. >> IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. >> this case includes OpenBSD, NetBSD, FreeBSD. >That's exactly what I was talking about. It's for me the least desired of >the proposed solutions, but it's enough for my purposes. if so, you will have problem in linux case... i guess it is not the best route to change getaddrinfo(3) like above. i guess it better to ignore certain error results. for example: on linux system, if you would like to turn IPV6_V6ONLY option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. itojun -- the loop fails to accept IPv4 traffic on linux. hints.ai_flags = AI_PASSIVE; getaddrinfo(NULL, "80", &hints, &res0); for (res = res0; res; res = res->ai_next) { s[i] = socket(); if (res->ai_family == AF_INET6) setsockopt(s[i], IPV6_V6ONLY, on); bind(s[i]); listen(s[i]); i++; } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 11:45:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MIjcdP029504 for ; Fri, 22 Jun 2001 11:45:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MIjcRw029503 for ipng-dist; Fri, 22 Jun 2001 11:45:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MIjYdP029496 for ; Fri, 22 Jun 2001 11:45:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10349 for ; Fri, 22 Jun 2001 11:45:40 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06947 for ; Fri, 22 Jun 2001 11:45:37 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA133282 for ; Fri, 22 Jun 2001 14:38:37 -0500 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.226.185]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5MIjai74778 for ; Fri, 22 Jun 2001 14:45:36 -0400 Importance: Normal Sensitivity: Subject: Re: RFC 2553 bind semantics harms the way to AF independence To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Fri, 22 Jun 2001 14:42:09 -0400 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 06/22/2001 02:45:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have come to the same conclusion that IPV6_V6ONLY should be allowed to change only if no bind or connect has been called on that socket. Do the RFC authors agree? If so, can we expect the next draft of this RFC to have this restriction? Thanks Lori -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 11:46:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MIkxdP029521 for ; Fri, 22 Jun 2001 11:46:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MIkxEq029520 for ipng-dist; Fri, 22 Jun 2001 11:46:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MIktdP029513 for ; Fri, 22 Jun 2001 11:46:55 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10502 for ; Fri, 22 Jun 2001 11:47:02 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20711 for ; Fri, 22 Jun 2001 12:46:59 -0600 (MDT) Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 22 Jun 2001 10:35:46 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 22 Jun 2001 10:37:59 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Fri, 22 Jun 2001 10:37:49 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Jun 2001 10:37:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC 2553 bind semantics harms the way to AF independence Date: Fri, 22 Jun 2001 10:37:18 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101671DDC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2553 bind semantics harms the way to AF independence Thread-Index: AcD7KuJy5fb2h0QoSNKHVBm/Y7fGEwAFtxqg From: "Dave Thaler" To: "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 22 Jun 2001 17:37:19.0239 (UTC) FILETIME=[FC666970:01C0FB41] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5MIktdP029514 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun writes: > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > > > Then the IPv6 sockets would have to be explicitly allowed to accept > > IPv4 connections. So the programs that use the IPv6 centric way have > > to be modified a bit, but the buggy implementations and the unworkable > > one could be corrected without losing features. Just making > > IPV6_V6ONLY default to on would have the same results. > > I really love to see this happen (polarity change is enough). > also, if IPv4 mapped address support becomes optional (explicitly) > to OS implementers it would be much better. > > However, we need to be careful - after looking into IPV6_V6ONLY (or > IPV6_ACCEPTV4MAPPED) more closer, I came to realize some mess in > setsockopt(2) behavior. > > for example: > - A issues bind(:: port 80). as IPV6_V6ONLY is turned on, it grabs > IPv6 traffic only. > - B issues bind(0.0.0.0 port 80). it grabs IPv4 traffic only. > - now, turn off IPV6_V6ONLY on A. what should happen? > (1) check if there's anyone listening to 0.0.0.0 port 80. since > there is B, the setsockopt should fail. > (2) doesn't matter. if there's B, IPv4 traffic goes into B as > B gives better match than A to any IPv4 traffic. > btw, there's no spec talks about how traffic should be routed > to which socket! > > there are A LOT of combinations we need to think about. I was under the impression that IPV6_V6ONLY after a bind() should just plain fail, in which case the problem you describe above wouldn't happen. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 12:39:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MJdWdP029599 for ; Fri, 22 Jun 2001 12:39:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MJdWcm029598 for ipng-dist; Fri, 22 Jun 2001 12:39:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MJdHdP029591 for ; Fri, 22 Jun 2001 12:39:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23809 for ; Fri, 22 Jun 2001 12:39:04 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04560 for ; Fri, 22 Jun 2001 13:38:59 -0600 (MDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 54F8F196740; Fri, 22 Jun 2001 16:38:57 -0300 (ART) Date: Fri, 22 Jun 2001 16:38:57 -0300 To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010622163857.A9360@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20010622183848.07B3B7BB@starfruit.itojun.org> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5MJdTdP029592 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > >> please clarify. are you suggesting that, for getaddrinfo(3) AI_PASSIVE > >> case: > >> - on platforms that makes :: and 0.0.0.0 conflict on bind(2), > >> dual stack kernel config: getaddrinfo(3) returns :: only. > >> IPv6 only kernel config: getaddrinfo(3) returns :: only. > >> IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. > >> this case includes linux. > >> - on platforms that makes :: and 0.0.0.0 do not conflict on bind(2), > >> dual stack kernel config: getaddrinfo(3) returns :: and 0.0.0.0. > >> IPv6 only kernel config: getaddrinfo(3) returns :: only. > >> IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. > >> this case includes OpenBSD, NetBSD, FreeBSD. > >That's exactly what I was talking about. It's for me the least desired of > >the proposed solutions, but it's enough for my purposes. > if so, you will have problem in linux case... i guess it is not the > best route to change getaddrinfo(3) like above. i guess it better to > ignore certain error results. Yes, I agree that that's not the better solution, but if no one of the others is accepted, that's just enough to solve my problems (it will generate anothers and add complexity to something that's enough complex right now too) > for example: on linux system, if you would like to turn IPV6_V6ONLY > option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. If that changes were done, turning IPV6_V6ONLY on would not be frequently done. > itojun HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 12:45:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MJjQdP029618 for ; Fri, 22 Jun 2001 12:45:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MJjQDL029617 for ipng-dist; Fri, 22 Jun 2001 12:45:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MJjMdP029610 for ; Fri, 22 Jun 2001 12:45:22 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13407 for ; Fri, 22 Jun 2001 12:45:29 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10264 for ; Fri, 22 Jun 2001 12:45:27 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E4E0F7BB; Sat, 23 Jun 2001 04:42:03 +0900 (JST) To: horape@tinuviel.compendium.net.ar Cc: ipng@sunroof.eng.sun.com In-reply-to: horape's message of Fri, 22 Jun 2001 16:38:57 -0300. <20010622163857.A9360@tinuviel.compendium.net.ar> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Sat, 23 Jun 2001 04:42:03 +0900 Message-Id: <20010622194204.E4E0F7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> for example: on linux system, if you would like to turn IPV6_V6ONLY >> option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. >If that changes were done, turning IPV6_V6ONLY on would not be frequently d= >one. if you want to see IPv4 traffic on AF_INET socket (so that we don't get confused by bogus source address, and generating bogus traffic when responding) you will want to do IPV6_V6ONLY. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 12:51:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MJpYdP029647 for ; Fri, 22 Jun 2001 12:51:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MJpXga029646 for ipng-dist; Fri, 22 Jun 2001 12:51:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MJpTdP029639 for ; Fri, 22 Jun 2001 12:51:29 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14337 for ; Fri, 22 Jun 2001 12:51:35 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05328 for ; Fri, 22 Jun 2001 12:51:29 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 78F7D19675A; Fri, 22 Jun 2001 16:51:25 -0300 (ART) Date: Fri, 22 Jun 2001 16:51:25 -0300 To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010622165125.B10091@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20010622194204.E4E0F7BB@starfruit.itojun.org> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5MJpUdP029640 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > >> for example: on linux system, if you would like to turn IPV6_V6ONLY > >> option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. > >If that changes were done, turning IPV6_V6ONLY on would not be frequently d= > >one. > if you want to see IPv4 traffic on AF_INET socket (so that we don't > get confused by bogus source address, and generating bogus traffic > when responding) you will want to do IPV6_V6ONLY. Yes, maybe a flag telling that the old behaviour should be used would be need to be added too. > itojun HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 13:35:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MKZMdP029684 for ; Fri, 22 Jun 2001 13:35:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MKZMeO029683 for ipng-dist; Fri, 22 Jun 2001 13:35:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MKZIdP029676 for ; Fri, 22 Jun 2001 13:35:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA05183 for ; Fri, 22 Jun 2001 13:35:26 -0700 (PDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12425 for ; Fri, 22 Jun 2001 14:36:16 -0600 (MDT) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 26F5BD4F; Fri, 22 Jun 2001 13:35:14 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id E34F8E87; Fri, 22 Jun 2001 13:35:13 -0700 (PDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 495567A6; Fri, 22 Jun 2001 15:35:24 -0500 (CDT) Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id D37C97E4; Fri, 22 Jun 2001 15:35:23 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000000517; Fri, 22 Jun 2001 16:35:22 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id QAA0000073305; Fri, 22 Jun 2001 16:35:21 -0400 (EDT) Message-ID: <3B33AC09.6CA8D6DD@zk3.dec.com> Date: Fri, 22 Jun 2001 16:35:21 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: ru, en MIME-Version: 1.0 To: "Tito Carlos S. Vieira" Cc: ipng@sunroof.eng.sun.com Subject: Re: Routing header References: <3B3387C3.10CEE170@fe.up.pt> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tito See RFC 2292 or draft-ietf-ipngwg-2292bis-XX. They explain this well with different examples. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 22 14:27:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MLR4dP029778 for ; Fri, 22 Jun 2001 14:27:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5MLR4EN029777 for ipng-dist; Fri, 22 Jun 2001 14:27:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5MLR1dP029770 for ; Fri, 22 Jun 2001 14:27:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14205 for ; Fri, 22 Jun 2001 14:27:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19816 for ; Fri, 22 Jun 2001 15:27:57 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA25956; Fri, 22 Jun 2001 14:27:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f5MLR0c22629; Fri, 22 Jun 2001 14:27:00 -0700 X-mProtect: Fri, 22 Jun 2001 14:27:00 -0700 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdTuzLVl; Fri, 22 Jun 2001 14:26:59 PDT Message-Id: <4.3.2.7.2.20010622141253.0213ddb0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Jun 2001 14:26:24 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Updated Charter and acronym change Cc: Bob Hinden , deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, Attached is an updated proposed charter that the chairs and ADs have reached consensus on. Most of the changes are related to making it current (i.e., remove completed work items, updated milestones, revise some work items to reflect current work, etc.). After some thought the chairs and ADs think it would be best to also change the working group acronym from IPng to IPv6. The down side of this is that new drafts will have to be labeled as IPv6 (i.e., draft-ietf-ipv6-xxxx-00.txt) and this may cause some additional work keeping track of existing drafts. The other issue is that the online version charter at http://www.ietf.org will not list the documents produced while the working group was named IPng. This is being addressed by creating a link to the old charter in the new charter. Our conclusion is that changing the working group acronym from IPng to IPv6 will cause some short term annoyances, overall it will be simpler to have the working group name and acronym match. Please let us know if you disagree. Thanks, Bob Hinden and Steve Deering p.s. We will also see about making both ipng and ipv6 work for the mailing list. _____________________________________________________________________ IP Version 6 Working Group (IPv6) Chair(s): Bob Hinden Steve Deering Document Editor Bob Hinden (hinden@iprg.nokia.com) Internet Area Director(s): Thomas Narten Erik Nordmark Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:ipng@sunroof.eng.sun.com To Subscribe: majordomo@sunroof.eng.sun.com In Body: in body: subscribe ipng Archive: ftp://playground.sun.com/pub/ipng/mail-archive Web Pages: Charter: http://www.ietf.org/html.charters/ipv6-charter.html Working group info: http://playground.sun.com/ipv6/ Previous charter: http://www.ietf.org/html.charters/ipngwg-charter.html Description of Working Group: IP version 6 or IPv6 (also formerly known as IP Next Generation or IPng) is intended to support the continued growth of the Internet, both in size and capabilities, by offering a greatly increased IP address space and other enhancements over IPv4. The IP Next Generation (IPng) working group was originally chartered by the IESG to implement the recommendations of the IPng Area Directors as outlined at the July 1994 IETF meeting and in "The Recommendation for the IP Next Generation Protocol," RFC1752, January 1995. Most of the tasks in that original charter have been completed, and the core IPv6 protocol specifications are now on the IETF standards track. This charter focuses on completing the remaining work items and providing a home for IPv6 work that spans multiple IETF working groups. The working group is being renamed the IP Version 6 Working Group (IPv6) because it is a better description of the working group's focus. The specific working group's ongoing responsibilities are as follows: - Complete work from the original charter and follow-on work, as outlined below. - Keep all IPv6 working group documents moving along publication / standardization track. - Serve as a review board and body of competence and coordination for IPv6 architectural issues that span multiple IETF working groups. - Provide a home for IPv6-related work that doesn't fit in an existing IETF working group and doesn't merit a working group of its own. - Provide technical input to the IAB, IANA and Internet Address Registries with regard to IPv6 address allocation policies and procedures. The list of the working group's current work items is as follows: - Revise and advance to Draft Standard the IPv6 Address Architecture document [RFC 2373] - Revise IPv6 Aggregatable Unicast Addresses [RFC 2374], removing the policy aspects that are considered RIR issues. - Complete work on recommended address-selection algorithms - Revise ICMPv6 spec [RFC 2463] (scope-exceeded err, no error to redirect, editorial) - Revise Generic Tunneling spec [RFC 2473] (add bidirectional tunnels) - Update Basic and Advanced API specs [RFC 2553, RFC 2292] - Complete Scoped Address Architecture spec and any necessary revisions to other working group drafts required to properly implement support for IPv6 address scoping - Work on host-based solutions to site-multihoming problems (in coordination with multi6) - Complete work on local IPv6 networking as part of IPv6 plug-and-play (to be coordinated with other WGs as appropriate, e.g., dnsext, zeroconf, etc.) - Document IPv6 renumbering model - Complete the IPv6 Node Information Queries spec - Revise and update the base IPv4/IPv6 MIBs and produce a new consistent set of MIBs that cover IPv4 and IPv6 together. RFCs to be looked at together: 2011, 2012, 2013, 2096, 2851, 2452, 2454, 2465, 2466 and possibly 3019. New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group. The working group would welcome contributions on the following topics (this is not an exhaustive list): - Flow label standardization - Solutions to other multihoming issues, beyond those specific to site-multihoming - Integration of autoconfiguration, mobility, DNS, service discovery and other technologies to enhance IPv6 plug-and-play - IPv6 dial-up issues relating to address assignment, use of Neighbor Discovery, etc. (not including AAA work) - Specifications for IPv6 over additional media - Host use of anycast; TCP use of anycast - Support for multi-link subnets (single subnet spans multiple links) - Scope-name discovery - IPv6 protocol extensions to accommodate mobile wireless networks. Goals and Milestones: Jun 2001 Revise IPv6 Address Architecture and resubmit to IESG for Draft Standard Jul 2001 Revise IPv6 Aggregatable Unicast Addresses and submit for Draft Standard Jul 2001 Resubmit the IPv6 Node Information Queries spec Aug 2001 Compete Address Selection specification and submit for Proposed Standard Dec 2001 Update ICMP document and resubmit for Draft Standard Dec 2001 Complete DNS Discovery draft and submit for Proposed Standard Dec 2001 Update Generic Tunneling specification and resubmit for Proposed Standard Dec 2001 Complete updates to Basic and Advanced API specifications and submit for Informational Mar 2002 Complete Scoped Address Architecture and submit for Proposed Standard May 2002 Submit document describing IPv6 renumbering model for Informational. _____________________________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 04:28:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBSadP000136 for ; Sat, 23 Jun 2001 04:28:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NBSaqm000135 for ipng-dist; Sat, 23 Jun 2001 04:28:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBSWdP000128 for ; Sat, 23 Jun 2001 04:28:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19259 for ; Sat, 23 Jun 2001 04:28:39 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28717 for ; Sat, 23 Jun 2001 05:28:35 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5NBSI002352; Sat, 23 Jun 2001 18:28:19 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: ipng@sunroof.eng.sun.com, deering@cisco.com Subject: Re: Updated Charter and acronym change In-Reply-To: <4.3.2.7.2.20010622141253.0213ddb0@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20010622141253.0213ddb0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Jun 2001 18:28:18 +0700 Message-ID: <2350.993295698@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 22 Jun 2001 14:26:24 -0700 From: Bob Hinden Message-ID: <4.3.2.7.2.20010622141253.0213ddb0@mailhost.iprg.nokia.com> | After some thought the chairs and ADs think it would be best to also change | the working group acronym from IPng to IPv6. Why? This seems all gloss, no substance, and a bunch of meaningless work and disruption for no benefit. The only real advantage to doing this would be if somewhere on the horizon was a WG for an even newer generation of IP. | Our conclusion is that changing the working group acronym from IPng to IPv6 | will cause some short term annoyances, overall it will be simpler to have | the working group name and acronym match. The working group name, as I understand it, is currently "IPNG". That's what the current charter calls it (with ipngwg as its acronym). You'll only make them match if you're changing the working group name as well (which it appears you are). If the "next" in the label is the problem, given that we want to give the impression that we're there already, just redefine that to "new" which is certainly still true. Before ipng (ipv6) ceases being new this WG ought to be extinct. The only hint of why is in the proposed new charter itself ... The working group is being renamed the IP Version 6 Working Group (IPv6) because it is a better description of the working group's focus. which I don't follow at all, IPng and IPv6 are the same thing (for the past 7 years, and the next 7 I hope). Whatever one means, so does the other - the focus is identical. | p.s. We will also see about making both ipng and ipv6 work for the mailing | list. There's no need to do that even if the name change occurs - the mailing list could retain its old identity (poisson still uses "poised" as its list name, which was the WG name 2 generations of WGs ago, and dnsext uses namedroppers which was never a WG name, but has been the DNS mailing list though a whole stck of WGs). I have no problems with anything of substance in the charter, though I do find the juxtaposition of the following two paragraphs amusing, to say the least... New work items not listed above require the approval of the working group and Internet Area directors before they will be taken on by the working group. The working group would welcome contributions on the following topics (this is not an exhaustive list): Which is to say, we can't do anything not listed above, but we want to do all of the following (none of which was listed above). Weird... kre ps: do you really expect June 2001 milestones to be met? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 04:31:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBVBdP000158 for ; Sat, 23 Jun 2001 04:31:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NBVBLX000157 for ipng-dist; Sat, 23 Jun 2001 04:31:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBV8dP000148 for ; Sat, 23 Jun 2001 04:31:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19482 for ; Sat, 23 Jun 2001 04:31:14 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29881 for ; Sat, 23 Jun 2001 05:31:12 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.143.102) by smtp2.libero.it (5.5.025) id 3AE981AF00CD6869; Sat, 23 Jun 2001 13:31:12 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id D78A228A40; Sat, 23 Jun 2001 13:27:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id B5B5928A35; Sat, 23 Jun 2001 13:27:23 +0200 (CEST) Date: Sat, 23 Jun 2001 13:27:23 +0200 (CEST) From: Mauro Tortonesi To: Cc: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010622112957.A16787@tinuviel.compendium.net.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) { > listenfds[n] = socket(res->ai_family, res->ai_socktype, > res->ai_protocol); > if(listenfds[n] < 0) > continue; /* libc supports protocols that kernel don't */ > > if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0) > die(); > > if(listen(listenfds[n], 10) != 0) > die(); > n++; > } i am afraid i don't understand this portion of code. is getaddrinfo expected to return one-and-only-one ready-to-be-bound address for every AF when called with flag AI_PASSIVE set? there's nothing in the drafts that states this: The AI_PASSIVE flag in the ai_flags member of the hints structure specifies how to fill in the IP address portion of the socket address structure. If the AI_PASSIVE flag is specified, then the returned address information must be suitable for use in binding a socket for accepting incoming connections for the specified service (i.e. a call to bind()). In this case, if the nodename argument is null, then the IP address portion of the socket address structure will be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE bit is not set, the returned address information must be suitable for a call to connect( ) (for a connection-mode protocol) or for a call to connect(), sendto() or sendmsg( ) (for a connectionless protocol). In this case, if the nodename argument is null, then the IP address portion of the socket address structure will be set to the loopback address. This flag is ignored if the nodename argument is not null. from what i can guess, instead, the expected behaviour for getaddrinfo in this case (AI_PASSIVE, AF_UNSPEC and SOCK_STREAM set) is to return a ready-to-be-bound ::1 (ipv6) address. am i wrong? if so, your code (which is truly AF-indipendent) is not RFC2553-compliant. or better, the API specified by RFC2553 is not AF-indipendent. > A comment > > But that's not all. > > Nor the IPv6 centric nor the AF independent way work as cleanly as I > presented them. The IPv6 centric way dies on OS where the IPv6 support > is not compiled, so when programming the IPv6 centric way you should > check if the socket call fails and then fall back to work as a pure > IPv4 server (ie, duplication of code) duplication of code is (and - if we're not gonna change the API draft in a significant way - will always be) inevitable. there are MANY problems in handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single AF_INET6 socket, and most of them are related to security. moreover, all the ipv6 compliant code that i have seen until now is full of preprocessor switches like: #ifdef INET6 /* code that handles both ipv6 and ipv4 */ /* this code is expected to make a heavy use of get{name,addr}info * and to avoid inet_{ntop,pton} when possible. */ #else /* ipv4-only (traditional) code */ /* this code is expected to make heavy use of gethostby{name,addr} * inet_{ntoa,aton} etc... */ #endif this is NOT AF-indipendent programming, as you have correctly pointed out. that's the point. RFC2553 focuses only on ipv6 and ipv4, and its main purpose is to extend the BSD API in order to make the transition to ipv6 as painless as possible. unfortunately, it has completely missed the point. by stating that it's possible to receive ipv4 traffic with AF_INET6 sockets, RFC2553 has introduced a BIG number of special cases which the programmers must handle. programming ipv6-compliant software in the RFC2553-compliant way is quite a nightmare. if you have some experience in porting apps to ipv6 under linux (which is, as you state, a RFC2553-compliant OS), you sure know what i am talking about. > Conclusion: there's no good implementations of RFC 2553 > > If my classification is not exhaustive and there is a non-buggy, fully > compliant implementation of the RFC 2553 bind semantics that doesn't > cause problems to programs written in an AF independent way, I'd be > very pleased to know them and learn how they have avoided all that > problems. But I believe that the cause is that the RFC is not very > good on that point and should have more work done on that. you are absolutely right. > Possible solutions [...] > Deprecate IPv4 mapped addresses > > Maybe the time for IPv4 mapped addresses is over, maybe that was a > good mechanism to get things to start rolling but it's time to grow up > and left them. i would be the best thing to do, IMHO. if we wish to achieve true AF-indipendence, we have to cut all the relationships between different AF. AF_INET6 sockets shouldn't have any relation with AF_INET sockets. it should't be possible to receive ipv4 traffic on a AF_INET6 socket. > Itojun has mentioned in their ipv6-transition-abuse draft many other > problems that the IPv4 mapped addresses have. that's another reason for removing IPv4 mapped addresses. > But, there is too much work done in the IPv6 centric way, so maybe it > isn't prudent to throw them all at once. i do not agree here. IPv4 mapped addresses should be deprecated and put in disuse as soon as possible. > Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > Then the IPv6 sockets would have to be explicitly allowed to accept > IPv4 connections. So the programs that use the IPv6 centric way have > to be modified a bit, but the buggy implementations and the unworkable > one could be corrected without losing features. Just making > IPV6_V6ONLY default to on would have the same results. no. all of this should also be deprecated, IMHO. AF_INET6 sockets should be IPV6_V6ONLY and there shouldn't be any chance to change this behaviour. > More magic to getaddrinfo > > Take the Linux approach as the good one (it's the only compliant and > non buggy -again, talking just about the issue on topic, i won't judge > the general buggyness of any stack here), add a bit more (yet more!) > of magic to getaddrinfo so it only returns the INET wildcard sockaddr > when the kernel has no support for IPv6, and then the buggy stacks > could be corrected with no loss of features and the unworkable one > would get workable. i don't understand you here. for a true AF-indipendent programming style, getaddrinfo should return a ready-to-be-bound address for every AF. for all those addresses, it should be possible to call bind without any conflicts. > Add a provision for double stack implementations > > RFC 2553 targets the dual stack systems, where there is one stack that > implements both IPv4 and IPv6 protocols. > > If the RFC had a little comment telling that there is allowed to have > systems with two isolated stacks, and that the IPv4 to IPv6 mapping > may be absent on these systems, the non compliant implementations > would become compliant and we would have some implementations > compliant, non buggy and easy to work with AF-independently. that's nonsense. compliant stacks would not be AF-independent, but quasi-compliant stacks would be. IMHO, a best choice would be to re-define the behaviour of AF_INET6 sockets in order to cut all the relationships with ipv4. AF-indipendence would be a great achievement. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 04:31:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBVKdP000169 for ; Sat, 23 Jun 2001 04:31:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NBVK71000168 for ipng-dist; Sat, 23 Jun 2001 04:31:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBVGdP000161 for ; Sat, 23 Jun 2001 04:31:16 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA27006 for ; Sat, 23 Jun 2001 04:31:22 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29615 for ; Sat, 23 Jun 2001 04:31:17 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.143.102) by smtp2.libero.it (5.5.025) id 3AE981AF00CD6866; Sat, 23 Jun 2001 13:31:11 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id B06C828A41; Sat, 23 Jun 2001 13:29:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id AA26928A35; Sat, 23 Jun 2001 13:29:20 +0200 (CEST) Date: Sat, 23 Jun 2001 13:29:20 +0200 (CEST) From: Mauro Tortonesi To: Cc: Jun-ichiro itojun Hagino , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010622134910.B12471@tinuviel.compendium.net.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > > - on platforms that makes :: and 0.0.0.0 do not conflict on bind(2), > > dual stack kernel config: getaddrinfo(3) returns :: and 0.0.0.0. > > IPv6 only kernel config: getaddrinfo(3) returns :: only. > > IPv4 only kernel config: getaddrinfo(3) returns 0.0.0.0 only. > > this case includes OpenBSD, NetBSD, FreeBSD. > > That's exactly what I was talking about. It's for me the least desired of > the proposed solutions, but it's enough for my purposes. this should be the correct behaviour, IMHO. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 04:42:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBgkdP000204 for ; Sat, 23 Jun 2001 04:42:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NBgkk6000203 for ipng-dist; Sat, 23 Jun 2001 04:42:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBggdP000196 for ; Sat, 23 Jun 2001 04:42:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22136 for ; Sat, 23 Jun 2001 04:42:49 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04703 for ; Sat, 23 Jun 2001 05:42:47 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5NBgYi44606; Sat, 23 Jun 2001 13:42:34 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA23003; Sat, 23 Jun 2001 13:42:33 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5NBgXO77912; Sat, 23 Jun 2001 13:42:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106231142.f5NBgXO77912@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: horape@tinuviel.compendium.net.ar cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Fri, 22 Jun 2001 11:29:57 -0300. <20010622112957.A16787@tinuviel.compendium.net.ar> Date: Sat, 23 Jun 2001 13:42:33 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: RFC 2553 bind semantics harms the way to AF independence Horacio J. Peña RFC 2553 enforces the IPv4 mapped on IPv6 model for bind(2). This has had some very useful short term results, but harms very badly the way to AF independence, a goal that in my opinion we should try to reach. => I understand your concern but this is a matter of taste and RFC 2553 chose one flavour. The basic issue is whether IPv6/AF_INET6 is a new protocol/separate address family or not. Obviously you'd prefer the split space model but RFC 2553 specifies a merged space model, i.e. "IPv6 is not a new protocol, IPv6 is a new version of the IP protocol". Of course one version must be represented in the other so IPv4 is injected into IPv6 as mapped addresses. There are pros and cons but RFC 2553 (and its revision which should be published soon) makes the support of this mandatory. You can just believe that AF_INET should be obsolete ASAP (this is not yet the case but is a reasonable target, isn't it?) Regards Francis.Dupont@enst-bretagne.fr PS: the technical part was already discussed in the V6ONLY thread... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 04:55:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBtRdP000230 for ; Sat, 23 Jun 2001 04:55:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NBtRaj000229 for ipng-dist; Sat, 23 Jun 2001 04:55:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NBtNdP000219 for ; Sat, 23 Jun 2001 04:55:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22636 for ; Sat, 23 Jun 2001 04:55:30 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20250 for ; Sat, 23 Jun 2001 05:56:17 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5NBtLi40843; Sat, 23 Jun 2001 13:55:21 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA23048; Sat, 23 Jun 2001 13:55:21 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5NBtKO77968; Sat, 23 Jun 2001 13:55:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106231155.f5NBtKO77968@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Lori Napoli" cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Fri, 22 Jun 2001 14:42:09 EDT. Date: Sat, 23 Jun 2001 13:55:20 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: We have come to the same conclusion that IPV6_V6ONLY should be allowed to change only if no bind or connect has been called on that socket. => I agree that to change IPV6_V6ONLY on a bound socket (i.e. after a bind or connect) is silly. I've looked at my code: it forbids to set IPV6_V6ONLY on a bound socket (not exactly what you ask for). Conclusion: wording should be very accurate. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 05:35:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NCZYdP000301 for ; Sat, 23 Jun 2001 05:35:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NCZYOQ000300 for ipng-dist; Sat, 23 Jun 2001 05:35:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NCZUdP000293 for ; Sat, 23 Jun 2001 05:35:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21542 for ; Sat, 23 Jun 2001 05:35:37 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA04795 for ; Sat, 23 Jun 2001 05:35:36 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5NCZOi44663; Sat, 23 Jun 2001 14:35:24 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA23160; Sat, 23 Jun 2001 14:35:23 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5NCZNO78095; Sat, 23 Jun 2001 14:35:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106231235.f5NCZNO78095@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Sat, 23 Jun 2001 13:27:23 +0200. Date: Sat, 23 Jun 2001 14:35:23 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: duplication of code is (and - if we're not gonna change the API draft in a significant way - will always be) inevitable. there are MANY problems in handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single AF_INET6 socket, and most of them are related to security. => I disagree. There is *no* security issue with IPv4-mapped addresses as soon as one doesn't forget them. moreover, all the ipv6 compliant code that i have seen until now is full of preprocessor switches like: => no, there are some codes which are written without switches. Of course they work only on systems where IPv6 is fully integrated. programming ipv6-compliant software in the RFC2553-compliant way is quite a nightmare. if you have some experience in porting apps to ipv6 under linux (which is, as you state, a RFC2553-compliant OS), you sure know what i am talking about. => I have ported many applications to IPv6 on BSD systems without the problems you seemed to have encountered... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 08:41:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NFfYdP000452 for ; Sat, 23 Jun 2001 08:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NFfYm9000451 for ipng-dist; Sat, 23 Jun 2001 08:41:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NFfUdP000444 for ; Sat, 23 Jun 2001 08:41:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19554 for ; Sat, 23 Jun 2001 08:41:36 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09881 for ; Sat, 23 Jun 2001 09:41:33 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 7D7437BB; Sun, 24 Jun 2001 00:41:11 +0900 (JST) To: Francis Dupont Cc: horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Sat, 23 Jun 2001 14:35:23 +0200. <200106231235.f5NCZNO78095@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Sun, 24 Jun 2001 00:41:11 +0900 Message-Id: <20010623154111.7D7437BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=> I disagree. There is *no* security issue with IPv4-mapped addresses >as soon as one doesn't forget them. you were very lucky. there are real attack scenarios, of course depending on configurations/stack implementations. - if you implement from RFC2553/RFC2765 straight you will implement a vulnerable implementation. - you can't assume programmers to be clever enough to check IPv4 mapped address right. the point of IPv4 mapped address support is to decrease porting cost, into as simple as s/AF_INET/AF_INET6/ and s/gethostbyname/gethostbyname2/. if you did that, you will get a likely-to-vulnerable userland code. if you are careful enough to put IN6_IS_ADDR_V4MAPPED everywhere, why not rewriting it to use getaddrinfo(AI_PASSIVE) and multiple sockets? so "as soon as ..." looks to me too optimistic. the following is KAME v6test configuration file that generates certain packets. the following URL an (expired) draft on this problem. http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt let me know if you know of of realworld implementation that are vulnerable (i believe there are a lot). hope TAHI test to cover these cases :-) itojun # $KAME: transition-abuse.conf,v 1.12 2001/06/23 15:40:30 itojun Exp $ # for more details/discussions, see # http://playground.iijlab.net/i-d/draft-itojun-ipv6-transition-abuse-01.txt # abuse of IPv4 mapped address. under the following conditions: # - the victim kernel stack does not check against IPv4 mapped address on # IPv6 native packet # - the victim node runs udp echo service (inetd) on AF_INET6 socket # the victim node can generate IPv4 broadcast responses mistakenly, # leading to DoS. # # the example also tries bypass access controls and attack inside the firewall # from outside (works nicer when 9.0.0.1 is an IPv4 firewall). # # you can attack any udp services by the same way. udp echo service works the # best for bad guys (or the worst for victims) since udp packet format is # common to IPv4 and IPv6, and echo service is common for IPv4 and IPv6. # therefore, the broadcast response will call for more responses (assumption: # inetd does not check udp source port). # attacker -> victim: from ::ffff:10.255.255.255 to ::ffff:9.0.0.1 # victim -> broadcast: from 9.0.0.1 to 10.255.255.255 # more response: from many guys to 9.0.0.1 # # RFC2553 does NOT comment on this case. also, if the victim node supports # SIIT (RFC2765) environment, the kernel stack is unable to filter out # the packet. # # to protect your implmentation from the attack, there are multiple ways. # the author recommends to implement the first three items at least: # 1. do not support IPv4 mapped address on AF_INET6 API (not compatible with # RFC2553 section 4.2). # 2. implement 2553bis-03 IPV6_V6ONLY socket option, and make the default value # to on (the default value suggested by the document is "off"). # this has almost the same effect as the first bullet (if userland # code changes IPV6_V6ONLY manually, you will become vulnerable again # depending on userland program). the change will make your stack # incompatible with 2553bis-03 section 4.2. # 3. drop any IPv6 native packet with IPv4 mapped address (incompatible with # RFC2765). # 4. on EVERY userland application check the IPv6 source address, if it # embeds bad IPv4 address (impossible in reality, as it's hard to know what # is "bad" address, and there are millions of coders in different places) # # of course, KAME is not affected. the implementation status differs # between *BSD base systems (due to policy differences in *BSD). # - KAME/OpenBSD: (1) and (3) - always safe # - KAME/NetBSD: (2) and (3) - safe as long as userland programmer does # not change IPV6_V6ONLY # - KAME/FreeBSD and KAME/BSDI: (3) - subject to API complications # 00:28:37.148869 ::ffff:10.255.255.255.7 > ::ffff:9.0.0.1.7: [udp sum ok] udp 0 (len 8, hlim 255) # 6000 0000 0008 11ff 0000 0000 0000 0000 # 0000 ffff 0aff ffff 0000 0000 0000 0000 # 0000 ffff 0900 0001 0007 0007 0008 ebd0 v4mapped1:\ :ip6-v4mapped1:udp1: ip6-v4mapped1:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="::ffff:10.255.255.255":\ :ip6_dst="::ffff:9.0.0.1": udp1:\ :udp_sport#7:udp_dport#7: # one more abuse of IPv4 mapped address. # bad guy pretends that the traffic is from the machine itself. # if the victim node re-selects source address on the first udp echo response, # we will see infinite IPv4 echo traffic on loopback interface # # note: most of recent BSD inetd rejects udp echo with source port = 7, # so they are safe. however, it is still true that we can bypass access # control like this. # 00:28:51.286261 ::ffff:127.0.0.1.7 > ::ffff:9.0.0.1.7: [udp sum ok] udp 0 (len 8, hlim 255) # 6000 0000 0008 11ff 0000 0000 0000 0000 # 0000 ffff 7f00 0001 0000 0000 0000 0000 # 0000 ffff 0900 0001 0007 0007 0008 77ce v4mapped2:\ :ip6-v4mapped2:udp1: ip6-v4mapped2:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="::ffff:127.0.0.1":\ :ip6_dst="::ffff:9.0.0.1": # abuse of IPv4 compatible address (auto tunnel). under the following # conditions: # - the victim kernel stack supports auto tunnel # the victim node will generate IPv4 broadcast responses, leading to DoS. # # the example also tries bypass access controls and attack inside the firewall # from outside (works nicer when 9.0.0.1 is an IPv4 firewall). # # with other IPv6 source address, bad guys can attack other IPv4 victim nodes # anonymously. however, IPv4 packet will always be tunnelled IPv6 packet # (ip.ip_p == 41), therefore there will be no further traffic amplicfication. # # RFC2883 has a comment for embedded broadcast/multicast case, however, # the set of rules does not make a perfect protection. # # KAME is not affected, since it does not support auto tunnels and it drops # packets with IPv4 compatible address. # 00:29:02.702670 ::10.255.255.255 > ::9.0.0.1: icmp6: echo request (len 8, hlim 255) # 6000 0000 0008 3aff 0000 0000 0000 0000 # 0000 0000 0aff ffff 0000 0000 0000 0000 # 0000 0000 0900 0001 8000 6bbd 0000 0000 v4compat:\ :ip6-v4compat:icmp6echo: ip6-v4compat:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="::10.255.255.255":\ :ip6_dst="::9.0.0.1": icmp6echo:\ :icmp6_type=echo:icmp6_code#0:icmp6_cksum=auto:icmp6_id#0:\ :icmp6_seq#0: # abuse of 6to4. under the following conditions: # - the victim node is configured as an 6to4 relay # the victim node will generate IPv4 broadcast responses, leading to DoS. # # with other IPv6 source address, bad guys can attack other IPv4 victim nodes # anonymously. however, IPv4 packet will always be tunnelled IPv6 packet # (ip.ip_p == 41), therefore there will be no further traffic amplicfication. # # 6to4 RFC suggests checks against embedded broadcat addresses, but it # does not work in reality. for example, 9.0.0.1 has no idea about topology # within 16.0.0.0/8 topology, and has no idea about IPv4 broadcast address # assignments. # because of this, the following example tries to generate a packet to # 16.255.255.255 by using 9.0.0.1 (6to4 relay) as trampoline, and hide the # identity of the real attacker. # if the admin at 16.0.0.0/8 is careful enough to drop directed broadcasts, # the scenario does not work. # # 6to4 RFC has a comment for embedded broadcast/multicast case, as well as # private address cases. so if an implementation follows the suggestion, # there is less chance for vulnerability. but - beware, "less" chance, not # "no" chance. you are still vulnerable to some of the scenarios. # # KAME is not affected, as long as you don't configure your machine as 6to4 # relay. if you configure KAME as 6to4 relay, you are vulnerable to some # of the attack scenarios. # 00:28:25.121083 2002:10ff:ffff::1 > 2001:900:1::1: icmp6: echo request (len 8, hlim 255) # 6000 0000 0008 3aff 2002 10ff ffff 0000 # 0000 0000 0000 0001 2001 0900 0001 0000 # 0000 0000 0000 0001 8000 25b8 0000 0000 stf:\ :ip6-stf:icmp6echo: ip6-stf:\ :ip6_flow#0:ip6_plen=auto:ip6_nxt=auto:ip6_hlim#255:\ :ip6_src="2002:10ff:ffff::1":\ :ip6_dst="2001:0900:0001::1": # homework: try using these addresses in extension headers (routing header, # home address option, whatever) and come up with more complex attack scnearios. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 12:11:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NJBBdP000753 for ; Sat, 23 Jun 2001 12:11:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NJBBQD000752 for ipng-dist; Sat, 23 Jun 2001 12:11:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NJB7dP000745 for ; Sat, 23 Jun 2001 12:11:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16818 for ; Sat, 23 Jun 2001 12:11:14 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28315 for ; Sat, 23 Jun 2001 12:11:13 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.140.177) by smtp1.libero.it (5.5.025) id 3AE980E700D1BC66; Sat, 23 Jun 2001 21:11:05 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 62AEA28A41; Sat, 23 Jun 2001 21:03:45 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 591A928A35; Sat, 23 Jun 2001 21:03:45 +0200 (CEST) Date: Sat, 23 Jun 2001 21:03:45 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106231235.f5NCZNO78095@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 23 Jun 2001, Francis Dupont wrote: > => no, there are some codes which are written without switches. of course there are. RFC 2553 has been written in order to minimize the need for those switches. > Of course they work only on systems where IPv6 is fully integrated. i don't think so. switches are necessary in many cases (especially when you want the same code to work on a traditional ipv4 system that uses gethostby{name,addr} and on a new ipv6-compliant system which uses get{addr,name}info). > => I have ported many applications to IPv6 on BSD systems without > the problems you seemed to have encountered... it depends from the application and the policy of the programmer. i prefer not to modify existing ipv4 code (for compatibility with older systems), so i generally use A LOT of switches. i also try to be careful when handling common ipv6/ipv4 cases, and this make my work a little harder. i have seen that many programmers find difficult the process of porting their apps to ipv6. i think that we should write a small informational document that explains how to write good ipv6-compliant code. itojun's "Implementing AF-indipendent apps" is a very good document. however, it is obsolete and it doesn't give many informations. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 23 12:26:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NJQ6dP000774 for ; Sat, 23 Jun 2001 12:26:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5NJQ6Te000773 for ipng-dist; Sat, 23 Jun 2001 12:26:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5NJQ2dP000766 for ; Sat, 23 Jun 2001 12:26:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14403 for ; Sat, 23 Jun 2001 12:26:08 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06240 for ; Sat, 23 Jun 2001 13:26:58 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 7EB124B20; Sun, 24 Jun 2001 04:25:55 +0900 (JST) To: Mauro Tortonesi Cc: Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com In-reply-to: mauro's message of Sat, 23 Jun 2001 21:03:45 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: itojun@iijlab.net Date: Sun, 24 Jun 2001 04:25:55 +0900 Message-ID: <10206.993324355@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >i have seen that many programmers find difficult the process of porting >their apps to ipv6. i think that we should write a small informational >document that explains how to write good ipv6-compliant code. we really need to convince random book authors to update their programming examples, from gethostbyname() to getnameinfo()... >itojun's "Implementing AF-indipendent apps" is a very good document. >however, it is obsolete and it doesn't give many informations. it is a bit dated, but the content should be still valid. do you have any suggestions for improvements? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 06:13:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5ODD7dP001726 for ; Sun, 24 Jun 2001 06:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5ODD7ec001725 for ipng-dist; Sun, 24 Jun 2001 06:13:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5ODD3dP001718 for ; Sun, 24 Jun 2001 06:13:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09091 for ; Sun, 24 Jun 2001 06:13:11 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03338 for ; Sun, 24 Jun 2001 06:13:10 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5ODCti46711; Sun, 24 Jun 2001 15:12:56 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA26396; Sun, 24 Jun 2001 15:12:55 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5ODCsO80487; Sun, 24 Jun 2001 15:12:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106241312.f5ODCsO80487@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Sat, 23 Jun 2001 21:03:45 +0200. Date: Sun, 24 Jun 2001 15:12:54 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => no, there are some codes which are written without switches. of course there are. RFC 2553 has been written in order to minimize the need for those switches. > Of course they work only on systems where IPv6 is fully integrated. i don't think so. => but we are sating the same thing. Perhaps we have different meanings for "integration"? switches are necessary in many cases (especially when you want the same code to work on a traditional ipv4 system that uses gethostby{name,addr} and on a new ipv6-compliant system which uses get{addr,name}info). > => I have ported many applications to IPv6 on BSD systems without > the problems you seemed to have encountered... it depends from the application and the policy of the programmer. i prefer not to modify existing ipv4 code (for compatibility with older systems), so i generally use A LOT of switches. i also try to be careful when handling common ipv6/ipv4 cases, and this make my work a little harder. => I have the opposite policy so results are different. My target is integrated systems where IPv6 is *not* optional, no more than IP is! i have seen that many programmers find difficult the process of porting their apps to ipv6. i think that we should write a small informational document that explains how to write good ipv6-compliant code. itojun's "Implementing AF-indipendent apps" is a very good document. however, it is obsolete and it doesn't give many informations. => I have done one but it is more than obsolete now. But my target is not AF-independence, it is IP version independence, even if a true AF independence (i.e. codes which can work with ISO CLNP) is a plus. Regards Francis.Dupont@enst-bretagne.fr PS: codes full of switches are at least unreadable... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 07:03:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OE3odP001756 for ; Sun, 24 Jun 2001 07:03:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OE3oMV001755 for ipng-dist; Sun, 24 Jun 2001 07:03:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OE3kdP001748 for ; Sun, 24 Jun 2001 07:03:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10765 for ; Sun, 24 Jun 2001 07:03:53 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01730 for ; Sun, 24 Jun 2001 07:03:52 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5OE3Jo08196; Sun, 24 Jun 2001 17:03:19 +0300 Date: Sun, 24 Jun 2001 17:03:19 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106241312.f5ODCsO80487@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001, Francis Dupont wrote: > switches are necessary in many cases (especially when > you want the same code to work on a traditional ipv4 system that uses > gethostby{name,addr} and on a new ipv6-compliant system which uses > get{addr,name}info). > > > => I have ported many applications to IPv6 on BSD systems without > > the problems you seemed to have encountered... > > it depends from the application and the policy of the programmer. > i prefer not to modify existing ipv4 code (for compatibility with older > systems), so i generally use A LOT of switches. i also try to be careful > when handling common ipv6/ipv4 cases, and this make my work a little > harder. > > => I have the opposite policy so results are different. My target is > integrated systems where IPv6 is *not* optional, no more than IP is! That is a longer term goal. Currently that only works in closed environments. >From my viewpoint, the applications wrt. ipv6 support can be split into a few categories: 1) no ipv6 support 2) ipv6 support togglable at compile time; if you use the app on ipv4-only system, it won't even run (or ipv4 features don't work properly) [for example xinetd] 3) ipv6 support togglable at compile time; if you use the app on ipv4-only system, ipv4 features work 4) ipv6 support detected/configured at runtime I don't consider applications to be integrated properly unless 4) applies. I get the impression you are doing mostly 2). As ipv4 isn't going away any time soon, except in some closed environments like 3G mobile phones, you have to be able to deal with all kinds of situations. As said, I don't think this works yet in real life (consider: OS distributions), and is counter-productive for the spread of IPv6 as distributions cannot ship ipv6 ready apps just in case unless they're 3) or 4) (because that'd hurt the operation of production software). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 09:51:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OGpcdP001848 for ; Sun, 24 Jun 2001 09:51:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OGpc89001847 for ipng-dist; Sun, 24 Jun 2001 09:51:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OGpYdP001840 for ; Sun, 24 Jun 2001 09:51:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15775 for ; Sun, 24 Jun 2001 09:51:42 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06377 for ; Sun, 24 Jun 2001 10:52:33 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5OGpKi49859; Sun, 24 Jun 2001 18:51:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA26958; Sun, 24 Jun 2001 18:51:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5OGpJO81141; Sun, 24 Jun 2001 18:51:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106241651.f5OGpJO81141@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Mauro Tortonesi , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Sun, 24 Jun 2001 17:03:19 +0300. Date: Sun, 24 Jun 2001 18:51:19 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I have the opposite policy so results are different. My target is > integrated systems where IPv6 is *not* optional, no more than IP is! That is a longer term goal. Currently that only works in closed environments. => I disagree about the closed environments, this works everywhere but this is very interesting only in environments where IPv6 is common. >From my viewpoint, the applications wrt. ipv6 support can be split into a few categories: 1) no ipv6 support 2) ipv6 support togglable at compile time; if you use the app on ipv4-only system, it won't even run (or ipv4 features don't work properly) [for example xinetd] 3) ipv6 support togglable at compile time; if you use the app on ipv4-only system, ipv4 features work 4) ipv6 support detected/configured at runtime I don't consider applications to be integrated properly unless 4) applies. => I support 4) only for some applications which are critical in case of a crash (the kind of applications which are statically linked). I get the impression you are doing mostly 2). => more than 2), the IPv6 support is not togglable! As ipv4 isn't going away any time soon, except in some closed environments like 3G mobile phones, you have to be able to deal with all kinds of situations. => as an IPv6 application is IPv4 capable on a RFC 2553 compliant system I don't understand your concern. As said, I don't think this works yet in real life (consider: OS distributions), and is counter-productive for the spread of IPv6 as distributions cannot ship ipv6 ready apps just in case unless they're 3) or 4) (because that'd hurt the operation of production software). => my target is not the same, you want to provide an optional IPv6 support (so 3) or 4) are needed), I want to provide an integrated IPv6 support so the IPv6 support is *not* optional, there is only a possibility to disable it for disaster recovery (because I run the code on the same system I develop it, I don't use the traditional/expensive way with two boxes). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 10:16:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OHGedP001878 for ; Sun, 24 Jun 2001 10:16:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OHGeGd001877 for ipng-dist; Sun, 24 Jun 2001 10:16:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OHGadP001870 for ; Sun, 24 Jun 2001 10:16:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13716 for ; Sun, 24 Jun 2001 10:16:45 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21279 for ; Sun, 24 Jun 2001 11:17:35 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5OHGJr09119; Sun, 24 Jun 2001 20:16:19 +0300 Date: Sun, 24 Jun 2001 20:16:19 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106241651.f5OGpJO81141@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > => I have the opposite policy so results are different. My target is > > integrated systems where IPv6 is *not* optional, no more than IP is! > > That is a longer term goal. Currently that only works in closed > environments. > > => I disagree about the closed environments, this works everywhere but > this is very interesting only in environments where IPv6 is common. These environments aren't that common, and unlikely to get so very soon (speaking from OS perspective). Currently systems are often ipv4 only. One day they just don't magically turn into ipv6 only boxes. Dual stack is the way the world is going towards. > => my target is not the same, you want to provide an optional IPv6 support > (so 3) or 4) are needed), I want to provide an integrated IPv6 support > so the IPv6 support is *not* optional, there is only a possibility to > disable it for disaster recovery (because I run the code on the same > system I develop it, I don't use the traditional/expensive way with > two boxes). Wanna bet your target isn't the most common case? There's no way there's going to be a flag day when people just magically get IPv6 enabled operating systems and never want to disable the support again. The transition process will be long, and API's and implementations will have to cope with the fact. 3G, home gadgets etc. aside where there exists no ipv4 implementation (or no implementation at all), you have like: - Windows - Linux - {Free,Open,Net}BSD - MacOS (=> FreeBSD) I dare say these are at least 99% of potential IPv6 end-user systems. End-users are the ones that will create the critical mass for IPv6, so their needs must be looked after. In corporate environments, you might also have, in addition to above, systems like: - Solaris, Tru64, HP-UX, AIX, etc. *UX - Cisco, etc. router products (if not replaced with e.g. BSD) All of these have existing, _working_ IPv4 network implementation. No one is going to just completely replace ipv4 with ipv6 one nice afternoon. It _will_ be necessary for the vendors to ship applications and code which works in dual-stack configurations, and on systems where people are at different stages in ipv4 -> ipv6 transition. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 11:18:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OIIddP001921 for ; Sun, 24 Jun 2001 11:18:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OIId4s001920 for ipng-dist; Sun, 24 Jun 2001 11:18:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OIIYdP001913 for ; Sun, 24 Jun 2001 11:18:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16210 for ; Sun, 24 Jun 2001 11:18:36 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01127 for ; Sun, 24 Jun 2001 12:18:34 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 1BD917BB; Mon, 25 Jun 2001 03:18:21 +0900 (JST) To: Francis Dupont Cc: Pekka Savola , Mauro Tortonesi , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Sun, 24 Jun 2001 18:51:19 +0200. <200106241651.f5OGpJO81141@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Mon, 25 Jun 2001 03:18:21 +0900 Message-Id: <20010624181821.1BD917BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=> my target is not the same, you want to provide an optional IPv6 support >(so 3) or 4) are needed), I want to provide an integrated IPv6 support >so the IPv6 support is *not* optional, there is only a possibility to >disable it for disaster recovery (because I run the code on the same >system I develop it, I don't use the traditional/expensive way with >two boxes). for this part, people have different requirements depending on their standpoints. for example, for *BSD-integrated KAME systems, it was strict requirement that we can let people happily replace IPv4/v6 dual stack kernel with IPv4-only kernel, without requiring recompilation of userland programs. therefore, we decided we shouldn't use AF_INET6 hardcoded, we should be using getaddrinfo loop instead. {Free,Net,Open}BSD ships compiled kernel binary with IPv6 support by default, which is good. however, there are people who are doing embedded IPv4-only router product and such. if we use AF_INET6 hardcoded into uersland binaries, they will be in trouble. you may still be able to provide AF_INET6 socket layer, without IPv6 code, but it looked too hairy to me. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 11:33:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OIXmdP001940 for ; Sun, 24 Jun 2001 11:33:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OIXmnD001939 for ipng-dist; Sun, 24 Jun 2001 11:33:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OIXidP001932 for ; Sun, 24 Jun 2001 11:33:44 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15408 for ; Sun, 24 Jun 2001 11:33:51 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12619 for ; Sun, 24 Jun 2001 11:33:50 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5OIX4i19159; Sun, 24 Jun 2001 20:33:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA27222; Sun, 24 Jun 2001 20:33:04 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5OIX3O81437; Sun, 24 Jun 2001 20:33:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106241833.f5OIX3O81437@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Mauro Tortonesi , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Sun, 24 Jun 2001 20:16:19 +0300. Date: Sun, 24 Jun 2001 20:33:03 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Currently systems are often ipv4 only. One day they just don't magically turn into ipv6 only boxes. Dual stack is the way the world is going towards. => I can't see where/when I said I'd like to get IPv6 only boxes ASAP? All of these have existing, _working_ IPv4 network implementation. No one is going to just completely replace ipv4 with ipv6 one nice afternoon. => I don't want to replace IPv4 by IPv6 next month, I want to get dual stacks as default ASAP. RFC 2553 is for dual stacks and dual stack is the main transition tool. You can run IPv6 only systems if you want, there is no market for them today and in general they are dual stack systems with IPv4 not configured (which is a bit different than disabled). I have some of them for DSTM demos (a case where the difference is important :-). The question is whether you believe in IPv6 or not: to ship systems with optional IPv6 (i.e. dual stack) support is not a positive answer. Regards Francis.Dupont@enst-bretagne.fr PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP. If you believe in this (stronger than IPv6 itself) then you can really understand the dual stack model (the integrated dual version model). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 11:41:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OIfOdP001957 for ; Sun, 24 Jun 2001 11:41:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OIfNOA001956 for ipng-dist; Sun, 24 Jun 2001 11:41:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OIfKdP001949 for ; Sun, 24 Jun 2001 11:41:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15716 for ; Sun, 24 Jun 2001 11:41:27 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14167 for ; Sun, 24 Jun 2001 11:41:26 -0700 (PDT) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5OIfYN01634; Sun, 24 Jun 2001 11:41:34 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id AAU47942; Sun, 24 Jun 2001 11:41:25 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <2350.993295698@brandenburg.cs.mu.OZ.AU> References: <4.3.2.7.2.20010622141253.0213ddb0@mailhost.iprg.nokia.com> <2350.993295698@brandenburg.cs.mu.OZ.AU> Date: Sun, 24 Jun 2001 11:41:25 -0700 To: Robert Elz From: Steve Deering Subject: Re: Updated Charter and acronym change Cc: Bob Hinden , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:28 PM +0700 6/23/01, Robert Elz wrote: > From: Bob Hinden > | After some thought the chairs and ADs think it would be best to also > | change the working group acronym from IPng to IPv6. > >Why? This seems all gloss, no substance, and a bunch of meaningless >work and disruption for no benefit. The main reason for the name change is to make it easier for people to find the online and meeting information about IPv6. The entry for this working group on the IETF web site's list of WGs currently says "ipngwg IPNG". That's hardly an obvious place to look for IPv6-related information, for anyone who isn't an IETF old-timer. ("IPNG? What's that? Internet Portable Network Graphics? Internet PiNG?") Also, as it is now, one has to give a little history lesson every time one mentions this working group's name. >IPng and IPv6 are the same thing (for the past 7 years, and the next >7 I hope). Whatever one means, so does the other - the focus is identical. IPng was the working term for whatever the IETF was going to choose as the next version of IP, while it was trying to make that determination (remember the temporary IPng Area?). Once a decision was made, the protocol was officially named (and numbered) IPv6 and that's what everyone now calls it, both inside and outside the IETF, apart from a few curmudgeons. >I have no problems with anything of substance in the charter, though I >do find the juxtaposition of the following two paragraphs amusing, to >say the least... > > New work items not listed above require the approval of the working > group and Internet Area directors before they will be taken on by the > working group. > > The working group would welcome contributions on the following topics > (this is not an exhaustive list): > >Which is to say, we can't do anything not listed above, but we want to >do all of the following (none of which was listed above). Weird... No, it's trying to encourage contributions on specific additional topics, but noting that they will be subject to an approval process. "Approval" is one possible outcome of the approval process. Some other possible outcomes are formation of a new working group or IRTF research group, delegation to different existing WG or RG, or simple rejection. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 12:19:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OJJkdP001985 for ; Sun, 24 Jun 2001 12:19:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5OJJkYs001984 for ipng-dist; Sun, 24 Jun 2001 12:19:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5OJJgdP001977 for ; Sun, 24 Jun 2001 12:19:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23519 for ; Sun, 24 Jun 2001 12:19:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20988 for ; Sun, 24 Jun 2001 13:19:41 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5OJJ0n09671; Sun, 24 Jun 2001 22:19:00 +0300 Date: Sun, 24 Jun 2001 22:19:00 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106241833.f5OIX3O81437@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001, Francis Dupont wrote: > In your previous mail you wrote: > > Currently systems are often ipv4 only. One day they just don't magically > turn into ipv6 only boxes. Dual stack is the way the world is going > towards. > > => I can't see where/when I said I'd like to get IPv6 only boxes ASAP? If you port applications to ipv6-only system, it usually implies you might want to actually use them too. If application is ipv6-only, the only way user cannot set the hell on loose is by shipping them in ipv6-only system :-). > All of these have existing, _working_ IPv4 network implementation. No one > is going to just completely replace ipv4 with ipv6 one nice afternoon. > > => I don't want to replace IPv4 by IPv6 next month, I want to get > dual stacks as default ASAP. RFC 2553 is for dual stacks and > dual stack is the main transition tool. On dual stacks, user can usually disable ipv6. Examples of this are Linux or BSD which nowadays ship ipv6-enabled by default. However, some users can turn it off intentionally or unitentionally. As Itojun pointed out, recompiling the user space is not usually an option. So, porting applications so that they can handle both gracefully is the way it should be done for about 5+ next years. IMO, this must be kept in mind when defining the API's. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 19:27:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P2RXdP002311 for ; Sun, 24 Jun 2001 19:27:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P2RXxd002310 for ipng-dist; Sun, 24 Jun 2001 19:27:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P2RTdP002303 for ; Sun, 24 Jun 2001 19:27:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11738 for ; Sun, 24 Jun 2001 19:27:37 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA21752 for ; Sun, 24 Jun 2001 20:27:35 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22274; Sun, 24 Jun 2001 22:27:33 -0400 Date: Sun, 24 Jun 2001 22:27:33 -0400 (EDT) From: Jim Bound To: Lori Napoli Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Compaq implements it the same way. But as one author NO this should not go in the spec. It is implementation defined. The only way to force this is to discuss porting assumptions of the market place. That is at best an art and not a science at this point with IPv6. If someone does not do it this way and they are the only one the market will not use their system. thanks /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Fri, 22 Jun 2001, Lori Napoli wrote: > We have come to the same conclusion that IPV6_V6ONLY should be allowed to > change only if no bind or connect has been called on that socket. Do the > RFC authors agree? If so, can we expect the next draft of this RFC to > have this restriction? > > > Thanks > Lori > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 19:30:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P2UAdP002330 for ; Sun, 24 Jun 2001 19:30:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P2UAcm002329 for ipng-dist; Sun, 24 Jun 2001 19:30:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P2U6dP002320 for ; Sun, 24 Jun 2001 19:30:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA11965 for ; Sun, 24 Jun 2001 19:30:12 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA12826 for ; Sun, 24 Jun 2001 19:30:12 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06217; Sun, 24 Jun 2001 22:29:59 -0400 Date: Sun, 24 Jun 2001 22:29:59 -0400 (EDT) From: Jim Bound To: Jun-ichiro itojun Hagino Cc: horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010622194204.E4E0F7BB@starfruit.itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you want to port in an IPv4 and IPv6 independent manner you will use the tools as currently specified. There is not protocol that will matter besides IPv4 and IPv6 for at least the next 10 years. The debate is not technical but where the future will be. This makes it hard. API folks have debated this the answer is as is specified now. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Sat, 23 Jun 2001, Jun-ichiro itojun Hagino wrote: > >> for example: on linux system, if you would like to turn IPV6_V6ONLY > >> option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. > >If that changes were done, turning IPV6_V6ONLY on would not be frequently d= > >one. > > if you want to see IPv4 traffic on AF_INET socket (so that we don't > get confused by bogus source address, and generating bogus traffic > when responding) you will want to do IPV6_V6ONLY. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 19:42:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P2gudP002413 for ; Sun, 24 Jun 2001 19:42:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P2gufO002412 for ipng-dist; Sun, 24 Jun 2001 19:42:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P2gqdP002405 for ; Sun, 24 Jun 2001 19:42:52 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12509 for ; Sun, 24 Jun 2001 19:43:00 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id TAA26163 for ; Sun, 24 Jun 2001 19:42:59 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02582; Sun, 24 Jun 2001 22:42:31 -0400 Date: Sun, 24 Jun 2001 22:42:30 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hear Say, Hear Say, Unless your going to name sources don't use them in debate. Here is one that does use the RFC 2553 model as ISV. Netscape. Here are a list of vendors that support the merge Francis spoke of with shipping products: Solaris HP-UX IBM AIX Compaq True64 UNIX Compaq OpenVMS for TCP/IP Also Netbsd and FreeBSD uses the model in 2553 since it was defined. What programmers in what organizations are you talking about? thanks /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Sat, 23 Jun 2001, Mauro Tortonesi wrote: > On Sat, 23 Jun 2001, Francis Dupont wrote: > > > => no, there are some codes which are written without switches. > > of course there are. RFC 2553 has been written in order to minimize the > need for those switches. > > > Of course they work only on systems where IPv6 is fully integrated. > > i don't think so. switches are necessary in many cases (especially when > you want the same code to work on a traditional ipv4 system that uses > gethostby{name,addr} and on a new ipv6-compliant system which uses > get{addr,name}info). > > > => I have ported many applications to IPv6 on BSD systems without > > the problems you seemed to have encountered... > > it depends from the application and the policy of the programmer. > i prefer not to modify existing ipv4 code (for compatibility with older > systems), so i generally use A LOT of switches. i also try to be careful > when handling common ipv6/ipv4 cases, and this make my work a little > harder. > > i have seen that many programmers find difficult the process of porting > their apps to ipv6. i think that we should write a small informational > document that explains how to write good ipv6-compliant code. > itojun's "Implementing AF-indipendent apps" is a very good document. > however, it is obsolete and it doesn't give many informations. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 22:24:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P5OXdP002568 for ; Sun, 24 Jun 2001 22:24:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P5OX7S002567 for ipng-dist; Sun, 24 Jun 2001 22:24:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P5OSdP002560 for ; Sun, 24 Jun 2001 22:24:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22893 for ; Sun, 24 Jun 2001 22:24:37 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14932 for ; Sun, 24 Jun 2001 23:25:29 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA14258 for ; Mon, 25 Jun 2001 14:25:33 +0900 (JST) Date: Mon, 25 Jun 2001 14:24:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 24 Jun 2001 22:42:30 -0400 (EDT), >>>>> Jim Bound said: > Here is one that does use the RFC 2553 model as ISV. Netscape. > Here are a list of vendors that support the merge Francis spoke of with > shipping products: > Solaris > HP-UX > IBM AIX > Compaq True64 UNIX > Compaq OpenVMS for TCP/IP > Also Netbsd and FreeBSD uses the model in 2553 since it was defined. Just to make it sure, if you mean "accepting IPv4 packets on an AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable the model by default. ...however, those corrections do not affect the main stream of this discussion. We've fully, fully discussed this (in the apifolks list), and have seen so many different views, and, as a consequence, could not reach consensus on a single unified behavior. Sad to say this, but I don't think we'll be able to force vendors a particular behavior based on a particular view of the model, like "the correct thing is to deprecate IPv4-mapped IPv6 addresses"... So, IMHO, the only feasible thing we can do now is to accept the differences of various implementations, and make a guidance of how to deal with the differences with a minimum effort. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 24 22:37:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P5b5dP002589 for ; Sun, 24 Jun 2001 22:37:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P5b5Jg002588 for ipng-dist; Sun, 24 Jun 2001 22:37:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P5b1dP002581 for ; Sun, 24 Jun 2001 22:37:01 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24699 for ; Sun, 24 Jun 2001 22:37:10 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA27490 for ; Sun, 24 Jun 2001 22:37:04 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id OAA14375 for ; Mon, 25 Jun 2001 14:38:04 +0900 (JST) Date: Mon, 25 Jun 2001 14:37:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010622165125.B10091@tinuviel.compendium.net.ar> References: <20010622194204.E4E0F7BB@starfruit.itojun.org> <20010622165125.B10091@tinuviel.compendium.net.ar> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 22 Jun 2001 16:51:25 -0300, >>>>> horape@tinuviel.compendium.net.ar said: >> >> for example: on linux system, if you would like to turn IPV6_V6ONLY >> >> option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. >> >If that changes were done, turning IPV6_V6ONLY on would not be frequently d= >> >one. >> if you want to see IPv4 traffic on AF_INET socket (so that we don't >> get confused by bogus source address, and generating bogus traffic >> when responding) you will want to do IPV6_V6ONLY. > Yes, maybe a flag telling that the old behaviour should be used would be need > to be added too. Then we'll see unreadable conditionals or ifdef tricks. I'd rather prefer just skipping possible errors against multiple calls of bind(2) for each addrinfo element returned by getaddrinfo(3), as itojun suggested. If we take this approach, though, then we'll need one constraint of getaddrinfo(3); it should return the AF_INET6 wildcard address before the AF_INET one on those stacks that do not allow conflict of an AF_INET6 wildcard socket and an AF_INET one. (Otherwise, the already bound AF_INET socket would reject binding the AF_INET6 one, and we would not receive IPv6 packets.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 02:15:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9FfdP002927 for ; Mon, 25 Jun 2001 02:15:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P9Ffa5002926 for ipng-dist; Mon, 25 Jun 2001 02:15:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9FadP002919 for ; Mon, 25 Jun 2001 02:15:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05364 for ; Mon, 25 Jun 2001 02:15:45 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24101 for ; Mon, 25 Jun 2001 02:15:40 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA15963; Mon, 25 Jun 2001 18:16:17 +0900 (JST) Date: Mon, 25 Jun 2001 18:15:18 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Lori Napoli" Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6_UNICAST_HOPS and IPV6_HOPLIMT In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sun, 10 Jun 2001 15:11:35 -0400, >>>>> "Lori Napoli" said: > I should have been more specific with my question. I agree the ancillary > data will override the setsockopt. I was really asking what happens if an > application does a setsockopt for IPV6_UNICAST_HOPS and IPV6_HOPLIMIT? > Does the IPV6_HOPLIMIT replace the value specified by the IPV6_UNICAST_HOPS > or are they separate values? Sorry, I forgot to reply to this. I believe the spec is ambiguous on this point. Our (KAME's) implementation always prefer IPV6_HOPLIMIT to IPV6_xxCAST_HOPS. So, > Lets say IPV6_UNICAST_HOPS = x, kernel > default = z and IPV6_HOPLIMIT = y. Would 'y' be the hoplimit used for a > unicast send? Yes, in our implementation. > Then suppose the application clears the IPV6_HOPLIMIT value. > Do we fall back to 'x' (the value specified on IPV6_UNICAST_HOPS) or 'z' > (kernel default)? Our implementation should fall back to 'x'. It would be better to make this clear on the next revision of the rfc2292bis draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 02:28:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9SqdP002996 for ; Mon, 25 Jun 2001 02:28:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P9SqLJ002995 for ipng-dist; Mon, 25 Jun 2001 02:28:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9SndP002988 for ; Mon, 25 Jun 2001 02:28:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06094 for ; Mon, 25 Jun 2001 02:28:58 -0700 (PDT) Received: from indica.wipsys.stph.net ([203.197.249.146]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17666 for ; Mon, 25 Jun 2001 03:28:54 -0600 (MDT) Received: from hdcvwall.wipro.com (hdcvwall.wipro.com [192.168.150.24]) by indica.wipsys.stph.net (8.9.3+Sun/8.9.3) with SMTP id OAA02522 for ; Mon, 25 Jun 2001 14:59:59 +0530 (IST) Received: from lbmail.mail.wipro.com ([196.12.37.250]) by vindhya.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GFHBK500.LI3 for ; Mon, 25 Jun 2001 14:56:30 +0530 Received: from 2d102 ([192.168.148.59]) by lbmail.mail.wipro.com (Netscape Messaging Server 4.15) with SMTP id GFHBRA00.GQL; Mon, 25 Jun 2001 15:00:46 +0530 Message-ID: <00b401c0fd58$a424d300$3b94a8c0@wipsys.stph.net> From: "k krishna mohan" To: Cc: "Sarosh Mathew Koshy" Subject: Reg UDP fragementation Date: Mon, 25 Jun 2001 14:54:31 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01C0FD86.BDB3DC20" ------=_NextPart_000_00B1_01C0FD86.BDB3DC20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a doubt regarding the way UDP works in IPv6. It would be of=20 great help if someone could throw some light on it.=20 In IPv6 only the source node and the Destination handle = fragementation of the packet, if required. No routers on the way fragement as was done in = IPv4.=20 I guess, mostly fragementation would be required for TCP packets. My question is/are : Is fragementation done when sending a UDP packet = also and=20 If yes how often does it happen that UDP packet is fragement?. I feel it = would=20 be rare(??).=20 Fragementation makes sense when you are sending a TCP packet because = you know what path the packets will take and you can do a MTU. In UDP , = I believe,=20 there is no definite known path a packet will take. Two UDP packets sent = from the=20 same source node under same conditions might take different paths... = then how=20 can we decide what size a UDP packet should be?? Thanks , K K Mohan =20 ------=_NextPart_000_00B1_01C0FD86.BDB3DC20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
    I have a doubt regarding the way UDP works in = IPv6. It=20 would be of
great help if someone could throw some light on it.
 
    In IPv6 only the source node and the=20 Destination handle fragementation of
the packet, if required. No routers on the way fragement as was = done in=20 IPv4.
I guess, mostly fragementation would be required for TCP = packets.
 
My question is/are : Is fragementation done when sending a UDP = packet=20 also and
If yes how often does it happen that UDP packet is fragement?. I = feel it=20 would
be rare(??).
 
    Fragementation makes sense when you are sending = a TCP=20 packet because
you know what path the packets will take and you can do a MTU. In = UDP , I=20 believe,
there is no definite known path a packet will take. Two UDP packets = sent=20 from the
same source node under same conditions might take different = paths... then=20 how
can we decide what size a UDP packet should be??
 
Thanks ,
K K Mohan
 
   
 
------=_NextPart_000_00B1_01C0FD86.BDB3DC20-- --------------InterScan_NT_MIME_Boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 02:47:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9l0dP003026 for ; Mon, 25 Jun 2001 02:47:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5P9l0Kh003025 for ipng-dist; Mon, 25 Jun 2001 02:47:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5P9kudP003018 for ; Mon, 25 Jun 2001 02:46:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07135 for ; Mon, 25 Jun 2001 02:47:05 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06638 for ; Mon, 25 Jun 2001 03:47:56 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA16086; Mon, 25 Jun 2001 18:32:26 +0900 (JST) Date: Mon, 25 Jun 2001 18:31:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Roy Brabson" Cc: ipng@sunroof.eng.sun.com Subject: Re: getsockopt() for IPV6_HOPLIMIT In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 67 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 19 Jun 2001 09:32:31 -0400, >>>>> "Roy Brabson" said: > I actually went back and read the existing RFC2292 - probably > something I should have done originally - and I think I have > a handle on this. Based on the current RFC and the -02 draft > my interpretation is that: > - IPV6_HOPLIMIT should not be allowed on a getsockopt() or > setsockopt() call, but instead IPV6_RECVHOPLIMIT should be > used. IPV6_HOPLIMIT can still be sent/received as ancillary > ancillary data. > - IPV6_RECVHOPLIMIT should be used on setsockopt() to request > that the IPV6_HOPLIMIT be returned as ancillary data. > Does this sound correct, or am I missing something? I believe getsockopt(IPV6_HOPLIMIT) simply returns the value set by setsockopt(IPV6_HOPLIMIT), or the default value (0 for RFC2292 and -1 for rfc2292bis) if the option has never been set on the corresponding socket. There should be no ambiguity on this point. Going back to your examples (I believe you assume the rfc2292bis behavior in these examples), >>>>> On Wed, 13 Jun 2001 12:24:31 -0400, >>>>> "Roy Brabson" said: > Using setsockopt() calls, I think the behavior would be as follows: > Unicast Hop Limit Multicast Hop Limit > ----------------- ------------------- > default 255 1 > IPV6_HOPLIMIT=100 100 100 > IPV6_MULTICAST_HOPS=5 100 5 > IPV6_UNICAST_HOPS=50 50 5 > IPV6_HOPLIMIT=3 3 3 > The question is, what should be returned for a getsockopt() on > IPV6_HOPLIMIT when the unicast and multicast hop limits are different? > Take the default case for instance. What is the correct value to return > on the getsockopt() call, 255 or 1? It should be -1. > And what should be returned after > setting IPV6_HOPLIMIT to 100 and following it with setting > IPV6_MULTICAST_HOPS to 5, 100 or 5? It should be 100 regardless the existence of the IPV6_MULTICAST_HOPS option. However, > All of this would be *much* simpler if the advanced API only allowed > IPV6_HOPLIMIT to be specified as ancillary data and required the use of > IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and > getsockopt() calls. Unfortunately, that isn't the case as 2292 allows > IPV6_HOPLIMIT to be specified as a sticky option. I tend to agree on this point. If we used a single socket for unicast and multicast packets, and wanted to use a same hoplimit for both, IPV6_HOPLIMIT would be useful, but I don't think it's worth the complexity introduced by the combination of the 3 options. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 03:20:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PAKXdP003072 for ; Mon, 25 Jun 2001 03:20:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PAKXm9003071 for ipng-dist; Mon, 25 Jun 2001 03:20:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PAKTdP003064 for ; Mon, 25 Jun 2001 03:20:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08956 for ; Mon, 25 Jun 2001 03:20:38 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20177 for ; Mon, 25 Jun 2001 04:21:27 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA13603; Mon, 25 Jun 2001 13:18:00 +0300 Date: Mon, 25 Jun 2001 13:18:00 +0300 Message-Id: <200106251018.NAA13603@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: rbrabson@us.ibm.com, ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: getsockopt() for IPV6_HOPLIMIT References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > All of this would be *much* simpler if the advanced API only allowed > > IPV6_HOPLIMIT to be specified as ancillary data and required the use of > > IPV6_UNICAST_HOPS and IPV6_MULTICAST_HOPS for setsockopt() and > > getsockopt() calls. Strongly agree on this. Keep it simple! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:14:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEE7dP003451 for ; Mon, 25 Jun 2001 07:14:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEE7ve003450 for ipng-dist; Mon, 25 Jun 2001 07:14:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEE1dP003436 for ; Mon, 25 Jun 2001 07:14:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02395 for ; Mon, 25 Jun 2001 07:14:10 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15170 for ; Mon, 25 Jun 2001 07:14:08 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.143.208) by smtp2.libero.it (5.5.025) id 3AE981AF00D30E75; Mon, 25 Jun 2001 16:13:59 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 1939228A42; Mon, 25 Jun 2001 15:44:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 13BDF28A35; Mon, 25 Jun 2001 15:44:38 +0200 (CEST) Date: Mon, 25 Jun 2001 15:44:38 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106241312.f5ODCsO80487@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > => no, there are some codes which are written without switches. > > of course there are. RFC 2553 has been written in order to minimize the > need for those switches. > > > Of course they work only on systems where IPv6 is fully integrated. > > i don't think so. > > => but we are sating the same thing. Perhaps we have different meanings > for "integration"? maybe i have not well understood what you've written, or, more probably, i haven't explained myself very well. i was trying to say this: RFC 2553 has been written in order to minimize the need for compile-time switches. however, i don't think that we should focus on that minimization, but instead on the definition of an API extension that can lead to easier porting procedures. as itojun has explained us, IPv4 mapped addresses present us many security problems that the developers will have to handle. unspecified behaviour for bind(2) - read my answer to itojun - will eventually produce platform specific code. RFC2553 does not address these problems. in the long run, this policy will cause many headaches to the developers. so, minimization of the compile time switches is not an absolute (or good-in-itself) target to be reached. the solution for this problems may be reached, IMHO, by making the two socket families AF_INET and AF_INET6 indipendent (orthogonal). > => I have the opposite policy so results are different. My target is > integrated systems where IPv6 is *not* optional, no more than IP is! we have different policies. > i have seen that many programmers find difficult the process of porting > their apps to ipv6. i think that we should write a small informational > document that explains how to write good ipv6-compliant code. > itojun's "Implementing AF-indipendent apps" is a very good document. > however, it is obsolete and it doesn't give many informations. > > => I have done one but it is more than obsolete now. But my target > is not AF-independence, it is IP version independence, even if a true > AF independence (i.e. codes which can work with ISO CLNP) is a plus. why don't you give us the url? it may be interesting. > PS: codes full of switches are at least unreadable... i don't think so. as soon as my patch for oftpd is integrated you'll have one example. for now, refer to USAGI's inetd from netkit-base. i find that the code is quite readable. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:14:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEEKdP003464 for ; Mon, 25 Jun 2001 07:14:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEEKw0003463 for ipng-dist; Mon, 25 Jun 2001 07:14:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEEEdP003456 for ; Mon, 25 Jun 2001 07:14:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02416 for ; Mon, 25 Jun 2001 07:14:21 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15271 for ; Mon, 25 Jun 2001 07:14:19 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.143.208) by smtp3.libero.it (5.5.025) id 3AE9822800D3ABAE; Mon, 25 Jun 2001 16:13:58 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id C2DC628A40; Mon, 25 Jun 2001 15:15:22 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 9B2F828A35; Mon, 25 Jun 2001 15:15:22 +0200 (CEST) Date: Mon, 25 Jun 2001 15:15:22 +0200 (CEST) From: Mauro Tortonesi To: Cc: Francis Dupont , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <10206.993324355@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001 itojun@iijlab.net wrote: > >i have seen that many programmers find difficult the process of porting > >their apps to ipv6. i think that we should write a small informational > >document that explains how to write good ipv6-compliant code. > > we really need to convince random book authors to update their > programming examples, from gethostbyname() to getnameinfo()... how can you expect them do so, when there's so much difference between the behaviour of the various TCP/IPv6 stacks? HoraPe has explained us that on *BSD systems, you can have two different sockets (one for AF_INET and one for AF_INET6) bound on the same port. in this way you can use an af-indipendent programming style. this is not true with linux. you have to use a single AF_INET6 socket and listen on both incoming ipv4 and ipv6 connections. draft-ietf-ipngwg-rfc2553bis-03.txt does not specify a specific behaviour for bind. it's left to the implementors. i'd really like to know the reason for doing so. IMVHO, this is a problem, because it will lead developers to write platform-specific code and technical writers to produce misinformation. IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the correct behaviour for bind(2). i vote for the *BSD one: by having two different sockets binding indipendently one from the other, we can get rid of all the problems given by IPv4-mapped IPv6 address, and have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6 address should not be deprecated, but their use should be unrecommended. this policy would lead to the best result with only minor changes in the draft and in the existing ipv6 implementations. however, it's not so simple. in this way we have two indipendent protocol families AF_INET and AF_INET6 (i would define them orthogonal), so we should modify the behaviour of getaddrinfo. in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol family, in a both ipv4- and ipv6-compliant system, getaddrinfo should return two different results (::1 for ipv6 and 127.0.0.1 for ipv4). moreover, calling getaddrinfo with AF_UNSPEC protocol family should produce a result that's the sum of the results of two getaddrinfo calls (one for AF_INET and one for AF_INET6). getnameinfo does not need to be modified. > >itojun's "Implementing AF-indipendent apps" is a very good document. > >however, it is obsolete and it doesn't give many informations. > > it is a bit dated, but the content should be still valid. > do you have any suggestions for improvements? some code examples would be useful. the paper doesn't explain how to handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example. however, as you have already said, the real problem is that there is not a "Unix Network Programming"-like reference book covering ipv6 socket programming. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:14:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEEVdP003474 for ; Mon, 25 Jun 2001 07:14:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEEVIV003473 for ipng-dist; Mon, 25 Jun 2001 07:14:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEERdP003466 for ; Mon, 25 Jun 2001 07:14:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02450 for ; Mon, 25 Jun 2001 07:14:35 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01947 for ; Mon, 25 Jun 2001 07:14:35 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.143.208) by smtp1.libero.it (5.5.025) id 3AE980E700D65E99; Mon, 25 Jun 2001 16:13:55 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 6549B28A45; Mon, 25 Jun 2001 15:58:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 5F9AC28A35; Mon, 25 Jun 2001 15:58:11 +0200 (CEST) Date: Mon, 25 Jun 2001 15:58:11 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: Francis Dupont , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001, Jim Bound wrote: > What programmers in what organizations are you talking about? i will not name any software here. for you, it will be enough to say that i have seen a lot of not-very-well-ported opensource software. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:14:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEE8dP003454 for ; Mon, 25 Jun 2001 07:14:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEE8um003452 for ipng-dist; Mon, 25 Jun 2001 07:14:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEE3dP003443 for ; Mon, 25 Jun 2001 07:14:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09039 for ; Mon, 25 Jun 2001 07:14:12 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01754 for ; Mon, 25 Jun 2001 07:14:11 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.143.208) by smtp1.libero.it (5.5.025) id 3AE980E700D65EA7; Mon, 25 Jun 2001 16:13:59 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 0893028A43; Mon, 25 Jun 2001 15:50:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 0285E28A35; Mon, 25 Jun 2001 15:50:11 +0200 (CEST) Date: Mon, 25 Jun 2001 15:50:10 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: Pekka Savola , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106241833.f5OIX3O81437@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 24 Jun 2001, Francis Dupont wrote: > PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP. > If you believe in this (stronger than IPv6 itself) then you can really > understand the dual stack model (the integrated dual version model). right. but this is not the real problem. the real problem is if AF_INET6 family should be a catch-all extension of AF_INET or if they should be an unrelated, being AF_INET6 a totally different type of socket from AF_INET. i vote for the second option. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:16:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEG2dP003489 for ; Mon, 25 Jun 2001 07:16:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEG1KP003488 for ipng-dist; Mon, 25 Jun 2001 07:16:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEFudP003481 for ; Mon, 25 Jun 2001 07:15:56 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29532 for ; Mon, 25 Jun 2001 07:15:49 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02603 for ; Mon, 25 Jun 2001 07:15:48 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.143.208) by smtp3.libero.it (5.5.025) id 3AE9822800D3AB94; Mon, 25 Jun 2001 16:13:53 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id B198028A46; Mon, 25 Jun 2001 16:05:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id AB1DE28A35; Mon, 25 Jun 2001 16:05:34 +0200 (CEST) Date: Mon, 25 Jun 2001 16:05:34 +0200 (CEST) From: Mauro Tortonesi To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > ...however, those corrections do not affect the main stream of this > discussion. We've fully, fully discussed this (in the apifolks list), > and have seen so many different views, and, as a consequence, could > not reach consensus on a single unified behavior. Sad to say this, > but I don't think we'll be able to force vendors a particular behavior > based on a particular view of the model, like "the correct thing is to > deprecate IPv4-mapped IPv6 addresses"... then why bothering to write RFC2553? if any ISV can do what he wants it has been only a useless effort. your arguments don't seem to have moche sense to me. rather, the discussion should be re-opened and, as a result, a new proposed standard should be produced. > So, IMHO, the only feasible thing we can do now is to accept the > differences of various implementations, and make a guidance of how to > deal with the differences with a minimum effort. this would be a BIG mistake, IMVHO. it is imperative to produce a standard for BSD socket extensions, or we can forget the word "code portability" for the next 50 years... -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:34:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEYUdP003553 for ; Mon, 25 Jun 2001 07:34:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEYTIw003552 for ipng-dist; Mon, 25 Jun 2001 07:34:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEYPdP003543 for ; Mon, 25 Jun 2001 07:34:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00290 for ; Mon, 25 Jun 2001 07:34:33 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08519 for ; Mon, 25 Jun 2001 08:35:22 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id XAA18128 for ; Mon, 25 Jun 2001 23:35:31 +0900 (JST) Date: Mon, 25 Jun 2001 23:34:29 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: complete the advanced API (rfc2292bis) User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, As an IPv6 stack/application programmer, I'd really like to fix the advanced API. The current situation is really mess, because rfc2292bis does not provide backward compatibility to the old RFC 2292, and some OSes has already shipped with rfc2292bis while some other OSes still keep RFC 2292. I believe we should basically go with rfc2292bis, since it has fixed many issues (bugs, in fact) in the old RFC spec, and some of them are essential for some applications (e.g. the IPV6_USE_MIN_MTU option for DNS servers). The most difficult issue would be the one for extension headers. According to a recent discussion about MIP6 issues, the API should be flexible enough to send/receive extension headers in any order, whereas rfc2292bis basically assumes the recommended order of the headers specified in RFC2460. Since it could be a fundamental change of the API spec, I'm not sure if we can get a consensus so smoothly. Anyways, I'll raise this issue later in a separate thread. Apart from the extension header issue, I'd like to start with the TODO and open issues list in draft-ietf-ipngwg-rfc2292bis-02.txt (which has already expired, but you can still get it at ftp://ftp.kame.net/pub/internet-drafts/) with some comments. If you're intested in this topic, please review them and tell me your opinions. If possible, I'd like to see the next revision of the draft before the next IETF meeting in London. So my question is: does anyone (especially in the authors) try to revise the draft now? If not, and if no one have time to do it for the moment, I'll be a volunteer to edit the text for the next revision. Please let me know your opinions. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp from TODO/Open list in the previous version of the draft: 18. TODO and Open Issues Items left to do: - Add macros for ip6_hdr to access the traffic class and flow label fields. I don't recall the discussion (if any), but I think it's just a naming issue. - Should we remove the 1, 2, 4, 8 byte restriction for inet6_opt_set_val and inet6_opt_get_val? Option values can be any size even though there alignment must be a power of two. Yes, I think so. And, Issue of how natural alignment is defined for sizes that are not a power of two. this can be left as implementors' choice, IMO. - Perhaps we should add a note to point out that robust receivers should verify alignment before calling inet6_opt_get_val(). Or require that inet6_opt_get_val() should check the alignment and fail by returning -1? I believe the draft just note possible unaligned data, and the library implementation itself should be careful about the alignment issue. - Should we change IPV6_USE_MIN_MTU to IPV6_USEMTU taking a uint32_t Should we add IPV6_DONTFRAG option for traceroute?? Through a former discussion, we should just go with the IPV6_USE_MIN_MTU. I'm still not sure about the IPV6_DONTFRAG option. - Add credits for UDP MTU stuff - Move information about mapping from inet6_opt to setsockopt and cmsg. What exactly do these two items mean? - Clarify IPV6_RTHDRDSTOPTS's interaction with IPV6_RTHDR. This would be the most difficult issue. We'll discuss it separately later. - Make the new inet6_opt_set_val() and inet6_opt_get_val() check the length of the data item. It would be just an editorial issue. - Add sending and receiving sections for routing header text just like destination options? This should be a part of difficult issue. - Include sample implementation of inet6_opt_XXX. We (KAME) can contribute our implementation as sample code. - Fix Authors address wrt Rich. It's an editorial issue. (But what is the best "address" for him?) Open issues: - Add ICMP name lookups definitions? Since the standardization has not proceeded, I think we should fix the API without the definition. - Add site-prefixes definitions? Ditto. - Add flow label allocation API as requested in draft-berson-rsvp- ipv6-fl-00.txt? Draft has expired! We now have a separate draft on this issue (draft-itojun-ipv6-flowlabel-api-01.txt). As described in the draft, I think we should fix the advanced API without this "more-advanced" stuff. - Anything special for mobility options? Restrict setting at API? Filter out on receipt? If received what does the home address option contain? IMO, we should fix the API without the restriction and filtering. As for reception of the address, I recall some discussion on this. Someone proposed that the remote address (such as the one returned by recvfrom(2)) should be the home address, and that the care-of address should be in the corresponding home-address option when some RECVDSTOPTS variants are specified. However, I'd rather leave the destination address option as is, and introduce a separate RECVxxx option if we really need to pass the option to the application. - Specify "change" for TCP especially when there are multiple HBH option headers etc. ??? what does "multiple HBH option headers" mean? The IPv6 spec requirs a HBH option header appear only once in a single packet. Is this a typo, and should this be "multiple DST option headers"? In any case, sending/receving extension headers is the most difficult part. We'll discuss this later. - Specify binding to scope-id => implies filtering of addresses with that scope if the address you are bound to is link-local etc. What about conflicts with bound scope-id and sendto/connect scope-id? - Specify order for ifindex selection. Put in separate section. Different cases for sending to link-local (scope_id including nexthop scope_id) and global. Is multicast different? - bind() and sin6_scope_id. Should have been in Basic API. Error checks when bind/sendto sin6_scope_id does not match? These three would depend on the result of the discussion about the semantics of the sin6_scope_id field (i.e. flat 32 vs 4+28 split). We'll think about this issue once the semantics is fixed. - Specify notion of default multicast interface? In Basic API? I don't think we should note it in the advanced API, but do not oppose if someone really wants this. - What about site names and site ids? Need for interfaces to map? Requires that site-prefixes pass name - does name need to use DNS format to handle character sets? I believe we should fix the API without this stuff, since this is a highly advanced issue. - If the home address option passed out in IPV6_RECVDSTOPTS? If so what address value does it contain? As I said above, I'd prefer a separate option if we really need to pass the home address to applications. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 07:35:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEZWdP003570 for ; Mon, 25 Jun 2001 07:35:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PEZV3X003569 for ipng-dist; Mon, 25 Jun 2001 07:35:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PEZQdP003562 for ; Mon, 25 Jun 2001 07:35:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14621 for ; Mon, 25 Jun 2001 07:35:35 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24201 for ; Mon, 25 Jun 2001 08:35:33 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 281C27BB; Mon, 25 Jun 2001 23:35:06 +0900 (JST) To: Mauro Tortonesi Cc: Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com In-reply-to: mauro's message of Mon, 25 Jun 2001 15:15:22 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Mon, 25 Jun 2001 23:35:06 +0900 Message-Id: <20010625143506.281C27BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> we really need to convince random book authors to update their >> programming examples, from gethostbyname() to getnameinfo()... >how can you expect them do so, when there's so much difference between >the behaviour of the various TCP/IPv6 stacks? yes, that is the issue. i was trying to suggest example be using getaddrinfo(3) loop, which should work for the most cases. if OS designers are sane enough to design bind(2) behavior and getaddrinfo(3) behavior with care, getaddrinfo(3) loop has a good chance to work in many cases. we need to document platform differences, of course. for exaplme, for server side, assume that the goal is to accept both IPv4 and IPv6 traffic. - if getaddrinfo(3) returns :: and 0.0.0.0, the code will work for the following cases: bind(2) in any order is permitted, traffic accepted as necessary bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket grabs IPv4 traffic but not for the following case: bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket does not grab IPv4 traffic (seems very broken to me) - if getaddrinfo(3) returns :: only, it will work for the following cases: AF_INET6 socket grabs IPv4 traffic but not for the following cases: AF_INET6 socket does not grab IPv4 traffic (getaddrinfo seems broken to me on this platform) (note to OS imlementers - so getaddrinfo(3) behavior has to be carefully designed consdidering your bind(2) and IPv4 mapped addr behavior!) >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the >correct behaviour for bind(2). i vote for the *BSD one: by having two >different sockets binding indipendently one from the other, we can >get rid of all the problems given by IPv4-mapped IPv6 address, and >have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6 >address should not be deprecated, but their use should be unrecommended. >this policy would lead to the best result with only minor changes in the >draft and in the existing ipv6 implementations. I have been trying SO HARD to suggest it in api discussion group (which is a small group of people who contributed 2553bis-03 updates), but was rejected. it is a holy war where there's no end. one side advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET splitted socket (or at least make the default behavior so). I'm of course in the second camp. in fact, as far as i understand, there's no good standard document on bind(2) interaction between two IPv4 sockets. so defining it for IPv4/v6 interaction would be a big task. >in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol >family, in a both ipv4- and ipv6-compliant system, getaddrinfo should >return two different results (::1 for ipv6 and 127.0.0.1 for ipv4). >moreover, calling getaddrinfo with AF_UNSPEC protocol family should >produce a result that's the sum of the results of two getaddrinfo >calls (one for AF_INET and one for AF_INET6). > >getnameinfo does not need to be modified. it is what i have been believed, but there are people believing in different behavior. >> it is a bit dated, but the content should be still valid. >> do you have any suggestions for improvements? >some code examples would be useful. the paper doesn't explain how to >handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example. aha, I was biased to independent AF_INET/AF_INET6 implementation ;-) as IPV6_V6ONLY support is still rare, not sure if it worth document it. thanks anyways. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 09:26:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PGQKdP003677 for ; Mon, 25 Jun 2001 09:26:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PGQJnM003676 for ipng-dist; Mon, 25 Jun 2001 09:26:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PGQGdP003669 for ; Mon, 25 Jun 2001 09:26:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02902 for ; Mon, 25 Jun 2001 09:26:25 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24636 for ; Mon, 25 Jun 2001 10:27:14 -0600 (MDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id DD856196740; Mon, 25 Jun 2001 13:26:17 -0300 (ART) Date: Mon, 25 Jun 2001 13:26:17 -0300 To: Jim Bound Cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625132617.B20646@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PGQGdP003670 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > If you want to port in an IPv4 and IPv6 independent manner you will use > the tools as currently specified. There is not protocol that will matter > besides IPv4 and IPv6 for at least the next 10 years. 10 years? If we're thinking so short-term something is bad. And if in 10 years there are other protocols we'll be better going full speed to the AF independence. I wasn't thinking myself being involved with future transitions, but maybe my children or grandchildren will (and i'm not even married yet, maybe my grandchildren get old enough to be involved with that in 50 years from now) > The debate is not > technical but where the future will be. This makes it hard. The question is "Will IPv6 work forever?", if the answer is yes, then there is nothing to talk about, if the answer is no (and I think that way) then we should try to help the next transitions to be easier, using what we have learned now. Now we need to port several thousands of applications, in 50 years there will be tens of thousands. If my grandchildren will be there, I'd like they could work with the interesting stuff (designing the protocol, implementing the stacks) and not with the boring, almost mechanical tasks (changing all INET6 for INET10) We cannot think for only 10 years, 10 years is almost the time we've spent by now in the IPv4 -> IPv6 transition, and it is just starting (ok, maybe now things go faster and it will be complete in 5 years more, but yet we're at the start) It's unwise to look so little in the future. > API folks > have debated this the answer is as is specified now. It seems from the discussion that there is not a real consensus, but just a "that's how it is being done, don't change it". For the ones who prefer to just look a few years in the future, I'll say let the IPv4 mapping enabled, but that should be done in a way that doesn't generates problems for the people that prefer to look further. So, while things don't change, there is a problem. And that problem ought to be solved. I've proposed several ways to solve it and allow more choices to the programmers and OS implementors. > /jim HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:09:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PH9OdP003744 for ; Mon, 25 Jun 2001 10:09:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PH9OJN003743 for ipng-dist; Mon, 25 Jun 2001 10:09:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PH9KdP003728 for ; Mon, 25 Jun 2001 10:09:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02994 for ; Mon, 25 Jun 2001 10:09:30 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10475 for ; Mon, 25 Jun 2001 10:09:21 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id E20B719674E; Mon, 25 Jun 2001 14:08:57 -0300 (ART) Date: Mon, 25 Jun 2001 14:08:57 -0300 To: Mauro Tortonesi Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625140857.C26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PH9KdP003733 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > > for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) { > > listenfds[n] = socket(res->ai_family, res->ai_socktype, > > res->ai_protocol); > > if(listenfds[n] < 0) > > continue; /* libc supports protocols that kernel don't */ > > > > if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0) > > die(); > > > > if(listen(listenfds[n], 10) != 0) > > die(); > > n++; > > } > i am afraid i don't understand this portion of code. is getaddrinfo > expected to return one-and-only-one ready-to-be-bound address for > every AF when called with flag AI_PASSIVE set? there's nothing in > the drafts that states this: That's not specified, as far as I can tell. It must return all the sockaddr's to bind to. If with just one sockaddr is enough that could be correct. But it's implemented normally as you described. > The AI_PASSIVE flag in the ai_flags member of the hints structure > specifies how to fill in the IP address portion of the socket address > structure. If the AI_PASSIVE flag is specified, then the returned > address information must be suitable for use in binding a socket for > accepting incoming connections for the specified service (i.e. a call > to bind()). In this case, if the nodename argument is null, then the > IP address portion of the socket address structure will be set to > INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 > address. If the AI_PASSIVE bit is not set, the returned address > information must be suitable for a call to connect( ) (for a > connection-mode protocol) or for a call to connect(), sendto() or > sendmsg( ) (for a connectionless protocol). In this case, if the > nodename argument is null, then the IP address portion of the socket > address structure will be set to the loopback address. This flag is > ignored if the nodename argument is not null. > from what i can guess, instead, the expected behaviour for getaddrinfo in > this case (AI_PASSIVE, AF_UNSPEC and SOCK_STREAM set) is to return a > ready-to-be-bound ::1 (ipv6) address. am i wrong? It should be :: (ANY), not ::1 (loopback) and that could be done that way if all the AFs can be mapped to IPv6, but if there are no mappable protocols it should return the list. > if so, your code (which is truly AF-indipendent) is not RFC2553-compliant. > or better, the API specified by RFC2553 is not AF-indipendent. I don't understand that. > > A comment > > But that's not all. > > Nor the IPv6 centric nor the AF independent way work as cleanly as I > > presented them. The IPv6 centric way dies on OS where the IPv6 support > > is not compiled, so when programming the IPv6 centric way you should > > check if the socket call fails and then fall back to work as a pure > > IPv4 server (ie, duplication of code) > duplication of code is (and - if we're not gonna change the API draft in a > significant way - will always be) inevitable. there are MANY problems in > handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single > AF_INET6 socket, and most of them are related to security. Yes, that's one of the things why I dislike programming for IPv6. > moreover, all the ipv6 compliant code that i have seen until now is full > of preprocessor switches like: > #ifdef INET6 > /* code that handles both ipv6 and ipv4 */ > /* this code is expected to make a heavy use of get{name,addr}info > * and to avoid inet_{ntop,pton} when possible. > */ > #else > /* ipv4-only (traditional) code */ > /* this code is expected to make heavy use of gethostby{name,addr} > * inet_{ntoa,aton} etc... > */ > #endif That shouldn't be that way. If we wanted to handle old systems with no get{name,addr}info support that should be tested by configure (or something like that) and not based on INET6 (BTW, I prefer to write a little wrapper around gethostby*, instead of the #ifdef's) > this is NOT AF-indipendent programming, as you have correctly pointed out. > that's the point. RFC2553 focuses only on ipv6 and ipv4, and its main > purpose is to extend the BSD API in order to make the transition to > ipv6 as painless as possible. > unfortunately, it has completely missed the point. by stating that it's > possible to receive ipv4 traffic with AF_INET6 sockets, RFC2553 has > introduced a BIG number of special cases which the programmers must > handle. Yes, and I want to make that optional, so the special cases are not needed. > programming ipv6-compliant software in the RFC2553-compliant way is > quite a nightmare. if you have some experience in porting apps to ipv6 > under linux (which is, as you state, a RFC2553-compliant OS), you sure > know what i am talking about. Yes, that's what has led me to work on this draft. > > Deprecate IPv4 mapped addresses > > Maybe the time for IPv4 mapped addresses is over, maybe that was a > > good mechanism to get things to start rolling but it's time to grow up > > and left them. > i would be the best thing to do, IMHO. if we wish to achieve true > AF-indipendence, we have to cut all the relationships between different > AF. AF_INET6 sockets shouldn't have any relation with AF_INET sockets. > it should't be possible to receive ipv4 traffic on a AF_INET6 socket. I'd like to do that too, but there is yet too much work done based on that mapping, so it's not reasonable to expect that being possible. > > But, there is too much work done in the IPv6 centric way, so maybe it > > isn't prudent to throw them all at once. > i do not agree here. IPv4 mapped addresses should be deprecated and put in > disuse as soon as possible. I'd like that, but that's just impossible. > > More magic to getaddrinfo > > Take the Linux approach as the good one (it's the only compliant and > > non buggy -again, talking just about the issue on topic, i won't judge > > the general buggyness of any stack here), add a bit more (yet more!) > > of magic to getaddrinfo so it only returns the INET wildcard sockaddr > > when the kernel has no support for IPv6, and then the buggy stacks > > could be corrected with no loss of features and the unworkable one > > would get workable. > i don't understand you here. for a true AF-indipendent programming style, > getaddrinfo should return a ready-to-be-bound address for every AF. > for all those addresses, it should be possible to call bind without any > conflicts. I'm proposing as a (very undesirable) solution that getaddrinfo worked as you explained before. > > Add a provision for double stack implementations > > RFC 2553 targets the dual stack systems, where there is one stack that > > implements both IPv4 and IPv6 protocols. > > If the RFC had a little comment telling that there is allowed to have > > systems with two isolated stacks, and that the IPv4 to IPv6 mapping > > may be absent on these systems, the non compliant implementations > > would become compliant and we would have some implementations > > compliant, non buggy and easy to work with AF-independently. > that's nonsense. compliant stacks would not be AF-independent, but > quasi-compliant stacks would be. I like better the noncompliant systems, but standard compliance is too important to discard it. So I hope to change the standard to accept the actually noncompliant behaviour. HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:12:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHCvdP003761 for ; Mon, 25 Jun 2001 10:12:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHCvN0003760 for ipng-dist; Mon, 25 Jun 2001 10:12:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHCrdP003753 for ; Mon, 25 Jun 2001 10:12:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13889 for ; Mon, 25 Jun 2001 10:13:03 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25823 for ; Mon, 25 Jun 2001 11:13:49 -0600 (MDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 00D8E196743; Mon, 25 Jun 2001 14:12:29 -0300 (ART) Date: Mon, 25 Jun 2001 14:12:29 -0300 To: Francis Dupont Cc: Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625141229.D26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200106231235.f5NCZNO78095@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHCsdP003754 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > duplication of code is (and - if we're not gonna change the API draft in a > significant way - will always be) inevitable. there are MANY problems in > handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single > AF_INET6 socket, and most of them are related to security. > => I disagree. There is *no* security issue with IPv4-mapped addresses > as soon as one doesn't forget them. The problem is that not forgeting them means the same amount of work that doing the port in the AF independent way. So the benefits of the IPv4-mapped addresses (easy porting) get lost. > Francis.Dupont@enst-bretagne.fr HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:19:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHJedP003780 for ; Mon, 25 Jun 2001 10:19:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHJeI9003779 for ipng-dist; Mon, 25 Jun 2001 10:19:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHJadP003772 for ; Mon, 25 Jun 2001 10:19:37 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02727 for ; Mon, 25 Jun 2001 10:19:47 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24215 for ; Mon, 25 Jun 2001 10:19:44 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 4894919674E; Mon, 25 Jun 2001 14:19:09 -0300 (ART) Date: Mon, 25 Jun 2001 14:19:09 -0300 To: Mauro Tortonesi Cc: Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625141908.E26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHJbdP003773 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > i have seen that many programmers find difficult the process of porting > their apps to ipv6. i think that we should write a small informational > document that explains how to write good ipv6-compliant code. > itojun's "Implementing AF-indipendent apps" is a very good document. > however, it is obsolete and it doesn't give many informations. It's not obsolete, but it's too terse. I've started working on a more extense tutorial, but I've been with too much work and never ended it. (and I don't even remember where the draft is) > Mauro Tortonesi mauro@ferrara.linux.it HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:22:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHMFdP003797 for ; Mon, 25 Jun 2001 10:22:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHMF97003796 for ipng-dist; Mon, 25 Jun 2001 10:22:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHMBdP003789 for ; Mon, 25 Jun 2001 10:22:11 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15871 for ; Mon, 25 Jun 2001 10:22:21 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25530 for ; Mon, 25 Jun 2001 10:22:19 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 8A6DB196743; Mon, 25 Jun 2001 14:21:44 -0300 (ART) Date: Mon, 25 Jun 2001 14:21:44 -0300 To: Mauro Tortonesi Cc: itojun@iijlab.net, Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625142144.F26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHMCdP003790 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > however, it's not so simple. in this way we have two indipendent protocol > families AF_INET and AF_INET6 (i would define them orthogonal), so > we should modify the behaviour of getaddrinfo. No change to getaddrinfo is needed. > in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol > family, in a both ipv4- and ipv6-compliant system, getaddrinfo should > return two different results (::1 for ipv6 and 127.0.0.1 for ipv4). > moreover, calling getaddrinfo with AF_UNSPEC protocol family should > produce a result that's the sum of the results of two getaddrinfo > calls (one for AF_INET and one for AF_INET6). That's exactly how getaddrinfo works. HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:39:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHdQdP003894 for ; Mon, 25 Jun 2001 10:39:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHdQUb003893 for ipng-dist; Mon, 25 Jun 2001 10:39:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHdNdP003886 for ; Mon, 25 Jun 2001 10:39:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09825 for ; Mon, 25 Jun 2001 10:39:33 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05958 for ; Mon, 25 Jun 2001 10:39:30 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 5F46019674E; Mon, 25 Jun 2001 14:39:23 -0300 (ART) Date: Mon, 25 Jun 2001 14:39:23 -0300 To: Jun-ichiro itojun Hagino Cc: Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625143923.H26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20010625143506.281C27BB@starfruit.itojun.org> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHdNdP003887 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the > >correct behaviour for bind(2). i vote for the *BSD one: by having two > >different sockets binding indipendently one from the other, we can > >get rid of all the problems given by IPv4-mapped IPv6 address, and > >have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6 > >address should not be deprecated, but their use should be unrecommended. > >this policy would lead to the best result with only minor changes in the > >draft and in the existing ipv6 implementations. > I have been trying SO HARD to suggest it in api discussion group (which > is a small group of people who contributed 2553bis-03 updates), but > was rejected. it is a holy war where there's no end. one side > advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET > splitted socket (or at least make the default behavior so). > I'm of course in the second camp. So, it's a holy war, and no consensus has been achieved. Could we at least allow both styles to work? Right now, that it isn't possible. > in fact, as far as i understand, there's no good standard document > on bind(2) interaction between two IPv4 sockets. so defining it > for IPv4/v6 interaction would be a big task. Maybe we should start writing that document? (although I see working for IPv4 a waste of time and effort) HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:41:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHfcdP003911 for ; Mon, 25 Jun 2001 10:41:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHfcjW003910 for ipng-dist; Mon, 25 Jun 2001 10:41:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHfYdP003903 for ; Mon, 25 Jun 2001 10:41:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19975 for ; Mon, 25 Jun 2001 10:41:44 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29519 for ; Mon, 25 Jun 2001 10:41:37 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id EED5C19675B; Mon, 25 Jun 2001 14:40:47 -0300 (ART) Date: Mon, 25 Jun 2001 14:40:47 -0300 To: Francis Dupont Cc: Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625144047.I26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200106241312.f5ODCsO80487@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHfYdP003904 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > i have seen that many programmers find difficult the process of porting > their apps to ipv6. i think that we should write a small informational > document that explains how to write good ipv6-compliant code. > itojun's "Implementing AF-indipendent apps" is a very good document. > however, it is obsolete and it doesn't give many informations. > => I have done one but it is more than obsolete now. But my target > is not AF-independence, it is IP version independence, even if a true > AF independence (i.e. codes which can work with ISO CLNP) is a plus. When we get IPv10, will you prefer to change all your INET6 for INET10, or just let the AF independent code do that by itself? > Regards > Francis.Dupont@enst-bretagne.fr HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:45:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHjCdP003931 for ; Mon, 25 Jun 2001 10:45:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHjCio003930 for ipng-dist; Mon, 25 Jun 2001 10:45:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHj9dP003923 for ; Mon, 25 Jun 2001 10:45:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10859 for ; Mon, 25 Jun 2001 10:45:19 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01613 for ; Mon, 25 Jun 2001 10:45:12 -0700 (PDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 6537B19674E; Mon, 25 Jun 2001 14:45:04 -0300 (ART) Date: Mon, 25 Jun 2001 14:45:04 -0300 To: Francis Dupont Cc: Pekka Savola , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625144504.J26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200106241833.f5OIX3O81437@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHj9dP003924 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > All of these have existing, _working_ IPv4 network implementation. No one > is going to just completely replace ipv4 with ipv6 one nice afternoon. > > => I don't want to replace IPv4 by IPv6 next month, I want to get > dual stacks as default ASAP. RFC 2553 is for dual stacks and > dual stack is the main transition tool. > You can run IPv6 only systems if you want, there is no market for them > today and in general they are dual stack systems with IPv4 not configured > (which is a bit different than disabled). I have some of them for DSTM > demos (a case where the difference is important :-). > The question is whether you believe in IPv6 or not: to ship systems > with optional IPv6 (i.e. dual stack) support is not a positive answer. The problem is that IPv6 support will be optional for a long time, so crossing that as not an option is not going to work. > Regards > Francis.Dupont@enst-bretagne.fr > PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP. > If you believe in this (stronger than IPv6 itself) then you can really > understand the dual stack model (the integrated dual version model). I won't enter into that discussion... HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:47:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHlodP003953 for ; Mon, 25 Jun 2001 10:47:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHln2I003952 for ipng-dist; Mon, 25 Jun 2001 10:47:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHlkdP003945 for ; Mon, 25 Jun 2001 10:47:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11724 for ; Mon, 25 Jun 2001 10:47:56 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09491 for ; Mon, 25 Jun 2001 11:47:53 -0600 (MDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 20C2719674E; Mon, 25 Jun 2001 14:47:49 -0300 (ART) Date: Mon, 25 Jun 2001 14:47:49 -0300 To: Francis Dupont Cc: Pekka Savola , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625144749.K26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200106241651.f5OGpJO81141@givry.rennes.enst-bretagne.fr> User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PHlkdP003946 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > I get the impression you are doing mostly 2). > => more than 2), the IPv6 support is not togglable! In the "real world" you cannot say that. People will want to disable IPv6 for a long time. > As said, I don't think this works yet in real life (consider: OS > distributions), and is counter-productive for the spread of IPv6 as > distributions cannot ship ipv6 ready apps just in case unless they're 3) > or 4) (because that'd hurt the operation of production software). > => my target is not the same, you want to provide an optional IPv6 support > (so 3) or 4) are needed), I want to provide an integrated IPv6 support > so the IPv6 support is *not* optional, there is only a possibility to > disable it for disaster recovery (because I run the code on the same > system I develop it, I don't use the traditional/expensive way with > two boxes). The same. > Francis.Dupont@enst-bretagne.fr HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 10:59:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHxidP004034 for ; Mon, 25 Jun 2001 10:59:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PHxiPL004033 for ipng-dist; Mon, 25 Jun 2001 10:59:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PHxddP004026 for ; Mon, 25 Jun 2001 10:59:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12713 for ; Mon, 25 Jun 2001 10:59:48 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26164 for ; Mon, 25 Jun 2001 12:00:41 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA19667 for ; Tue, 26 Jun 2001 03:00:46 +0900 (JST) Date: Tue, 26 Jun 2001 02:59:44 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 48 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 25 Jun 2001 16:05:34 +0200 (CEST), >>>>> Mauro Tortonesi said: >> ...however, those corrections do not affect the main stream of this >> discussion. We've fully, fully discussed this (in the apifolks list), >> and have seen so many different views, and, as a consequence, could >> not reach consensus on a single unified behavior. Sad to say this, >> but I don't think we'll be able to force vendors a particular behavior >> based on a particular view of the model, like "the correct thing is to >> deprecate IPv4-mapped IPv6 addresses"... > then why bothering to write RFC2553? if any ISV can do what he wants it > has been only a useless effort. > your arguments don't seem to have moche sense to me. rather, the > discussion should be re-opened and, as a result, a new proposed > standard should be produced. I admit I'm too pessimistic. I of course agree that it would be great if we could get a consensus on a single behavior by the reopened discussion. However, I would just like to point out that all the discussion so far has already been raised, and the fact was that those argument could not convince the people who have other opinions. Itojun's bugtraq report is a good summary, but it still basically was in the past discussion, which, again, could not convince everyone. Yes, I admit that the fact we once failed on something does not mean we'll fail in the future. If you have a good enough point to make a unified consensus, it would be really great. >> So, IMHO, the only feasible thing we can do now is to accept the >> differences of various implementations, and make a guidance of how to >> deal with the differences with a minimum effort. > this would be a BIG mistake, IMVHO. it is imperative to produce > a standard for BSD socket extensions, or we can forget the word > "code portability" for the next 50 years... Agreed, but that's the reality, unfortunately, as far as I understand the issue. Sorry for the negative opinions. I do not intend to discourage people aiming to an ideal goal. I'll be silent on this particular topic... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 11:01:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PI1HdP004053 for ; Mon, 25 Jun 2001 11:01:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5PI1GUo004052 for ipng-dist; Mon, 25 Jun 2001 11:01:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PI1CdP004045 for ; Mon, 25 Jun 2001 11:01:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25351 for ; Mon, 25 Jun 2001 11:01:21 -0700 (PDT) From: horape@tinuviel.compendium.net.ar Received: from tinuviel.compendium.net.ar (usat2-00222.usateleport.com [208.248.183.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27398 for ; Mon, 25 Jun 2001 12:02:12 -0600 (MDT) Received: by tinuviel.compendium.net.ar (Postfix, from userid 1000) id 5DA7919672C; Mon, 25 Jun 2001 15:01:00 -0300 (ART) Date: Mon, 25 Jun 2001 15:01:00 -0300 To: Jim Bound Cc: Lori Napoli , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010625150100.N26062@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.18i x-attribution: HoraPe Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5PI1DdP004046 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ¡Hola! > Compaq implements it the same way. > But as one author NO this should not go in the spec. It is implementation > defined. The only way to force this is to discuss porting assumptions of > the market place. That is at best an art and not a science at this point > with IPv6. If someone does not do it this way and they are the only one > the market will not use their system. We should convert the art into science, and so the spec should be clear. As in telling when is allowed to change IPV6_V6ONLY value, or specifying what should happen if it is changed after bind/connect. Main problem with RFC2553 is that it is too ambiguous. Different implementations of the same standard are a Bad Thing, and vague standards are so a Bad Thing too. RFC 2553 should be made clearer, not vaguer. > /jim HoraPe --- Horacio J. Peña horape@compendium.com.ar horape@uninet.edu bofh@puntoar.net.ar horape@hcdn.gov.ar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:00:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q30kdP006858 for ; Mon, 25 Jun 2001 20:00:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q30kxv006857 for ipng-dist; Mon, 25 Jun 2001 20:00:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q30gdP006850 for ; Mon, 25 Jun 2001 20:00:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25071 for ; Mon, 25 Jun 2001 20:00:52 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA20996 for ; Mon, 25 Jun 2001 21:01:46 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02560; Mon, 25 Jun 2001 23:00:33 -0400 Date: Mon, 25 Jun 2001 23:00:32 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And I have seen a lot of well written code that uses the API as is and testing in various research centers. We cannot change the base api for IPv6 every six months because new programmers want new features. what we need to do is take what we have now and see what IEEE did with the latest rev they are working on and be done with the base api. then new programmers can add new thingees to it tomorrow. As far as being able to accept v4mapped on AF_INET6 is supported by Solaris as I said. This is the view of tomorrow by most server vendors. It is the default. If one don't like it set the option to v6only and no v4mapped will go over AF_INET6 in any manner. Thats the plan. thanks /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, Mauro Tortonesi wrote: > On Sun, 24 Jun 2001, Jim Bound wrote: > > > What programmers in what organizations are you talking about? > > i will not name any software here. for you, it will be enough to say > that i have seen a lot of not-very-well-ported opensource software. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:03:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q33ZdP006877 for ; Mon, 25 Jun 2001 20:03:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q33Zqc006876 for ipng-dist; Mon, 25 Jun 2001 20:03:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q33VdP006869 for ; Mon, 25 Jun 2001 20:03:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00192 for ; Mon, 25 Jun 2001 20:03:41 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA15553 for ; Mon, 25 Jun 2001 21:03:36 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA00748; Mon, 25 Jun 2001 23:03:13 -0400 Date: Mon, 25 Jun 2001 23:03:13 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Francis Dupont , Pekka Savola , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk AF_INET6 will always permit the catch only model because its been a method for over 6 years and customers have ported to that model. We are not getting rid of it now. That is not going to happen. The market has spoken and the early adopter deployment customers will not have their code broken. As far as the default it is you will get v4mapped on AF_INET6 unless you set v6only sockopt. It is done it is written. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, Mauro Tortonesi wrote: > On Sun, 24 Jun 2001, Francis Dupont wrote: > > > PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP. > > If you believe in this (stronger than IPv6 itself) then you can really > > understand the dual stack model (the integrated dual version model). > > right. but this is not the real problem. the real problem is if > AF_INET6 family should be a catch-all extension of AF_INET or if > they should be an unrelated, being AF_INET6 a totally different type of > socket from AF_INET. > > i vote for the second option. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:06:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q36HdP006912 for ; Mon, 25 Jun 2001 20:06:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q36GRi006911 for ipng-dist; Mon, 25 Jun 2001 20:06:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q36DdP006904 for ; Mon, 25 Jun 2001 20:06:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06897 for ; Mon, 25 Jun 2001 20:06:22 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA25077 for ; Mon, 25 Jun 2001 21:07:15 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA02496; Mon, 25 Jun 2001 23:06:08 -0400 Date: Mon, 25 Jun 2001 23:06:08 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This api is not going to standards track it is in informational RFC ONLY. The real standard for the API will be done by the IEEE 1003 committee and we are trying to get them to work with the IETF experts here. They have adopted 2553-bis-03.txt style. Its a done deal. What is open for discussion is the 4+28 split for the sin6_scopeid /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, Mauro Tortonesi wrote: > On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > > ...however, those corrections do not affect the main stream of this > > discussion. We've fully, fully discussed this (in the apifolks list), > > and have seen so many different views, and, as a consequence, could > > not reach consensus on a single unified behavior. Sad to say this, > > but I don't think we'll be able to force vendors a particular behavior > > based on a particular view of the model, like "the correct thing is to > > deprecate IPv4-mapped IPv6 addresses"... > > then why bothering to write RFC2553? if any ISV can do what he wants it > has been only a useless effort. > > your arguments don't seem to have moche sense to me. rather, the > discussion should be re-opened and, as a result, a new proposed > standard should be produced. > > > So, IMHO, the only feasible thing we can do now is to accept the > > differences of various implementations, and make a guidance of how to > > deal with the differences with a minimum effort. > > this would be a BIG mistake, IMVHO. it is imperative to produce > a standard for BSD socket extensions, or we can forget the word > "code portability" for the next 50 years... > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:19:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3JsdP006975 for ; Mon, 25 Jun 2001 20:19:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3Jrud006974 for ipng-dist; Mon, 25 Jun 2001 20:19:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3JodP006967 for ; Mon, 25 Jun 2001 20:19:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA27271 for ; Mon, 25 Jun 2001 20:19:59 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA05904 for ; Mon, 25 Jun 2001 21:20:51 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04813; Mon, 25 Jun 2001 23:19:42 -0400 Date: Mon, 25 Jun 2001 23:19:42 -0400 (EDT) From: Jim Bound To: Jun-ichiro itojun Hagino Cc: Mauro Tortonesi , Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625143506.281C27BB@starfruit.itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we do not document product platform differences in the IETF. but here is how the market will work. the market picks a market leader. today that market leader for most of IP stuff for "Servers" is Sun Microsystems (not all but most if you look at market share). For the client its Microsoft. If Microsoft uses v6only as default and does not adhere to 2553 most likely thats the way all client apps will code. If Sun uses v6only as default the same. The rest of us are debating academics here and the majority of folks believe the model we have is correct. Those viewing the purist API model of Address Family independence believe IPv4 and IPv6 are separate protocols. I for one think that is not true and an error in their model. IPv6 is an extension to IPv4. Hence IPv6 AF should be able to deal with IPv4 notation of IPv6 which is v4mapped. Some others believe we have to worry about yet another real new protocol such as OSI in the past. I think that is nonsense for at least 10 years. In Internet time 10 years will change so many things the API is the least of our worries as Internet engineers IMO. The other problem is some have built a complete dual stack IPv4 and IPv6. If this was done it was a poor design and coding effort or a hack job to get it done quick. They are dead meat with the variant issues such as crossover in kernel code base suppoting two stacks, code bloat, and all the things an experienced (at least 10 years of programming) OS network kernel engineer would not do. These are just broken and the market will force them to fix it. All we ever ask for in any specs in this area is a dual IP layer. We should wrap up the 4+28 split merge the text with what IEEE 1003 has done (which is going to be a lot of work for us authors fyi) and ship this spec to the market. It is in all our interests if we stop this now. We are at a stalemate and stalemate means prior art wins IMO and that prior art is what the Base API spec has preached and delivered for 6 years. Otherwise we will have a shism here and if you think its bad now imagine how bad it will be if the UNIX vendors go one way, Microsoft goes another way, and the public domain stuff goes another way. Just use 2553-bis-03 and be done with it. Anyone who can't make it work please send the code that won't work and I will bet those who support 2553-bis-03 will show you how it works. But if its just a matter of style then thats another issue. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001, Jun-ichiro itojun Hagino wrote: > >> we really need to convince random book authors to update their > >> programming examples, from gethostbyname() to getnameinfo()... > >how can you expect them do so, when there's so much difference between > >the behaviour of the various TCP/IPv6 stacks? > > yes, that is the issue. i was trying to suggest example be using > getaddrinfo(3) loop, which should work for the most cases. > if OS designers are sane enough to design bind(2) behavior and > getaddrinfo(3) behavior with care, getaddrinfo(3) loop has a good > chance to work in many cases. > we need to document platform differences, of course. > > for exaplme, for server side, assume that the goal is to accept both > IPv4 and IPv6 traffic. > - if getaddrinfo(3) returns :: and 0.0.0.0, the code will work > for the following cases: > bind(2) in any order is permitted, traffic accepted as > necessary > bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket > grabs IPv4 traffic > but not for the following case: > bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket > does not grab IPv4 traffic (seems very broken to me) > - if getaddrinfo(3) returns :: only, it will work for the following > cases: > AF_INET6 socket grabs IPv4 traffic > but not for the following cases: > AF_INET6 socket does not grab IPv4 traffic (getaddrinfo seems > broken to me on this platform) > > (note to OS imlementers - so getaddrinfo(3) behavior has to be > carefully designed consdidering your bind(2) and IPv4 mapped addr > behavior!) > > >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the > >correct behaviour for bind(2). i vote for the *BSD one: by having two > >different sockets binding indipendently one from the other, we can > >get rid of all the problems given by IPv4-mapped IPv6 address, and > >have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6 > >address should not be deprecated, but their use should be unrecommended. > >this policy would lead to the best result with only minor changes in the > >draft and in the existing ipv6 implementations. > > I have been trying SO HARD to suggest it in api discussion group (which > is a small group of people who contributed 2553bis-03 updates), but > was rejected. it is a holy war where there's no end. one side > advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET > splitted socket (or at least make the default behavior so). > I'm of course in the second camp. > > in fact, as far as i understand, there's no good standard document > on bind(2) interaction between two IPv4 sockets. so defining it > for IPv4/v6 interaction would be a big task. > > >in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol > >family, in a both ipv4- and ipv6-compliant system, getaddrinfo should > >return two different results (::1 for ipv6 and 127.0.0.1 for ipv4). > >moreover, calling getaddrinfo with AF_UNSPEC protocol family should > >produce a result that's the sum of the results of two getaddrinfo > >calls (one for AF_INET and one for AF_INET6). > > > >getnameinfo does not need to be modified. > > it is what i have been believed, but there are people believing in > different behavior. > > >> it is a bit dated, but the content should be still valid. > >> do you have any suggestions for improvements? > >some code examples would be useful. the paper doesn't explain how to > >handle IPv4-mapped IPv6 address and the IPV6_ONLY option, for example. > > aha, I was biased to independent AF_INET/AF_INET6 implementation ;-) > as IPV6_V6ONLY support is still rare, not sure if it worth document it. > thanks anyways. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:25:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3PodP007013 for ; Mon, 25 Jun 2001 20:25:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3Pn0A007012 for ipng-dist; Mon, 25 Jun 2001 20:25:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3PkdP007005 for ; Mon, 25 Jun 2001 20:25:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01856 for ; Mon, 25 Jun 2001 20:25:55 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA17308 for ; Mon, 25 Jun 2001 20:25:54 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB01044; Mon, 25 Jun 2001 23:25:47 -0400 Date: Mon, 25 Jun 2001 23:25:47 -0400 (EDT) From: Jim Bound To: horape@tinuviel.compendium.net.ar Cc: Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625132617.B20646@tinuviel.compendium.net.ar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q3PkdP007006 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk With all due respect I don't care about peoples grandchildren. I have been doing this for 25 years. 10 years is tops anything lasts of this nature. So I don't care about after 10 years. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > If you want to port in an IPv4 and IPv6 independent manner you will use > > the tools as currently specified. There is not protocol that will matter > > besides IPv4 and IPv6 for at least the next 10 years. > > 10 years? If we're thinking so short-term something is bad. And if in 10 > years there are other protocols we'll be better going full speed to the > AF independence. > > I wasn't thinking myself being involved with future transitions, but > maybe my children or grandchildren will (and i'm not even married yet, > maybe my grandchildren get old enough to be involved with that in 50 > years from now) > > > The debate is not > > technical but where the future will be. This makes it hard. > > The question is "Will IPv6 work forever?", if the answer is yes, then there > is nothing to talk about, if the answer is no (and I think that way) then > we should try to help the next transitions to be easier, using what we have > learned now. > > Now we need to port several thousands of applications, in 50 years there will > be tens of thousands. If my grandchildren will be there, I'd like they could > work with the interesting stuff (designing the protocol, implementing the > stacks) and not with the boring, almost mechanical tasks (changing all INET6 > for INET10) > > We cannot think for only 10 years, 10 years is almost the time we've spent by now > in the IPv4 -> IPv6 transition, and it is just starting (ok, maybe now things > go faster and it will be complete in 5 years more, but yet we're at the start) > It's unwise to look so little in the future. > > > API folks > > have debated this the answer is as is specified now. > > It seems from the discussion that there is not a real consensus, but just a > "that's how it is being done, don't change it". > > For the ones who prefer to just look a few years in the future, I'll say let > the IPv4 mapping enabled, but that should be done in a way that doesn't > generates problems for the people that prefer to look further. > > So, while things don't change, there is a problem. And that problem ought to > be solved. I've proposed several ways to solve it and allow more choices to > the programmers and OS implementors. > > > /jim > > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:33:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3XqdP007047 for ; Mon, 25 Jun 2001 20:33:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3XqI7007046 for ipng-dist; Mon, 25 Jun 2001 20:33:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3XndP007039 for ; Mon, 25 Jun 2001 20:33:49 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02512 for ; Mon, 25 Jun 2001 20:33:59 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA21070 for ; Mon, 25 Jun 2001 20:33:58 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25975; Mon, 25 Jun 2001 23:33:45 -0400 Date: Mon, 25 Jun 2001 23:33:45 -0400 (EDT) From: Jim Bound To: horape@tinuviel.compendium.net.ar Cc: Francis Dupont , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625141229.D26062@tinuviel.compendium.net.ar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q3XndP007040 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk mapped addreses permit very large ISVs to treat all addresses as IPv6 and one code AF. IPv6. And large ISVs tell their suppliers what they want not the other way around. So if database vendor X (who causes customers to use computers for their business) tells sun, compaq, ibm, and hp and others I want you to do it this way. We will. v4mapped permits them to write their app to v6 once and only once. And most ISVs don't care about 10 years from now. They care about the $$$$$$ they will make this year and next year and maybe the next 2 years. And the most efficient cost of doing business engineering way to do that. And that is doing as the style suggests in 2553-bus-03. Now who did we build the api for (we being ipng and IEEE participants) 1. The goodness and social responsibility of man kind on planet earth. No. 2. For the computer science purist. No. 3. For the API purist maybe. No. 4. For someones grandchildren. No. 5. For people that built certain types of stacks. No. 6. For ISVs who want the most efficient API possible to support ipv4 and ipv6 and permit the eventual phase out of IPv4. Yes. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > duplication of code is (and - if we're not gonna change the API draft in a > > significant way - will always be) inevitable. there are MANY problems in > > handling both ipv6 and ipv4 (or better, ipv4-mapped) traffic with a single > > AF_INET6 socket, and most of them are related to security. > > > => I disagree. There is *no* security issue with IPv4-mapped addresses > > as soon as one doesn't forget them. > > The problem is that not forgeting them means the same amount of work that doing > the port in the AF independent way. So the benefits of the IPv4-mapped addresses > (easy porting) get lost. > > > Francis.Dupont@enst-bretagne.fr > > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:36:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3avdP007067 for ; Mon, 25 Jun 2001 20:36:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3auF5007066 for ipng-dist; Mon, 25 Jun 2001 20:36:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3ardP007059 for ; Mon, 25 Jun 2001 20:36:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA08918 for ; Mon, 25 Jun 2001 20:37:03 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA00348 for ; Mon, 25 Jun 2001 20:37:02 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA06104; Mon, 25 Jun 2001 23:36:47 -0400 Date: Mon, 25 Jun 2001 23:36:47 -0400 (EDT) From: Jim Bound To: horape@tinuviel.compendium.net.ar Cc: Lori Napoli , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625150100.N26062@tinuviel.compendium.net.ar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q3ardP007060 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Clarity is mandatory. What text exactly is not clear? thanks /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > Compaq implements it the same way. > > > But as one author NO this should not go in the spec. It is implementation > > defined. The only way to force this is to discuss porting assumptions of > > the market place. That is at best an art and not a science at this point > > with IPv6. If someone does not do it this way and they are the only one > > the market will not use their system. > > We should convert the art into science, and so the spec should be clear. As > in telling when is allowed to change IPV6_V6ONLY value, or specifying what > should happen if it is changed after bind/connect. > > Main problem with RFC2553 is that it is too ambiguous. Different > implementations of the same standard are a Bad Thing, and vague standards > are so a Bad Thing too. RFC 2553 should be made clearer, not vaguer. > > > /jim > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:44:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3i5dP007093 for ; Mon, 25 Jun 2001 20:44:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3i5BO007092 for ipng-dist; Mon, 25 Jun 2001 20:44:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3i1dP007085 for ; Mon, 25 Jun 2001 20:44:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03414 for ; Mon, 25 Jun 2001 20:44:11 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA03310 for ; Mon, 25 Jun 2001 20:44:10 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01339; Mon, 25 Jun 2001 23:43:43 -0400 Date: Mon, 25 Jun 2001 23:43:43 -0400 (EDT) From: Jim Bound To: horape@tinuviel.compendium.net.ar Cc: Francis Dupont , Pekka Savola , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625144504.J26062@tinuviel.compendium.net.ar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q3i1dP007086 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 is not optional for 3GGP and I hope soon 3GGP2 and that is both sides of the wireless coin requiring initial steps to IPv6. If any vendor don't have IPv6 running in their products this year they will not be permitted to bid on a large business opportunities. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > All of these have existing, _working_ IPv4 network implementation. No one > > is going to just completely replace ipv4 with ipv6 one nice afternoon. > > > > => I don't want to replace IPv4 by IPv6 next month, I want to get > > dual stacks as default ASAP. RFC 2553 is for dual stacks and > > dual stack is the main transition tool. > > You can run IPv6 only systems if you want, there is no market for them > > today and in general they are dual stack systems with IPv4 not configured > > (which is a bit different than disabled). I have some of them for DSTM > > demos (a case where the difference is important :-). > > The question is whether you believe in IPv6 or not: to ship systems > > with optional IPv6 (i.e. dual stack) support is not a positive answer. > > The problem is that IPv6 support will be optional for a long time, so > crossing that as not an option is not going to work. > > > Regards > > Francis.Dupont@enst-bretagne.fr > > > PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP. > > If you believe in this (stronger than IPv6 itself) then you can really > > understand the dual stack model (the integrated dual version model). > > I won't enter into that discussion... > > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:47:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3lQdP007118 for ; Mon, 25 Jun 2001 20:47:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3lQ9P007117 for ipng-dist; Mon, 25 Jun 2001 20:47:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3lNdP007110 for ; Mon, 25 Jun 2001 20:47:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29303 for ; Mon, 25 Jun 2001 20:47:32 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA04675 for ; Mon, 25 Jun 2001 20:47:31 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04942; Mon, 25 Jun 2001 23:47:19 -0400 Date: Mon, 25 Jun 2001 23:47:19 -0400 (EDT) From: Jim Bound To: horape@tinuviel.compendium.net.ar Cc: Jun-ichiro itojun Hagino , Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625143923.H26062@tinuviel.compendium.net.ar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q3lNdP007111 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we did suggest that there be no default for v6only (in fact I suggested it) and no one on either side wanted that. thinking was even if one did not get their choice then its better to have default for the users. also this is not a holy war. that was a mis-characterization. in fact it was about 6 to 3 ratio in favor of v6only not being the default. or if there were 9 people only 3 wanted what you want. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the > > >correct behaviour for bind(2). i vote for the *BSD one: by having two > > >different sockets binding indipendently one from the other, we can > > >get rid of all the problems given by IPv4-mapped IPv6 address, and > > >have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6 > > >address should not be deprecated, but their use should be unrecommended. > > >this policy would lead to the best result with only minor changes in the > > >draft and in the existing ipv6 implementations. > > > I have been trying SO HARD to suggest it in api discussion group (which > > is a small group of people who contributed 2553bis-03 updates), but > > was rejected. it is a holy war where there's no end. one side > > advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET > > splitted socket (or at least make the default behavior so). > > I'm of course in the second camp. > > So, it's a holy war, and no consensus has been achieved. Could we at least > allow both styles to work? Right now, that it isn't possible. > > > in fact, as far as i understand, there's no good standard document > > on bind(2) interaction between two IPv4 sockets. so defining it > > for IPv4/v6 interaction would be a big task. > > Maybe we should start writing that document? (although I see working for IPv4 > a waste of time and effort) > > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 20:51:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3pLdP007144 for ; Mon, 25 Jun 2001 20:51:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q3pLB3007143 for ipng-dist; Mon, 25 Jun 2001 20:51:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q3pGdP007136 for ; Mon, 25 Jun 2001 20:51:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29488 for ; Mon, 25 Jun 2001 20:51:26 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA01092 for ; Mon, 25 Jun 2001 21:52:18 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D6DFD7BB; Tue, 26 Jun 2001 12:50:34 +0900 (JST) To: Jim Bound Cc: horape@tinuviel.compendium.net.ar, Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Mon, 25 Jun 2001 23:47:19 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 12:50:34 +0900 Message-Id: <20010626035034.D6DFD7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >we did suggest that there be no default for v6only (in fact I suggested >it) and no one on either side wanted that. thinking was even if one did >not get their choice then its better to have default for the users. sorry to be picky. is it correct that "no one on either side wanted that"? Dave Thaler and i preferred "no default" at some point. >in fact it was about 6 to 3 ratio in favor of v6only not being the >default. or if there were 9 people only 3 wanted what you want. at least the sentence conflict with the above "no one". itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 21:01:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q419dP007182 for ; Mon, 25 Jun 2001 21:01:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q419cN007181 for ipng-dist; Mon, 25 Jun 2001 21:01:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q415dP007174 for ; Mon, 25 Jun 2001 21:01:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA29693 for ; Mon, 25 Jun 2001 21:01:16 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA03024 for ; Mon, 25 Jun 2001 21:01:15 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04001; Tue, 26 Jun 2001 00:00:35 -0400 Date: Tue, 26 Jun 2001 00:00:35 -0400 (EDT) From: Jim Bound To: horape@tinuviel.compendium.net.ar Cc: Francis Dupont , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625144047.I26062@tinuviel.compendium.net.ar> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q416dP007175 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I know the ip stack inside and out. if we have to go to IPv10 it will be a new IP layer protocol and by definition a completely new AF type. This is not the case for IPv4 and IPv6. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > i have seen that many programmers find difficult the process of porting > > their apps to ipv6. i think that we should write a small informational > > document that explains how to write good ipv6-compliant code. > > itojun's "Implementing AF-indipendent apps" is a very good document. > > however, it is obsolete and it doesn't give many informations. > > > => I have done one but it is more than obsolete now. But my target > > is not AF-independence, it is IP version independence, even if a true > > AF independence (i.e. codes which can work with ISO CLNP) is a plus. > > When we get IPv10, will you prefer to change all your INET6 for INET10, > or just let the AF independent code do that by itself? > > > Regards > > Francis.Dupont@enst-bretagne.fr > > HoraPe > --- > Horacio J. Peña > horape@compendium.com.ar > horape@uninet.edu > bofh@puntoar.net.ar > horape@hcdn.gov.ar > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 21:01:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q414dP007172 for ; Mon, 25 Jun 2001 21:01:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q4147m007171 for ipng-dist; Mon, 25 Jun 2001 21:01:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q410dP007162 for ; Mon, 25 Jun 2001 21:01:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05052 for ; Mon, 25 Jun 2001 21:01:10 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08600 for ; Mon, 25 Jun 2001 22:02:03 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 667D67BB; Tue, 26 Jun 2001 13:00:27 +0900 (JST) To: Jim Bound Cc: horape@tinuviel.compendium.net.ar, Lori Napoli , ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Mon, 25 Jun 2001 23:36:47 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 13:00:27 +0900 Message-Id: <20010626040027.667D67BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Main problem with RFC2553 is that it is too ambiguous. Different >> implementations of the same standard are a Bad Thing, and vague standards >> are so a Bad Thing too. RFC 2553 should be made clearer, not vaguer. >Clarity is mandatory. What text exactly is not clear? at least the following items are not documented on 2553bis-03. for most of the items we agreed to disagree (or to leave them unspecified) on apifolks list. they raise fundamental portability issues when you implement more complex applications like BIND9 (see BIND9 doc/misc/ipv6). (NOTE: the following items does not suggest anything outside of 2553bis-03, like changes to IPv4 mapped address behavior) http://www.kame.net/newsletter/20010504/ http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/ for the current status of the world - everyone is doing this differently. itojun with IPV6_V6ONLY = off on AF_INET6 socket, if you bind(2) to A, and then bind(2) to B, what happens? will it raise error or will it go successful? pick A and B from the following. we need to define all combinations. :: ::1 0.0.0.0 127.0.0.1 ::ffff:0.0.0.0 ::ffff:127.0.0.1 no consensus on apifolks (leave it unspecified) with IPV6_V6ONLY = on on AF_INET6 socket, if you bind(2) to A, and then bind(2) to B, what happens? will it raise error or will it go successful? ditto almost no consensus on apifolks (leave it unspecified), but it seems that most people are happy to allow 0.0.0.0 bind(2) after :: bind(2). what happens if you mix IPV6_V6ONLY = on AF_INET6 socket and off AF_INET6 socket with the above? no consensus on apifolks (leave it unspecified) after all bind(2) operation combintion, who will receive the inbound traffic? for example, if you permit both :: and 127.0.0.1 to bind(2), what kind of traffic goes to which? how about :: and 0.0.0.0? (traffic from 10.0.0.1 go to the former as if from ::ffff:10.0.0.1, or the latter as if from 10.0.0.1?) no consensus on apifolks (leave it unspecified) what should getaddrinfo return on the following invocation: memset(&hints, 0, sizeof(hints)); hints.ai_flags = AI_PASSIVE; hints.ai_socktype = SOKC_STERAM; getaddrinfo(NULL, "80", &hints, &res); consensus seems to be both :: and 0.0.0.0, in this order. what should getaddrinfo return on the following invocation: memset(&hints, 0, sizeof(hints)); hints.ai_socktype = SOKC_STERAM; getaddrinfo(NULL, "80", &hints, &res); consensus seems to be both ::1 and 127.0.0.1, in this order. can we return items other than AF_INET/AF_INET6 from getaddrinfo? no consensus so far, Linux guys and NRL seem to want this. can we issue setsockopt(IPV6_V6ONLY) after bind(2) or connect(2)? consensus seems to be NO. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 21:13:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q4DqdP007218 for ; Mon, 25 Jun 2001 21:13:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q4DqPP007217 for ipng-dist; Mon, 25 Jun 2001 21:13:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q4DmdP007210 for ; Mon, 25 Jun 2001 21:13:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA11486 for ; Mon, 25 Jun 2001 21:13:58 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA18376 for ; Mon, 25 Jun 2001 22:13:56 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA05866; Tue, 26 Jun 2001 00:13:37 -0400 Date: Tue, 26 Jun 2001 00:13:37 -0400 (EDT) From: Jim Bound To: Jun-ichiro itojun Hagino Cc: horape@tinuviel.compendium.net.ar, Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010626035034.D6DFD7BB@starfruit.itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hmmmm /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) > >we did suggest that there be no default for v6only (in fact I suggested > >it) and no one on either side wanted that. thinking was even if one did > >not get their choice then its better to have default for the users. > > sorry to be picky. is it correct that "no one on either side wanted > that"? Dave Thaler and i preferred "no default" at some point. I dont recall you responding to Tim, Jack and Eriks mail that no default was very bad???????????? or Dave............... > >in fact it was about 6 to 3 ratio in favor of v6only not being the > >default. or if there were 9 people only 3 wanted what you want. > > at least the sentence conflict with the above "no one". No it does not. two different cells in the truth table. First statement was for ifandonlyif one wanted NO DEFAULT. But I don't recall yours and Daves input and I could be mistaken I guess.?????? The second was the actual vote ifandonlyif you do not support the current style of 2553 for 6 years. It was only you, and dave and one other and one person abstained from linux. Actually it was many more who did not want the v6only default I was being nice :---) I just don't want to rehash this again and again. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 21:18:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q4IpdP007240 for ; Mon, 25 Jun 2001 21:18:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q4Iomu007239 for ipng-dist; Mon, 25 Jun 2001 21:18:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q4IkdP007232 for ; Mon, 25 Jun 2001 21:18:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07017 for ; Mon, 25 Jun 2001 21:18:56 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA22880 for ; Mon, 25 Jun 2001 22:19:50 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 11EEE7BB; Tue, 26 Jun 2001 13:18:05 +0900 (JST) To: Jim Bound Cc: ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Mon, 25 Jun 2001 23:19:42 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 13:18:05 +0900 Message-Id: <20010626041805.11EEE7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >we do not document product platform differences in the IETF. just to be clear: i was suggesting to convince *book authors* to write more examples that use newer APIs, like getaddrinfo(3). otherwise university students will learn about gethostbyname(3) forever. i never suggest IETF to document platform differences. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 21:21:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q4LadP007263 for ; Mon, 25 Jun 2001 21:21:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q4La4Z007262 for ipng-dist; Mon, 25 Jun 2001 21:21:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q4LXdP007255 for ; Mon, 25 Jun 2001 21:21:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01398 for ; Mon, 25 Jun 2001 21:21:43 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA25068 for ; Mon, 25 Jun 2001 22:22:37 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04489; Tue, 26 Jun 2001 00:21:38 -0400 Date: Tue, 26 Jun 2001 00:21:38 -0400 (EDT) From: Jim Bound To: Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010626041805.11EEE7BB@starfruit.itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ack... yes this needs to be fixed soon... sorry I missed that......... /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Jun-ichiro itojun Hagino wrote: > > >we do not document product platform differences in the IETF. > > just to be clear: > i was suggesting to convince *book authors* to write more examples > that use newer APIs, like getaddrinfo(3). otherwise university > students will learn about gethostbyname(3) forever. > i never suggest IETF to document platform differences. > > itojun > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 22:48:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q5mCdP007328 for ; Mon, 25 Jun 2001 22:48:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q5mCEC007327 for ipng-dist; Mon, 25 Jun 2001 22:48:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q5m8dP007320 for ; Mon, 25 Jun 2001 22:48:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA14763 for ; Mon, 25 Jun 2001 22:48:19 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA02189 for ; Mon, 25 Jun 2001 23:48:17 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5Q5lR308285; Tue, 26 Jun 2001 08:47:28 +0300 Date: Tue, 26 Jun 2001 08:47:27 +0300 (EEST) From: Pekka Savola To: Jim Bound cc: Mauro Tortonesi , Francis Dupont , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001, Jim Bound wrote: > AF_INET6 will always permit the catch only model because its been a method > for over 6 years and customers have ported to that model. We are not > getting rid of it now. That is not going to happen. The market has > spoken and the early adopter deployment customers will not have their code > broken. > > As far as the default it is you will get v4mapped on AF_INET6 unless you > set v6only sockopt. Wouldn't it be better to have the code potentially broken _now_, when they're (very) _early adopters_, versus in 2-3 years when *everybody's* code would break? There are dangers to being an early adopter. One of them is having to rewrite code when it becomes clear that certain method, discovered during the early adopter phase, is not going to work in the long term. Better to break 1000 people's code now than 100000's in two years. Or are we just playing time here? If we can delay this enough, there's no way we can get rid of mapped addresses in the next 10 years as it's going to be used by ported apps more and more... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 25 23:40:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q6e9dP007420 for ; Mon, 25 Jun 2001 23:40:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q6e8BA007419 for ipng-dist; Mon, 25 Jun 2001 23:40:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q6e5dP007412 for ; Mon, 25 Jun 2001 23:40:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24612 for ; Mon, 25 Jun 2001 23:40:14 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA20315 for ; Tue, 26 Jun 2001 00:41:05 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5Q6d6E08477; Tue, 26 Jun 2001 09:39:06 +0300 Date: Tue, 26 Jun 2001 09:39:06 +0300 (EEST) From: Pekka Savola To: Jim Bound cc: Jun-ichiro itojun Hagino , Mauro Tortonesi , Francis Dupont , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001, Jim Bound wrote: > we do not document product platform differences in the IETF. > > but here is how the market will work. > > the market picks a market leader. today that market leader for most of IP > stuff for "Servers" is Sun Microsystems (not all but most if you look at > market share). For the client its Microsoft. [ I don't want to start an OS flamewar here (or anywhere else), but I think this has to be clarified as it is important in your argumentation. ] I'm sorry, but the above for servers seems to be explainable only by assuming some interesting definition for "market leader". Does it have to be sold for an expensive price to qualify? I don't have the detailed numbers handy, but a google search pointed to, for example: http://news.cnet.com/news/0-1003-200-4979275.html?tag=prntfr (IDC Server OS market share in 2000) Windows: 41% Linux: 27% Netware: 17% Unix: 14% Other: 2% For example, Linux is about twice as popular as Solaris, HP-UX, Aix, Tru64, etc. *combined*. Granted these are for all kinds of servers, but give some figure for popularity. For small to medium-sized IP servers, I couldn't find any statistics but I'd estimate: 40% BSD + Linux 25% Solaris 20% Windows 15% Rest (personally I've a feeling that BSD+Linux should have a lot higher percentage, but I tried to be unbiased) Large IP servers (GB's of memory, etc.) are a small minority of all IP server and should not spell out the way we're heading. Lies, damned lies, statistics etc. aside, I think you can _at least_ safely assume that free operating systems are a major, if not dominant, player in IP server markets. Please open the windows of your office and look outside :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 00:28:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q7S9dP007514 for ; Tue, 26 Jun 2001 00:28:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q7S9Nr007513 for ipng-dist; Tue, 26 Jun 2001 00:28:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q7S5dP007506 for ; Tue, 26 Jun 2001 00:28:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24469 for ; Tue, 26 Jun 2001 00:28:15 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25262 for ; Tue, 26 Jun 2001 01:28:11 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5Q7Q8402626; Tue, 26 Jun 2001 14:26:09 +0700 (ICT) From: Robert Elz To: horape@tinuviel.compendium.net.ar cc: Jim Bound , Jun-ichiro itojun Hagino , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625132617.B20646@tinuviel.compendium.net.ar> References: <20010625132617.B20646@tinuviel.compendium.net.ar> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Jun 2001 14:26:08 +0700 Message-ID: <2624.993540368@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 25 Jun 2001 13:26:17 -0300 From: horape@tinuviel.compendium.net.ar Message-ID: <20010625132617.B20646@tinuviel.compendium.net.ar> | The question is "Will IPv6 work forever?", if the answer is yes, then there | is nothing to talk about, if the answer is no (and I think that way) then | we should try to help the next transitions to be easier, using what we have | learned now. Unfortunately this requires crystal ball gazing. I partly agree with Jim - not where he said that 10 years is nothing (he seems to have forgotten that the IPv4 API that is being, only partly, replaced here was invented 20 years ago already...) but do agree that we cannot possibly plan now to handle the next set of problems. The API transition for IPv6 largely concerns dealing with the different address type - if/when we need a new protocol, the least likely thing of all we have in IPv6 to be worrying about will be the address. It may be that in some future protocol, applications will be required to determine and set a flow label for all packets/connections - nothing we're now defining would have applications doing that (even if we did, we have no idea what form the flow label of that far future time might be). Or, it may be that (as was proposed by PIP) applications need to discover and set the route to the destination, with the "routers" being converted to being just very fast forwarders, not running any routing algorithms at all. Since we have no idea how that might be done, or what the result would look like, we can't plan for that today either. Of course, since I can imagine both of those already, they're most likely not going to be the major turning point which requires a new IP level protocol. What it would be is likely to be something that now we can't even guess at. Given that, how can we possibly design an API today to handle it? (Unless we make the API so dumb, that the application gets no control at all). But more than that, it is perhaps more likely that the next revolution will be transport protocol based, and it will be the API that deals with the transport interface, rather than the part of it that deals with TCP or UDP (or something entirely new) will be what needs to alter. That is, perhaps port numbers will be gone completely from a future transport interface, to be replaced by something else completely different. Who knows? Because of all this, we cannot possibly make an AF independent API that handles anything more than the protocols that we know of today. Perhaps we can also make it adaptable to a few things that we can guess now might happen in the future (but for any of those that we now think likely, we'd be better off to simply include them now, and avoid another transition later - but there seems to be little we can agree on might be needed, beyond what is in IPv6) so, even that doesn't seem productive. And then given that, what is needed is to handle what we see as being important to handle of today's protocols - and that means IPv4 and IPv6. There's nothing else that almost any code which is going to use this API is going to deal with (we could add CLNP or something, but the applications that use CLNP and the applications that use IP are almost a disjoint set, there's almost nothing to be gained by unifying them). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:15:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8FqdP007628 for ; Tue, 26 Jun 2001 01:15:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8Fqmj007627 for ipng-dist; Tue, 26 Jun 2001 01:15:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8FNdP007620 for ; Tue, 26 Jun 2001 01:15:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03026 for ; Tue, 26 Jun 2001 01:15:33 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA07490 for ; Tue, 26 Jun 2001 01:15:32 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5Q8FHi41327; Tue, 26 Jun 2001 10:15:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA14475; Tue, 26 Jun 2001 10:15:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5Q8FFO86755; Tue, 26 Jun 2001 10:15:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106260815.f5Q8FFO86755@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Mauro Tortonesi , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Sun, 24 Jun 2001 22:19:00 +0300. Date: Tue, 26 Jun 2001 10:15:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I don't want to replace IPv4 by IPv6 next month, I want to get > dual stacks as default ASAP. RFC 2553 is for dual stacks and > dual stack is the main transition tool. On dual stacks, user can usually disable ipv6. Examples of this are Linux or BSD which nowadays ship ipv6-enabled by default. However, some users can turn it off intentionally or unitentionally. As Itojun pointed out, recompiling the user space is not usually an option. => this is Itojun's choice, he mentioned it because he knows that it is not mine (:-). So, porting applications so that they can handle both gracefully is the way it should be done for about 5+ next years. => ah! I understand where we disagree. For me the 5+ next years began at the end of 1995 so the delay is expired... The IPv4 mapped stuff is enough in my environment to catch legacy applications. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:28:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8S6dP007650 for ; Tue, 26 Jun 2001 01:28:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8S6l5007649 for ipng-dist; Tue, 26 Jun 2001 01:28:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8S2dP007642 for ; Tue, 26 Jun 2001 01:28:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22897 for ; Tue, 26 Jun 2001 01:27:59 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA24769 for ; Tue, 26 Jun 2001 02:28:52 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5Q8RHi19607; Tue, 26 Jun 2001 10:27:18 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA14609; Tue, 26 Jun 2001 10:27:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5Q8RGO86850; Tue, 26 Jun 2001 10:27:17 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106260827.f5Q8RGO86850@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 14:24:34 +0900. Date: Tue, 26 Jun 2001 10:27:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Just to make it sure, if you mean "accepting IPv4 packets on an AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable the model by default. => I agree with the definition of the model... and any implementation which doesn't follow it or disables it by default is not compliant. We can't support every not compliant implementations just because there are too many ways to be not compliant so your argument (we have to support everything) is not admissible: AF independent coding style is perhaps better but we haven't to enforce it. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:47:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lrdP007715 for ; Tue, 26 Jun 2001 01:47:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8lrgY007713 for ipng-dist; Tue, 26 Jun 2001 01:47:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8ljdP007702 for ; Tue, 26 Jun 2001 01:47:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06008 for ; Tue, 26 Jun 2001 01:47:55 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14085 for ; Tue, 26 Jun 2001 02:48:48 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.142.38) by smtp2.libero.it (5.5.025) id 3AE981AF00D5E65D; Tue, 26 Jun 2001 10:47:44 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 6DBEB28A40; Tue, 26 Jun 2001 10:13:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 45DC728A35; Tue, 26 Jun 2001 10:13:57 +0200 (CEST) Date: Tue, 26 Jun 2001 10:13:57 +0200 (CEST) From: Mauro Tortonesi To: Jun-ichiro itojun Hagino Cc: Francis Dupont , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625143506.281C27BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001, Jun-ichiro itojun Hagino wrote: > >> we really need to convince random book authors to update their > >> programming examples, from gethostbyname() to getnameinfo()... > >how can you expect them do so, when there's so much difference between > >the behaviour of the various TCP/IPv6 stacks? > > yes, that is the issue. i was trying to suggest example be using > getaddrinfo(3) loop, which should work for the most cases. > if OS designers are sane enough to design bind(2) behavior and > getaddrinfo(3) behavior with care, getaddrinfo(3) loop has a good > chance to work in many cases. > we need to document platform differences, of course. > > for exaplme, for server side, assume that the goal is to accept both > IPv4 and IPv6 traffic. > - if getaddrinfo(3) returns :: and 0.0.0.0, the code will work > for the following cases: > bind(2) in any order is permitted, traffic accepted as > necessary > bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket > grabs IPv4 traffic > but not for the following case: > bind(2) of 0.0.0.0 prohibited after ::, AF_INET6 socket > does not grab IPv4 traffic (seems very broken to me) > - if getaddrinfo(3) returns :: only, it will work for the following > cases: > AF_INET6 socket grabs IPv4 traffic > but not for the following cases: > AF_INET6 socket does not grab IPv4 traffic (getaddrinfo seems > broken to me on this platform) > > (note to OS imlementers - so getaddrinfo(3) behavior has to be > carefully designed consdidering your bind(2) and IPv4 mapped addr > behavior!) why don't we include this as a note in RFC2553 addressing implementers? > >IMHO, draft-ietf-ipngwg-rfc2553bis-03.txt should specify what is the > >correct behaviour for bind(2). i vote for the *BSD one: by having two > >different sockets binding indipendently one from the other, we can > >get rid of all the problems given by IPv4-mapped IPv6 address, and > >have true af-indipendence. the IPV6-ONLY option and IPv4-mapped IPv6 > >address should not be deprecated, but their use should be unrecommended. > >this policy would lead to the best result with only minor changes in the > >draft and in the existing ipv6 implementations. > > I have been trying SO HARD to suggest it in api discussion group (which > is a small group of people who contributed 2553bis-03 updates), but > was rejected. it is a holy war where there's no end. one side > advocates AF_INET6 only world, one side advocates AF_INET6/AF_INET > splitted socket (or at least make the default behavior so). > I'm of course in the second camp. > > in fact, as far as i understand, there's no good standard document > on bind(2) interaction between two IPv4 sockets. so defining it > for IPv4/v6 interaction would be a big task. i think that without the definition of a single standard behaviour for bind and getaddrinfo, developers will have big problems writing portable software. i propose to add a paragraph to RFC2553 that explains the two allowed behaviours for getaddrinfo and bind, and defining a constant that can be examined to know the actual behaviour of our system at compile time. something like: #ifdef AF64_ORTHOGONALITY /* the system behaves like *BSD */ #else /* the system behaves like linux */ #endif the same thing can be achieve in a better way if we define a new read-only socket option: getsockopt(sock, IPPROTO_IPV6, AF64_ORTHOGONALITY, &value, sizeof(int)); this works at run time. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:47:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lQdP007686 for ; Tue, 26 Jun 2001 01:47:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8lQan007685 for ipng-dist; Tue, 26 Jun 2001 01:47:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lMdP007678 for ; Tue, 26 Jun 2001 01:47:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05989 for ; Tue, 26 Jun 2001 01:47:33 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19991 for ; Tue, 26 Jun 2001 01:47:32 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.142.38) by smtp1.libero.it (5.5.025) id 3AE980E700D9274F; Tue, 26 Jun 2001 10:47:31 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id E7D9828A41; Tue, 26 Jun 2001 10:18:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id E1B8828A35; Tue, 26 Jun 2001 10:18:27 +0200 (CEST) Date: Tue, 26 Jun 2001 10:18:27 +0200 (CEST) From: Mauro Tortonesi To: Cc: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625140857.C26062@tinuviel.compendium.net.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q8lMdP007679 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > > for(n = 0; (n < MAX_AF) && res ; res = res->ai_next) { > > > listenfds[n] = socket(res->ai_family, res->ai_socktype, > > > res->ai_protocol); > > > if(listenfds[n] < 0) > > > continue; /* libc supports protocols that kernel don't */ > > > > > > if(bind(listenfds[n], res->ai_addr, res->ai_addrlen) != 0) > > > die(); > > > > > > if(listen(listenfds[n], 10) != 0) > > > die(); > > > n++; > > > } > > > i am afraid i don't understand this portion of code. is getaddrinfo > > expected to return one-and-only-one ready-to-be-bound address for > > every AF when called with flag AI_PASSIVE set? there's nothing in > > the drafts that states this: > > That's not specified, as far as I can tell. It must return all the > sockaddr's to bind to. If with just one sockaddr is enough that could > be correct. But it's implemented normally as you described. unfortunately, on linux it's not. > > from what i can guess, instead, the expected behaviour for getaddrinfo in > > this case (AI_PASSIVE, AF_UNSPEC and SOCK_STREAM set) is to return a > > ready-to-be-bound ::1 (ipv6) address. am i wrong? > > It should be :: (ANY), not ::1 (loopback) and that could be done that way > if all the AFs can be mapped to IPv6, but if there are no mappable protocols > it should return the list. of course. it's ::. excuse me. > > if so, your code (which is truly AF-indipendent) is not RFC2553-compliant. > > or better, the API specified by RFC2553 is not AF-indipendent. > > I don't understand that. it was a reference to the AF-indipendent code you have presented in your paper. > > that's nonsense. compliant stacks would not be AF-independent, but > > quasi-compliant stacks would be. > > I like better the noncompliant systems, but standard compliance is too > important to discard it. So I hope to change the standard to accept > the actually noncompliant behaviour. i don't think we will reach consensus about this. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:47:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lqdP007714 for ; Tue, 26 Jun 2001 01:47:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8lqiD007712 for ipng-dist; Tue, 26 Jun 2001 01:47:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lhdP007691 for ; Tue, 26 Jun 2001 01:47:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06002 for ; Tue, 26 Jun 2001 01:47:53 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15812 for ; Tue, 26 Jun 2001 02:47:51 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.142.38) by smtp1.libero.it (5.5.025) id 3AE980E700D92784; Tue, 26 Jun 2001 10:47:42 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 58A6828A43; Tue, 26 Jun 2001 10:20:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 5725628A35; Tue, 26 Jun 2001 10:20:56 +0200 (CEST) Date: Tue, 26 Jun 2001 10:20:56 +0200 (CEST) From: Mauro Tortonesi To: Cc: Jun-ichiro itojun Hagino , Francis Dupont , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625143923.H26062@tinuviel.compendium.net.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > > in fact, as far as i understand, there's no good standard document > > on bind(2) interaction between two IPv4 sockets. so defining it > > for IPv4/v6 interaction would be a big task. > > Maybe we should start writing that document? (although I see working for IPv4 > a waste of time and effort) why not? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:47:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lndP007710 for ; Tue, 26 Jun 2001 01:47:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8lnhl007709 for ipng-dist; Tue, 26 Jun 2001 01:47:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lgdP007688 for ; Tue, 26 Jun 2001 01:47:42 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27501 for ; Tue, 26 Jun 2001 01:47:52 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15803 for ; Tue, 26 Jun 2001 02:47:50 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.142.38) by smtp3.libero.it (5.5.025) id 3AE9822800D666CE; Tue, 26 Jun 2001 10:47:42 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id C3A7628A42; Tue, 26 Jun 2001 10:20:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id BD96628A35; Tue, 26 Jun 2001 10:20:12 +0200 (CEST) Date: Tue, 26 Jun 2001 10:20:12 +0200 (CEST) From: Mauro Tortonesi To: Cc: , Francis Dupont , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010625142144.F26062@tinuviel.compendium.net.ar> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5Q8lgdP007689 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001 horape@tinuviel.compendium.net.ar wrote: > ¡Hola! > > > however, it's not so simple. in this way we have two indipendent protocol > > families AF_INET and AF_INET6 (i would define them orthogonal), so > > we should modify the behaviour of getaddrinfo. > > No change to getaddrinfo is needed. then both the glibc and the USAGI implementation of getaddrinfo on linux are broken. > > in fact, when called with AI_PASSIVE flag set and AF_UNSPEC protocol > > family, in a both ipv4- and ipv6-compliant system, getaddrinfo should > > return two different results (::1 for ipv6 and 127.0.0.1 for ipv4). > > moreover, calling getaddrinfo with AF_UNSPEC protocol family should > > produce a result that's the sum of the results of two getaddrinfo > > calls (one for AF_INET and one for AF_INET6). > > That's exactly how getaddrinfo works. not on a rfc2553-compliant system like linux. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 02:23:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9NjdP007785 for ; Tue, 26 Jun 2001 02:23:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q9NjRo007784 for ipng-dist; Tue, 26 Jun 2001 02:23:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9NfdP007777 for ; Tue, 26 Jun 2001 02:23:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26873 for ; Tue, 26 Jun 2001 02:23:52 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA15157 for ; Tue, 26 Jun 2001 03:24:44 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5Q9Nai31892; Tue, 26 Jun 2001 11:23:36 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA15478; Tue, 26 Jun 2001 11:23:35 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5Q9NZO87198; Tue, 26 Jun 2001 11:23:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106260923.f5Q9NZO87198@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: itojun@iijlab.net, horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 15:15:22 +0200. Date: Tue, 26 Jun 2001 11:23:35 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > we really need to convince random book authors to update their > programming examples, from gethostbyname() to getnameinfo()... how can you expect them do so, when there's so much difference between the behaviour of the various TCP/IPv6 stacks? => this discussion is about to find a way to solve difference between compliant stacks... HoraPe has explained us that on *BSD systems, you can have two different sockets (one for AF_INET and one for AF_INET6) bound on the same port. in this way you can use an af-indipendent programming style. => you can use it with the V6ONLY stuff. this is not true with linux. you have to use a single AF_INET6 socket and listen on both incoming ipv4 and ipv6 connections. => this is the standard way but with the V6ONLY way you can use the single socket (my favorite) or the socket per IP version (Itojun's favorite). The user shall choice his own favorite or the one which matches the application constraints. draft-ietf-ipngwg-rfc2553bis-03.txt does not specify a specific behaviour for bind. it's left to the implementors. i'd really like to know the reason for doing so. IMVHO, this is a problem, because it will lead developers to write platform-specific code and technical writers to produce misinformation. => oh no! Read the mailing list archive and don't reopen this discussion! (the conclusion of the discussion is against your proposal which is not as new as you seem to believe) however, as you have already said, the real problem is that there is not a "Unix Network Programming"-like reference book covering ipv6 socket programming. => there is one but it is too old and the author is dead... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 02:26:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9QVdP007802 for ; Tue, 26 Jun 2001 02:26:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q9QUo9007801 for ipng-dist; Tue, 26 Jun 2001 02:26:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9QQdP007794 for ; Tue, 26 Jun 2001 02:26:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03614 for ; Tue, 26 Jun 2001 02:26:37 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14428 for ; Tue, 26 Jun 2001 02:26:36 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5Q9QGi43751; Tue, 26 Jun 2001 11:26:16 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA15513; Tue, 26 Jun 2001 11:26:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5Q9QFO87214; Tue, 26 Jun 2001 11:26:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106260926.f5Q9QFO87214@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: Pekka Savola , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 15:50:10 +0200. Date: Tue, 26 Jun 2001 11:26:15 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS: (again) IPv6 is not a new protocol, IPv6 is the new version of IP. > If you believe in this (stronger than IPv6 itself) then you can really > understand the dual stack model (the integrated dual version model). right. but this is not the real problem. => this is the real problem: your problem is in fact a consequence. the real problem is if AF_INET6 family should be a catch-all extension of AF_INET or if they should be an unrelated, being AF_INET6 a totally different type of socket from AF_INET. i vote for the second option. => and RFC 2553 specifies the first option. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 02:55:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9tsdP007902 for ; Tue, 26 Jun 2001 02:55:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q9tsss007901 for ipng-dist; Tue, 26 Jun 2001 02:55:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9todP007894 for ; Tue, 26 Jun 2001 02:55:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05442 for ; Tue, 26 Jun 2001 02:55:59 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29324 for ; Tue, 26 Jun 2001 03:55:57 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5Q9sxi44284; Tue, 26 Jun 2001 11:55:00 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA16023; Tue, 26 Jun 2001 11:54:58 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5Q9svO87328; Tue, 26 Jun 2001 11:54:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106260954.f5Q9svO87328@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mauro Tortonesi cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 16:05:34 +0200. Date: Tue, 26 Jun 2001 11:54:57 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > ...however, those corrections do not affect the main stream of this > discussion. We've fully, fully discussed this (in the apifolks list), > and have seen so many different views, and, as a consequence, could > not reach consensus on a single unified behavior. Sad to say this, > but I don't think we'll be able to force vendors a particular behavior > based on a particular view of the model, like "the correct thing is to > deprecate IPv4-mapped IPv6 addresses"... then why bothering to write RFC2553? if any ISV can do what he wants it has been only a useless effort. your arguments don't seem to have moche sense to me. rather, the discussion should be re-opened and, as a result, a new proposed standard should be produced. > So, IMHO, the only feasible thing we can do now is to accept the > differences of various implementations, and make a guidance of how to > deal with the differences with a minimum effort. this would be a BIG mistake, IMVHO. it is imperative to produce a standard for BSD socket extensions, or we can forget the word "code portability" for the next 50 years... => some of us are old enough or learn by the hard way that to be convinced to be in possesion of the Truth is not a strong argument. Please don't reopen this discussion, to flood this mailing list with boring messages about this won't be a successful strategy (:-). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 02:59:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9xIdP007945 for ; Tue, 26 Jun 2001 02:59:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q9xIsJ007944 for ipng-dist; Tue, 26 Jun 2001 02:59:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q9xEdP007937 for ; Tue, 26 Jun 2001 02:59:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02462 for ; Tue, 26 Jun 2001 02:59:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01046 for ; Tue, 26 Jun 2001 02:59:22 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5Q9wmk09334; Tue, 26 Jun 2001 12:58:48 +0300 Date: Tue, 26 Jun 2001 12:58:47 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Mauro Tortonesi , , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106260923.f5Q9NZO87198@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > we really need to convince random book authors to update their > > programming examples, from gethostbyname() to getnameinfo()... > > how can you expect them do so, when there's so much difference between > the behaviour of the various TCP/IPv6 stacks? > > => this discussion is about to find a way to solve difference between > compliant stacks... Differences between _currently_ compliant stacks aren't the big issue here. Compliancy is specifically defined, and if a stack is compliant there should be no interoperability problems. Rather, what should be labeled as "compliant" and what not is what this is about. I doubt there's going to be "rough consensus" on this subject (AAAA vs A6 take two, anyone), so would it be possible to define two possible methods, and easy means how the application developer could find out which his OS's prefer and one that best suits his interests? This way both parties _might_ be happy and we could end this and move on. Else this very issue keeps popping up all the time and the API will be in limbo forever. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 03:08:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QA8NdP007983 for ; Tue, 26 Jun 2001 03:08:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QA8NmJ007982 for ipng-dist; Tue, 26 Jun 2001 03:08:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QA8JdP007975 for ; Tue, 26 Jun 2001 03:08:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06345 for ; Tue, 26 Jun 2001 03:08:27 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA06229 for ; Tue, 26 Jun 2001 03:08:26 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QA7Yi57258; Tue, 26 Jun 2001 12:07:34 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA16227; Tue, 26 Jun 2001 12:07:34 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QA7XO87396; Tue, 26 Jun 2001 12:07:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261007.f5QA7XO87396@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-reply-to: Your message of Mon, 25 Jun 2001 23:34:29 +0900. Date: Tue, 26 Jun 2001 12:07:33 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As an IPv6 stack/application programmer, I'd really like to fix the advanced API. The current situation is really mess, because rfc2292bis does not provide backward compatibility to the old RFC 2292, and some OSes has already shipped with rfc2292bis while some other OSes still keep RFC 2292. I believe we should basically go with rfc2292bis, since it has fixed many issues (bugs, in fact) in the old RFC spec, and some of them are essential for some applications (e.g. the IPV6_USE_MIN_MTU option for DNS servers). => I agree. Obviously the current editor has not enough time to do this but this must be done ASAP. The most difficult issue would be the one for extension headers. According to a recent discussion about MIP6 issues, the API should be flexible enough to send/receive extension headers in any order, whereas rfc2292bis basically assumes the recommended order of the headers specified in RFC2460. Since it could be a fundamental change of the API spec, I'm not sure if we can get a consensus so smoothly. Anyways, I'll raise this issue later in a separate thread. => this is a deep change but not in a very used part of the spec so perhaps we should split the advanced API into two parts in order to be able to publish a document soon? If possible, I'd like to see the next revision of the draft before the next IETF meeting in London. => two procedural questions: - is the change of the name of the working group makes the counter to restart at 0? - if we split the document into two parts, can you keep the name? I.e. is the deadline 13 July or not? Thanks Francis.Dupont@enst-bretagne.fr PS: we have a G6 meeting at the end of the week, I'll try to collect comments at this occasion. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 03:14:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAERdP008003 for ; Tue, 26 Jun 2001 03:14:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QAEREx008002 for ipng-dist; Tue, 26 Jun 2001 03:14:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAEMdP007995 for ; Tue, 26 Jun 2001 03:14:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11833 for ; Tue, 26 Jun 2001 03:14:30 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12715 for ; Tue, 26 Jun 2001 04:14:27 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QAEHi14106; Tue, 26 Jun 2001 12:14:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA16309; Tue, 26 Jun 2001 12:14:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QAEGO87474; Tue, 26 Jun 2001 12:14:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261014.f5QAEGO87474@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: horape@tinuviel.compendium.net.ar cc: Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 14:12:29 -0300. <20010625141229.D26062@tinuviel.compendium.net.ar> Date: Tue, 26 Jun 2001 12:14:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The problem is that not forgeting them means the same amount of work that doing the port in the AF independent way. So the benefits of the IPv4-mapped addresses (easy porting) get lost. => be serious, not all applications need access control (at least clients don't need it and they represent more than 50%). Not everything is like inetd or BIND... Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 03:19:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAJ0dP008025 for ; Tue, 26 Jun 2001 03:19:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QAJ0nR008024 for ipng-dist; Tue, 26 Jun 2001 03:19:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAIudP008017 for ; Tue, 26 Jun 2001 03:18:56 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00791 for ; Tue, 26 Jun 2001 03:19:04 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11818 for ; Tue, 26 Jun 2001 03:19:03 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QAIli50038; Tue, 26 Jun 2001 12:18:47 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA16366; Tue, 26 Jun 2001 12:18:47 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QAIkO87533; Tue, 26 Jun 2001 12:18:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261018.f5QAIkO87533@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: horape@tinuviel.compendium.net.ar cc: Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 14:40:47 -0300. <20010625144047.I26062@tinuviel.compendium.net.ar> Date: Tue, 26 Jun 2001 12:18:46 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: When we get IPv10, will you prefer to change all your INET6 for INET10, or just let the AF independent code do that by itself? => I can't see a problem before IPv16 (:-) Francis.Dupont@enst-bretagne.fr PS: (silly?) suggession: remove AF_INET6 and use AF_INET for IP with any version with injection of small address spaces in the larger one? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 03:22:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAMWdP008045 for ; Tue, 26 Jun 2001 03:22:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QAMWvH008044 for ipng-dist; Tue, 26 Jun 2001 03:22:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAMSdP008037 for ; Tue, 26 Jun 2001 03:22:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12244 for ; Tue, 26 Jun 2001 03:22:36 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17521 for ; Tue, 26 Jun 2001 04:22:34 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QAMHi32216; Tue, 26 Jun 2001 12:22:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA16407; Tue, 26 Jun 2001 12:22:16 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QAMGO87574; Tue, 26 Jun 2001 12:22:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261022.f5QAMGO87574@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: horape@tinuviel.compendium.net.ar cc: Pekka Savola , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Mon, 25 Jun 2001 14:47:49 -0300. <20010625144749.K26062@tinuviel.compendium.net.ar> Date: Tue, 26 Jun 2001 12:22:16 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I get the impression you are doing mostly 2). > => more than 2), the IPv6 support is not togglable! In the "real world" you cannot say that. People will want to disable IPv6 for a long time. => if you believe this you should spend more time on a NAT-friendly API (:-) Francis.Dupont@enst-bretagne.fr PS: don't be afraid, jump into the IPv6 world! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 03:31:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAVvdP008070 for ; Tue, 26 Jun 2001 03:31:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QAVukL008069 for ipng-dist; Tue, 26 Jun 2001 03:31:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QAVrdP008062 for ; Tue, 26 Jun 2001 03:31:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01918 for ; Tue, 26 Jun 2001 03:32:01 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22451 for ; Tue, 26 Jun 2001 04:31:58 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id NAA15283; Tue, 26 Jun 2001 13:31:58 +0300 Date: Tue, 26 Jun 2001 13:31:58 +0300 Message-Id: <200106261031.NAA15283@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <200106260926.f5Q9QFO87214@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 26 Jun 2001 11:26:15 +0200) Subject: Re: RFC 2553 bind semantics harms the way to AF independence References: <200106260926.f5Q9QFO87214@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just want to inject another viewpoint to this Unix-centric discussion. I'm trying to specify how the IPv6 affects the socket API in EPOC OS, and this is how it works (to bind a server socket): RSocketServ iSS; // Socket server handle (EPOC specific) RSocket iSocket; // Socket (roughly same as Unix) ... // Open Socket to be used for TCP TInt err = iSocket.Open( iSS, // socket server handle KAfInet, // Protocol Family = INET KSockStream, // Stream Socket KProtocolInetTcp // TCP protocol ); ... TInetAddr addr; // declare equivalent of sock_addr addr.SetPort(80); // define port of the address // addr.SetAddress(KInetAddrAny); // Listen only IPv4 // addr.SetAddress(Kinet6AddrNone); // Listen only IPv6 // addr.SetFamily(0); // default, listen IPv4 and IPv6 err = iSocket.Bind(addr); ... err = iSocket.Listen(100); For the rest of the code, it really doesn't matter whether bind was IPv4 only, IPv6 only or allow both. (Except that with the first variant, returned addresses are of KAfInet family, and for latter two, address family is KAfInet6 and IPv4 is represented as IPv4-mapped.) The key difference to the Unix is that, the existing address class (TInetAddr) that is being used by IPv4 applications, is large enough to hold also IPv6 addresses. Thus, with some reservations, existing IPv4 application binaries have high probability of working as is also with IPv6 connections (WEB browser being one example of such applications). IPv4 (as IPv4 mapped) is a subset of IPv6. As to issues like src="::ffff:10.255.255.255", you have to handle this in IPv4 only world, the same applies to IPv6. If your application doesn't want to do these checks and if they are required, then it can refuse to anser to all IPv4 or set this IPv6ONLY flag? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 05:21:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCLHdP008255 for ; Tue, 26 Jun 2001 05:21:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QCLHX1008254 for ipng-dist; Tue, 26 Jun 2001 05:21:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCLBdP008247 for ; Tue, 26 Jun 2001 05:21:12 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f5QCLE723433; Tue, 26 Jun 2001 14:21:14 +0200 (MET DST) Date: Tue, 26 Jun 2001 14:20:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: complete the advanced API (rfc2292bis) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If possible, I'd like to see the next revision of the draft before the > next IETF meeting in London. So my question is: > > does anyone (especially in the authors) try to revise the draft now? I'd like to see the document finished. But I don't have any cycles to actually drive the open issues to conclusion. If folks can agree on text to add/change I can do the editing of the document. Or I can take on a co-author that will help drive this to conclusion and also do the edits. > - Add credits for UDP MTU stuff > - Move information about mapping from inet6_opt to setsockopt and > cmsg. > > What exactly do these two items mean? The issue about UDP MTU for DNS servers was brought up by somebody on this list and there was a separate I-D (expired long time ago) which had one proposal for this. The document should give due credit to that individual. The second one is about the structure of the document. The inet6_opt routines are described as having to do with ancillary data and in a separate place it is pointed out that the routines also apply to the same information in setsockopt. This organization could be better. > - Fix Authors address wrt Rich. > > It's an editorial issue. (But what is the best "address" for him?) I don't know what is traditionally done in cases like this thus any guidance would be quite helpful. If he is listed as an author we need to say something in the address section. Alternatively we can list him at the top of the acknowldgement section e.g. with something like Previous versions of this document [RFC 2292] was co-authored by the late Rich Stevens. > - Specify "change" for TCP especially when there are multiple HBH > option headers etc. > > ??? what does "multiple HBH option headers" mean? The IPv6 spec > requirs a HBH option header appear only once in a single packet. Is > this a typo, and should this be "multiple DST option headers"? I guess the comment is generic - applies indepedently of the type of repeated extension headers. Is there really something in RFC 2460 which says that packets with multiple HBH headers should be dropped? Being "liberal in what you receive" would hint that it would be good to accept such packets. But then we need perhaps specify something - or at least point out the issue - for TCP detecting when the set of extension headers and their content is different in one segment than the previous segments. > - If the home address option passed out in If so > what address value does it contain? > > As I said above, I'd prefer a separate option if we really need to > pass the home address to applications. I'd be fine with that approach. This means adding some text to say that the home address option should not be passed to the application when the application has specified IPV6_RECVDSTOPTS?, right? Or do you envision two different mechanisms by which the application can receive this information? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 05:24:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCO5dP008278 for ; Tue, 26 Jun 2001 05:24:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QCO4wx008277 for ipng-dist; Tue, 26 Jun 2001 05:24:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCNxdP008270 for ; Tue, 26 Jun 2001 05:24:00 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f5QCO5723806; Tue, 26 Jun 2001 14:24:06 +0200 (MET DST) Date: Tue, 26 Jun 2001 14:23:39 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2553 bind semantics harms the way to AF independence To: Jun-ichiro itojun Hagino Cc: horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20010622144837.DE4C17BB@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > > > Then the IPv6 sockets would have to be explicitly allowed to accept > > IPv4 connections. So the programs that use the IPv6 centric way have > > to be modified a bit, but the buggy implementations and the unworkable > > one could be corrected without losing features. Just making > > IPV6_V6ONLY default to on would have the same results. > > I really love to see this happen (polarity change is enough). > also, if IPv4 mapped address support becomes optional (explicitly) > to OS implementers it would be much better. In hindsight I agree that the default should have been different - forcing applications to explicitly request use of IPv4-mapped addresses on AF_INET6 sockets. But I suspect that folks have different opinions on the cost of changing the default at this point in time :-( Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 05:30:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCUVdP008315 for ; Tue, 26 Jun 2001 05:30:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QCUVGK008314 for ipng-dist; Tue, 26 Jun 2001 05:30:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCUQdP008307 for ; Tue, 26 Jun 2001 05:30:27 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f5QCUV724453; Tue, 26 Jun 2001 14:30:31 +0200 (MET DST) Date: Tue, 26 Jun 2001 14:30:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2553 bind semantics harms the way to AF independence To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > Just to make it sure, if you mean "accepting IPv4 packets on an > AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in > 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable > the model by default. What aspect of this do you believe is not there is Solaris? Solaris by default accepts IPv4 packets on an AF_INET6 socket bound to in6addr_any, so there must be some sutble detail that you're referring to. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 05:41:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCfodP008358 for ; Tue, 26 Jun 2001 05:41:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QCfopi008357 for ipng-dist; Tue, 26 Jun 2001 05:41:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCfkdP008350 for ; Tue, 26 Jun 2001 05:41:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23257; Tue, 26 Jun 2001 05:41:54 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08249; Tue, 26 Jun 2001 06:41:51 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5QCfqL10138; Tue, 26 Jun 2001 15:41:52 +0300 Date: Tue, 26 Jun 2001 15:41:51 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: Jun-ichiro itojun Hagino , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Erik Nordmark wrote: > > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > > > > > Then the IPv6 sockets would have to be explicitly allowed to accept > > > IPv4 connections. So the programs that use the IPv6 centric way have > > > to be modified a bit, but the buggy implementations and the unworkable > > > one could be corrected without losing features. Just making > > > IPV6_V6ONLY default to on would have the same results. > > > > I really love to see this happen (polarity change is enough). > > also, if IPv4 mapped address support becomes optional (explicitly) > > to OS implementers it would be much better. > > In hindsight I agree that the default should have been different - forcing > applications to explicitly request use of IPv4-mapped addresses on AF_INET6 > sockets. > But I suspect that folks have different opinions on the cost of changing > the default at this point in time :-( What do you suspect the cost would be in 2-3 years? I don't think the _current_ amount of IPv6 applications is that huge. Almost all of these are simple tools by OS vendors, or open source. I don't think the change would be too big _now_, especially if the change was detected by people who don't necessarily read RFC's (e.g. compilation fail => forced to look at issue and spend an hour thinking about it). IMO, we haven't passed the point of no return yet. In 2-3 years we have. And hindsight then won't be fun. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 05:57:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCvndP008383 for ; Tue, 26 Jun 2001 05:57:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QCvn3t008382 for ipng-dist; Tue, 26 Jun 2001 05:57:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QCvjdP008375 for ; Tue, 26 Jun 2001 05:57:45 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13605 for ; Tue, 26 Jun 2001 05:57:54 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26903 for ; Tue, 26 Jun 2001 05:57:53 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QCv3i15028; Tue, 26 Jun 2001 14:57:03 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA18190; Tue, 26 Jun 2001 14:57:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QCv2O88127; Tue, 26 Jun 2001 14:57:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261257.f5QCv2O88127@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: Jim Bound , horape@tinuviel.compendium.net.ar, Lori Napoli , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-reply-to: Your message of Tue, 26 Jun 2001 13:00:27 +0900. <20010626040027.667D67BB@starfruit.itojun.org> Date: Tue, 26 Jun 2001 14:57:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: they raise fundamental portability issues when you implement more complex applications like BIND9 (see BIND9 doc/misc/ipv6). => we introduce the V6ONLY stuff in order to fix this. Are you saying there are still issues if: - the implementation is RFC 2553 bis compliant - the implementation has IPV6_V6ONLY as specified in the draft - the implementation has a BSD style SO_REUSEADDR ? can we issue setsockopt(IPV6_V6ONLY) after bind(2) or connect(2)? consensus seems to be NO. => this is the only item about this stuff which is not yet in the draft. It should not change the way to code applications, it is just a specification for an error/undefined behaviour case. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 07:10:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QEAudP008569 for ; Tue, 26 Jun 2001 07:10:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QEAuAN008568 for ipng-dist; Tue, 26 Jun 2001 07:10:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QEAqdP008561 for ; Tue, 26 Jun 2001 07:10:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24460 for ; Tue, 26 Jun 2001 07:10:59 -0700 (PDT) Received: from hoteldns02.stsn.com (p85.usslc13.stsn.com [208.32.226.85]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12103 for ; Tue, 26 Jun 2001 08:11:52 -0600 (MDT) Received: from starfruit.itojun.org ([10.3.37.243]) by hoteldns02.stsn.com (8.11.0/8.11.0) with SMTP id f5QEEKl14902 for ; Tue, 26 Jun 2001 08:14:20 -0600 Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 090607C3; Tue, 26 Jun 2001 23:10:51 +0900 (JST) To: Francis Dupont Cc: Jim Bound , horape@tinuviel.compendium.net.ar, Lori Napoli , ipng@sunroof.eng.sun.com In-reply-to: Francis.Dupont's message of Tue, 26 Jun 2001 14:57:02 +0200. <200106261257.f5QCv2O88127@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Tue, 26 Jun 2001 23:10:51 +0900 Message-Id: <20010626141052.090607C3@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > they raise fundamental portability issues when you implement more > complex applications like BIND9 (see BIND9 doc/misc/ipv6). >=> we introduce the V6ONLY stuff in order to fix this. Are you >saying there are still issues if: > - the implementation is RFC 2553 bis compliant > - the implementation has IPV6_V6ONLY as specified in the draft > - the implementation has a BSD style SO_REUSEADDR >? IPV6_V6ONLY is a good thing, but there still are items unclear. please re-read drafts with fresh eyes, and you'll find out. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:18:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGILdP008956 for ; Tue, 26 Jun 2001 09:18:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGILlE008955 for ipng-dist; Tue, 26 Jun 2001 09:18:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGIHdP008948 for ; Tue, 26 Jun 2001 09:18:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29995 for ; Tue, 26 Jun 2001 09:18:27 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA06950 for ; Tue, 26 Jun 2001 09:18:24 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id f5QGINi49965 for ; Tue, 26 Jun 2001 18:18:23 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA21169 for ; Tue, 26 Jun 2001 18:18:22 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id f5QGIMO89266 for ; Tue, 26 Jun 2001 18:18:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200106261618.f5QGIMO89266@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: IPv6/PPP Date: Tue, 26 Jun 2001 18:18:22 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am looking for IPv6 support in the "http://www.awfulhak.org/ppp.html" user PPP which works on FreeBSD 4.x and OpenBSD 2.x (it seems to be easy to port any system with a tun interface/device too). Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:24:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGOjdP009077 for ; Tue, 26 Jun 2001 09:24:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGOjd6009076 for ipng-dist; Tue, 26 Jun 2001 09:24:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGOfdP009069 for ; Tue, 26 Jun 2001 09:24:41 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19037 for ; Tue, 26 Jun 2001 09:24:51 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA19321 for ; Tue, 26 Jun 2001 10:24:48 -0600 (MDT) Received: from 157.54.1.52 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Jun 2001 09:24:45 -0700 (Pacific Daylight Time) Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Jun 2001 09:24:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 2553 bind semantics harms the way to AF independence Date: Tue, 26 Jun 2001 09:24:45 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2553 bind semantics harms the way to AF independence Thread-Index: AcD+OyU4AYxUctlrQ7uCNdr7rBmmqQAIK5VA From: "Brian Zill" To: X-OriginalArrivalTime: 26 Jun 2001 16:24:36.0856 (UTC) FILETIME=[7DDE9780:01C0FE5C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5QGOgdP009070 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] >> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option >> > >> > Then the IPv6 sockets would have to be explicitly >> > allowed to accept IPv4 connections. So the programs >> > that use the IPv6 centric way have to be modified a >> > bit, but the buggy implementations and the unworkable >> > one could be corrected without losing features. Just >> > making IPV6_V6ONLY default to on would have the same >> > results. >> >> I really love to see this happen (polarity change is enough). >> also, if IPv4 mapped address support becomes optional >> (explicitly) to OS implementers it would be much better. > >In hindsight I agree that the default should have been >different - forcing applications to explicitly request use of >IPv4-mapped addresses on AF_INET6 sockets. But I suspect that >folks have different opinions on the cost of changing the >default at this point in time :-( I have absolutely no problem with changing the default at this time. As several other posters have suggested, I think this would be a really good thing to do. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:37:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGbwdP009169 for ; Tue, 26 Jun 2001 09:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGbwjP009168 for ipng-dist; Tue, 26 Jun 2001 09:37:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGbsdP009161 for ; Tue, 26 Jun 2001 09:37:54 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24290 for ; Tue, 26 Jun 2001 09:38:03 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17308 for ; Tue, 26 Jun 2001 09:38:03 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.140.51) by smtp1.libero.it (5.5.025) id 3AE980E700DB2803; Tue, 26 Jun 2001 18:37:20 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 79CE128A44; Tue, 26 Jun 2001 11:33:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 787A928A35; Tue, 26 Jun 2001 11:33:57 +0200 (CEST) Date: Tue, 26 Jun 2001 11:33:57 +0200 (CEST) From: Mauro Tortonesi To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Fri, 22 Jun 2001 16:51:25 -0300, > >>>>> horape@tinuviel.compendium.net.ar said: > > >> >> for example: on linux system, if you would like to turn IPV6_V6ONLY > >> >> option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. > >> >If that changes were done, turning IPV6_V6ONLY on would not be frequently d= > >> >one. > > >> if you want to see IPv4 traffic on AF_INET socket (so that we don't > >> get confused by bogus source address, and generating bogus traffic > >> when responding) you will want to do IPV6_V6ONLY. > > > Yes, maybe a flag telling that the old behaviour should be used would be need > > to be added too. > > Then we'll see unreadable conditionals or ifdef tricks. I'd rather > prefer just skipping possible errors against multiple calls of bind(2) > for each addrinfo element returned by getaddrinfo(3), as itojun > suggested. If we take this approach, though, then we'll need one > constraint of getaddrinfo(3); it should return the AF_INET6 wildcard > address before the AF_INET one on those stacks that do not allow > conflict of an AF_INET6 wildcard socket and an AF_INET one. > (Otherwise, the already bound AF_INET socket would reject binding the > AF_INET6 one, and we would not receive IPv6 packets.) good idea. at least this behaviour for getaddrinfo (returning first :: and then 0.0.0.0) could be specified. jim, what do you think? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:38:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGcrdP009189 for ; Tue, 26 Jun 2001 09:38:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGcrOx009188 for ipng-dist; Tue, 26 Jun 2001 09:38:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGcmdP009175 for ; Tue, 26 Jun 2001 09:38:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27629 for ; Tue, 26 Jun 2001 09:38:54 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17905 for ; Tue, 26 Jun 2001 09:38:53 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.140.51) by smtp1.libero.it (5.5.025) id 3AE980E700DB28B8; Tue, 26 Jun 2001 18:38:03 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id C210B28A40; Tue, 26 Jun 2001 11:21:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id B99D328A35; Tue, 26 Jun 2001 11:21:33 +0200 (CEST) Date: Tue, 26 Jun 2001 11:21:33 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: Francis Dupont , Pekka Savola , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Jun 2001, Jim Bound wrote: > As far as the default it is you will get v4mapped on AF_INET6 unless you > set v6only sockopt. ok, but a good working of v6only sockopt can be obtained only if bind and getaddrinfo behave like on *BSD. that's the point. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:39:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGd2dP009199 for ; Tue, 26 Jun 2001 09:39:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGd2EB009198 for ipng-dist; Tue, 26 Jun 2001 09:39:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGcmdP009174 for ; Tue, 26 Jun 2001 09:38:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27645 for ; Tue, 26 Jun 2001 09:38:57 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17951 for ; Tue, 26 Jun 2001 09:38:56 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.140.51) by smtp2.libero.it (5.5.025) id 3AE981AF00D7F528; Tue, 26 Jun 2001 18:38:04 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 8C63C28A41; Tue, 26 Jun 2001 11:25:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 8606728A35; Tue, 26 Jun 2001 11:25:47 +0200 (CEST) Date: Tue, 26 Jun 2001 11:25:47 +0200 (CEST) From: Mauro Tortonesi To: Pekka Savola Cc: Jim Bound , Francis Dupont , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Pekka Savola wrote: > On Mon, 25 Jun 2001, Jim Bound wrote: > > AF_INET6 will always permit the catch only model because its been a method > > for over 6 years and customers have ported to that model. We are not > > getting rid of it now. That is not going to happen. The market has > > spoken and the early adopter deployment customers will not have their code > > broken. > > > > As far as the default it is you will get v4mapped on AF_INET6 unless you > > set v6only sockopt. > > Wouldn't it be better to have the code potentially broken _now_, when > they're (very) _early adopters_, versus in 2-3 years when *everybody's* > code would break? > > There are dangers to being an early adopter. One of them is having to > rewrite code when it becomes clear that certain method, discovered during > the early adopter phase, is not going to work in the long term. > > Better to break 1000 people's code now than 100000's in two years. > > Or are we just playing time here? If we can delay this enough, there's no > way we can get rid of mapped addresses in the next 10 years as it's going > to be used by ported apps more and more... i think pekka is right here. unfortunately, as jim has pointed out, the game may be already over now. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:47:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGlJdP009261 for ; Tue, 26 Jun 2001 09:47:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGlIVR009260 for ipng-dist; Tue, 26 Jun 2001 09:47:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGlFdP009253 for ; Tue, 26 Jun 2001 09:47:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06386 for ; Tue, 26 Jun 2001 09:47:24 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23522 for ; Tue, 26 Jun 2001 09:47:23 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5QGlLS11239 for ; Tue, 26 Jun 2001 19:47:21 +0300 Date: Tue, 26 Jun 2001 19:47:21 +0300 (EEST) From: Pekka Savola To: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Erik Nordmark wrote: > > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > > > > > Then the IPv6 sockets would have to be explicitly allowed to accept > > > IPv4 connections. So the programs that use the IPv6 centric way have > > > to be modified a bit, but the buggy implementations and the unworkable > > > one could be corrected without losing features. Just making > > > IPV6_V6ONLY default to on would have the same results. > > > > I really love to see this happen (polarity change is enough). > > also, if IPv4 mapped address support becomes optional (explicitly) > > to OS implementers it would be much better. > > In hindsight I agree that the default should have been different - forcing > applications to explicitly request use of IPv4-mapped addresses on AF_INET6 > sockets. > But I suspect that folks have different opinions on the cost of changing > the default at this point in time :-( Another point here is security, especially if overloading mapped addresses is allowed to continue (SIIT). 10 years ago all Unix vendors shipped about all services enabled by default. At some point people began to realize that it's an endless battle if users/application writers must take full care of that. So, wise vendors have changed the default from "enable everything" to "enable what's needed". Some haven't gotten it yet, or depend too heavily on old cruft, and are afraid to (possibly) break some customers who might actually be running obscure_serviced. I just hope we won't be doing the same mistake here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 09:56:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGuFdP009367 for ; Tue, 26 Jun 2001 09:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QGuEhN009366 for ipng-dist; Tue, 26 Jun 2001 09:56:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QGuBdP009359 for ; Tue, 26 Jun 2001 09:56:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08496 for ; Tue, 26 Jun 2001 09:56:20 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA21336 for ; Tue, 26 Jun 2001 10:56:18 -0600 (MDT) Received: from 157.54.9.101 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Jun 2001 09:18:15 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Jun 2001 09:18:09 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 26 Jun 2001 09:17:07 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Jun 2001 09:17:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 2553 bind semantics harms the way to AF independence Date: Tue, 26 Jun 2001 09:17:29 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC101671E21@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2553 bind semantics harms the way to AF independence Thread-Index: AcD98wSjmP/g6xMVTGOCSQjH1YkvEQAaERJg From: "Dave Thaler" To: "Jim Bound" , Cc: "Jun-ichiro itojun Hagino" , "Mauro Tortonesi" , "Francis Dupont" , X-OriginalArrivalTime: 26 Jun 2001 16:17:29.0706 (UTC) FILETIME=[7F44ACA0:01C0FE5B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5QGuBdP009360 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound: > we did suggest that there be no default for v6only (in fact I suggested > it) and no one on either side wanted that. thinking was even if one did > not get their choice then its better to have default for the users. Actually I suggested it as well, so I wouldn't have a problem with no default. Anyone who wants portable apps would just always set the option, no problem. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 11:07:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QI7fdP010067 for ; Tue, 26 Jun 2001 11:07:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QI7ff0010066 for ipng-dist; Tue, 26 Jun 2001 11:07:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QI7bdP010059 for ; Tue, 26 Jun 2001 11:07:37 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15115 for ; Tue, 26 Jun 2001 11:07:45 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21346 for ; Tue, 26 Jun 2001 11:07:43 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA29717 for ; Wed, 27 Jun 2001 03:08:43 +0900 (JST) Date: Wed, 27 Jun 2001 03:07:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: summary of discussions about the semantics of sin6_scope_id User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 190 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following is a summary of discussions about the semantics of sin6_scope_id (aka flat 32 vs 4+28 split issue) we have had in the API list. Since some of key members of this issue are (accidentally) not on the list, I think this list is the best place to get a consensus. Please note that the text below is not the conclusion, but just a memo. I'd like to hear from others about the issues on this list based on the memo, discuss further if necessary, and try to get a consensus hopefully in a week or so. Then the result will (probably) be in the next revision of the scope architecture draft. In the following memo, I'll first show you definitions of the semantics, which will fall into 3 categories. I'll then describe (a summary of) opinions about each definition that I've heard in the discussions. I tried to be fair when describing them, but if I was wrong on some points or I missed something, please point it out. DEFINITIONS We have seen 3 definitions of semantics. I call them (A) the flat 32 (B) the strict 4+28 split (C) the flexible 4+28 split respectively. (A) The flat 32 uses the whole space (i.e. 32 bits) per scope. The uniqueness of IDs are only ensured in a single scope. Both (B) and (C) embed a scope type (4 bits) into the ID space. IDs in a particular scope is specified by the remaining 28 bits. And the 28-bit ID for a particular zone must also be unique in the scope. We can choose the 28-bit ID for a particular zone in any way, but Francis showed a concrete example: the interface index of a particular interface that belongs to the zone. I'll use this definition in the following examples, with the smallest interface index in the zone as the particular one. The only difference between (B) and (C) is about the usage. In "the strict strip", - if an ID is given with a (non-unspecified) address, the ID must be in the same scope type as the address in any context (including in a sockaddr_in6 structure). - even if the accompanying address is unspecified, we do not allow a non-zero ID for specifying a particular (or any) zone of a particular scope type. "The flexible split", on the other hand, does not have any such restriction; we allow any combination of a (scoped) address and a zone ID, provided that the scope type of the ID is equal to or smaller than the scope type of the address. Examples. The following topology is described in the scope architecture draft. --------------------------------------------------------------- | a node | | | | | | | | | | | | /--------------------site1--------------------\ /--site2--\ | | | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | --------------------------------------------------------------- : | | | | : | | | | : | | | | (imaginary ================= a point- a loopback an Ethernet to-point tunnel link) link A) Using the "flat 32", the zone indices are as follows: ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5 ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4 ID(site1) = 1, ID(site2) = 2 where ID(x) means the zone identifier for the zone "x". B&C) Using the strict/flexible 4+28 split, the zone indices are ID(intf1) = 0x10000001, ID(intf2) = 0x10000002, ..., ID(intf5) = 0x10000005 ID(link1) = 0x20000001, ID(link2) = 0x20000002, ID(link3) = 0x20000004, ID(link4) = 0x20000005 ID(site1) = 0x50000001, ID(site2) = 0x50000005 (assuming scope types like the "scop" field for multicast addresses.) And, if we take (B), the strict 4+28 split, then if we have a sockaddr_in6 structure, whose sin6_addr member is "fec0::1234", then its sin6_scope_id must be in the site scope, like 0x50000001. if we have a sockaddr_in6 structure, whose sin6_addr member is in6addr_any, then its sin6_scope_id must be 0. If we take (C), the flexible split, then if we have a sockaddr_in6 structure, whose sin6_addr member is "fec0::1234", then the scope type of its sin6_scope_id can be any scope which is equal to or smaller than the site scope. if we have a sockaddr_in6 structure, whose sin6_addr member is in6addr_any, the the sin6_scope_id is in any type of scope. Example usages of the flexibility are: 1) binding to "any interface in a given scope zone". This would mean, when sa.sin6_addr = unspecified, and sa.sin6_scope_id = 0x50000001, then bind(&sa) specifies the kernel to accept any packet arrived at the interface which belongs to the site zone 1. 2) when sa.sin6_addr = fec0::1234, and sa.sin6_scope_id = 0x20000002, then sendto(&sa) specifies the kernel to send the corresponding packet to one of the interfaces in the link zone 2. 3) allow IPV6_MULTICAST_IF (and IPV6_JOIN_GROUP) to use a scope id rather than just an ifindex, to let the stack choose the best interface in a given scope zone, similar to passing 0 today. OPINIONS Opinions from those who support A (including Steve and I): A-1 It provides backward compatibility to existing implementations that use interface indices as link indices, assuming one-to-one mapping between interfaces and links. A-2 There is no chance of misusages such as specifying a site zone ID for a link-local address. A-3 Since the IDs are typically specified with a (non-unspecified) address, like in the sockaddr_in6 structure, and the accompanying address itself provides the appropriate scope type, the strict split does not have much merit. We'd rather keep it "simple" to avoid misconfiguration described in A-2. A-4 The flexible split would make comparison of two scoped addresses (in a same scope type) more complicated; we may have a chance to compare {sin6_addr = fec0::1234, sin6_scope_id = 0x50000001} and {sin6_addr = fec0::1234, sin6_scope_id = 0x20000002} which may or may not specify a same single node, and we can't just compare the scope ID part by a "simple" operator '='. A-5 It would be the most readable, especially when we use digit integers for IDs, as specified in the current scope architecture draft. (e.g. recall the fact that 0x50000001 = 1342177281). Even if we allow hex integers or a dotted notation like 5.1, the flat ID would still be the most readable, and we'll see some situations that we want to type the ID itself, not an alias name of the ID, in some configuration files or something. A-6 We've never seen realistic examples of the flexibility that the flexible split would provide. On the other hand, we will see (or even have seen) some situations where we just want to disambigute scoped addresses (with the same scope type of the address). We should implement the "advanced" flexibility in a kind of advanced API, not using a part of the basic API; sin6_scope_id. (Note: I'm probably biased, and might not be fair, in this section. I have to say that some people pointed out that some of the points were just a matter of taste, and some points did not provide much difference. Also, please make additions in the items below, and corrections to the items above.) Opinions from those who support B (including Francis and Vlad - please add if I miss anyone): B-1 It provides global uniqueness. B-2 It provides zone IDs by themselves. B-3 It has no possible conflict with the interface index space. B-4 As for the readability, we should change the current definition, so that hex integers or the dotted notation would be allowed. B-5 It can provide the backward compatibility described in A-2 above and the readability in A-5, by specifying that the scope type 0 means the same scope type of the corresponding address (assuming a non unspecified address is given). B-6 the flexibility that the flexible split would provide is a "too much" or "too clever" stuff, and should not be in the basic API (basically the same argument as A-6 above) Opinions from those who support C (including Dave and Markku - please add if I miss anyone): C-1: the same benefits as B-1 to B-3 are applied to C. C-2: the same argument as B-4 as for the readability. C-3: the example usages described in "Example usages of the flexibility" above really benefits of this approach. C-4: we should not add API knobs to implement the flexibility, because it would confuse the users. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 11:48:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QIm9dP010191 for ; Tue, 26 Jun 2001 11:48:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QIm9Oa010190 for ipng-dist; Tue, 26 Jun 2001 11:48:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QIm6dP010183 for ; Tue, 26 Jun 2001 11:48:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA00978 for ; Tue, 26 Jun 2001 11:48:14 -0700 (PDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27662 for ; Tue, 26 Jun 2001 12:49:07 -0600 (MDT) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 588D0A31; Tue, 26 Jun 2001 11:47:58 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 17767ABB for ; Tue, 26 Jun 2001 11:47:58 -0700 (PDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 02A65550; Tue, 26 Jun 2001 13:48:08 -0500 (CDT) Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id B302A4D3 for ; Tue, 26 Jun 2001 13:48:08 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id OAA0000021741; Tue, 26 Jun 2001 14:48:07 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id OAA0000078889; Tue, 26 Jun 2001 14:48:07 -0400 (EDT) Message-ID: <3B38D8E6.74EC7CA8@zk3.dec.com> Date: Tue, 26 Jun 2001 14:48:06 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: ru, en MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of discussions about the semantics of sin6_scope_id References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I guess I would prefere a combination between B and C. The thing that I like from (C) is the ability to specify a scope (top 4 bits) with the unspecified address. This offers some rather interesting flexibility that would be used in more advanced applications. I haven't considered the implications of allowing a full ID (both the '4' and the '28'). At first glance the specifying the '28' in this case may be a bit too much. The thing I disklike about (C) is that scope(sin6_scope_id) <= scope(sin6_addr). This would make it much harder to compare scoped addresses. Also looking at numerical representation like this: fec0::1%20000001 ... it just looks wrong to me. It's essentially saying that we have this site-local address in link scope. I think we could add the first flexibility of (C) to option B and not increase complexity alot. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 12:10:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QJA8dP010280 for ; Tue, 26 Jun 2001 12:10:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QJA768010279 for ipng-dist; Tue, 26 Jun 2001 12:10:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QJA3dP010272 for ; Tue, 26 Jun 2001 12:10:03 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02137 for ; Tue, 26 Jun 2001 12:10:11 -0700 (PDT) Received: from roll.mentat.com ([192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29828 for ; Tue, 26 Jun 2001 12:10:11 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA02368 for ; Tue, 26 Jun 2001 12:10:38 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id MAA05592 for ; Tue, 26 Jun 2001 12:10:39 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id MAA01191 for ipng@sunroof.eng.sun.com; Tue, 26 Jun 2001 12:12:27 -0700 (PDT) Date: Tue, 26 Jun 2001 12:12:27 -0700 (PDT) From: Tim Hartrick Message-Id: <200106261912.MAA01191@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof.eng.sun.com Tue Jun 26 01:50:32 2001 > Received: from roll.mentat.com (roll [192.88.122.129]) > by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id BAA23124 > for ; Tue, 26 Jun 2001 01:50:32 -0700 (PDT) > Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) > by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id BAA29739 > for ; Tue, 26 Jun 2001 01:50:29 -0700 (PDT) > Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) > by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16729; > Tue, 26 Jun 2001 02:49:17 -0600 (MDT) > Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) > by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06117; > Tue, 26 Jun 2001 01:49:07 -0700 (PDT) > Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) > by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lqdP007714 > for ; Tue, 26 Jun 2001 01:47:52 -0700 (PDT) > Received: (from majordomo@localhost) > by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5Q8lqiD007712 > for ipng-dist; Tue, 26 Jun 2001 01:47:52 -0700 (PDT) > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) > by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5Q8lhdP007691 > for ; Tue, 26 Jun 2001 01:47:43 -0700 (PDT) All, Everyone of BSD, Solaris, Linux and Winsock define slightly different behavior of bind(2) and SO_REUSEADDR/SO_REUSEPORT. We can certainly classify the differences but to what end? None of the differences in behavior are going to be rectified. We aren't going to arrive at a common understanding. What will happen is absurd chest beating about market share and how everyone should change their implementations to conform with whoever claims to have the larger market or better understanding of security issues or better grasp of what is "right". In fact, I see it is already happening.... All the discussions which are occuring in this thread have occurred before. The outcome of those discussions is in RFC 2553. We aren't going to achieve agreement on how bind(2) and SO_REUSEADDR/SO_REUSEPORT should behave because no implementor worth their salt is going to risk breaking applications that may depend on the particular idiosyncrasies of their implementation. It is ridculous to even suggest the idea that RFC 2553 should be thrown out simply because someone has arrived late to the party. The price of arriving late to the party is accepting the work that has come before and making your implementation conform. If you want to be in on the design you need to get to the party early. With regard to the IPV6_V6ONLY option, it made and makes little difference to me what value the option defaults to. No matter which we choose code will break. We have also had this discussion before. I see that Erik and Brian are for changing the default value to true. If that is the consensus I can live with that. It will, however, break existing code. How much and how badly depends on where you sit. It is easy for those that don't have code to be in favor of changes. Let's make a call and move on. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 15:56:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QMuadP010540 for ; Tue, 26 Jun 2001 15:56:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QMuaqs010539 for ipng-dist; Tue, 26 Jun 2001 15:56:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QMuXdP010532 for ; Tue, 26 Jun 2001 15:56:33 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19691 for ; Tue, 26 Jun 2001 15:56:41 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14924 for ; Tue, 26 Jun 2001 15:56:40 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.141.25) by smtp2.libero.it (5.5.025) id 3AE981AF00D9AFA9; Wed, 27 Jun 2001 00:56:34 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id D1CD328A41; Tue, 26 Jun 2001 19:28:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id AF1DF28A35; Tue, 26 Jun 2001 19:28:54 +0200 (CEST) Date: Tue, 26 Jun 2001 19:28:54 +0200 (CEST) From: Mauro Tortonesi To: Brian Zill Cc: Subject: RE: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Brian Zill wrote: > >From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > >> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > >> > > >> > Then the IPv6 sockets would have to be explicitly > >> > allowed to accept IPv4 connections. So the programs > >> > that use the IPv6 centric way have to be modified a > >> > bit, but the buggy implementations and the unworkable > >> > one could be corrected without losing features. Just > >> > making IPV6_V6ONLY default to on would have the same > >> > results. > >> > >> I really love to see this happen (polarity change is enough). > >> also, if IPv4 mapped address support becomes optional > >> (explicitly) to OS implementers it would be much better. > > > >In hindsight I agree that the default should have been > >different - forcing applications to explicitly request use of > >IPv4-mapped addresses on AF_INET6 sockets. But I suspect that > >folks have different opinions on the cost of changing the > >default at this point in time :-( > > I have absolutely no problem with changing the default at this time. As > several other posters have suggested, I think this would be a really > good thing to do. it seems that there are many people in favor of changing the behaviour of AF_INET6 sockets: itojun, pekka, me, horape, brian, erik. only jim and francis do not agree. is it necessary to have consensus of EVERYBODY to change something in a draft, or is 75% a sufficient percentage? -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 15:57:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QMvSdP010550 for ; Tue, 26 Jun 2001 15:57:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QMvSSb010549 for ipng-dist; Tue, 26 Jun 2001 15:57:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QMvNdP010542 for ; Tue, 26 Jun 2001 15:57:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21531 for ; Tue, 26 Jun 2001 15:57:32 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03375 for ; Tue, 26 Jun 2001 16:57:30 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.141.25) by smtp1.libero.it (5.5.025) id 3AE980E700DCE3ED; Wed, 27 Jun 2001 00:56:35 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id C7FAA28A42; Tue, 26 Jun 2001 19:40:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id C19BD28A35; Tue, 26 Jun 2001 19:40:29 +0200 (CEST) Date: Tue, 26 Jun 2001 19:40:29 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106260954.f5Q9svO87328@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Francis Dupont wrote: > In your previous mail you wrote: > > On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > > ...however, those corrections do not affect the main stream of this > > discussion. We've fully, fully discussed this (in the apifolks list), > > and have seen so many different views, and, as a consequence, could > > not reach consensus on a single unified behavior. Sad to say this, > > but I don't think we'll be able to force vendors a particular behavior > > based on a particular view of the model, like "the correct thing is to > > deprecate IPv4-mapped IPv6 addresses"... > > then why bothering to write RFC2553? if any ISV can do what he wants it > has been only a useless effort. > > your arguments don't seem to have moche sense to me. rather, the > discussion should be re-opened and, as a result, a new proposed > standard should be produced. > > > So, IMHO, the only feasible thing we can do now is to accept the > > differences of various implementations, and make a guidance of how to > > deal with the differences with a minimum effort. > > this would be a BIG mistake, IMVHO. it is imperative to produce > a standard for BSD socket extensions, or we can forget the word > "code portability" for the next 50 years... > > => some of us are old enough or learn by the hard way that to be > convinced to be in possesion of the Truth is not a strong argument. i have always believed to be quite reasonable. i am certainly not in posses of the Truth. no one is. i have only said that it would be nice to have the possibility, for the developer, of having two sockets (one AF_INET and the other AF_INET6) listening on the same port traffic of two different protocols. > Please don't reopen this discussion, to flood this mailing list > with boring messages about this won't be a successful strategy (:-). i have a deep respect for you and jim, who have ideas which are different from mine. given this, don't you think that maybe this is a discussion that could lead to interesting results? we have only to keep the discussion within boundaries (i don't like flame wars). -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 15:57:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QMvYdP010567 for ; Tue, 26 Jun 2001 15:57:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QMvYUv010566 for ipng-dist; Tue, 26 Jun 2001 15:57:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QMvTdP010552 for ; Tue, 26 Jun 2001 15:57:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25583 for ; Tue, 26 Jun 2001 15:57:33 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27226 for ; Tue, 26 Jun 2001 16:58:24 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.141.25) by smtp2.libero.it (5.5.025) id 3AE981AF00D9AFEB; Wed, 27 Jun 2001 00:57:01 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 696E428A40; Tue, 26 Jun 2001 18:58:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id F06A428A35; Tue, 26 Jun 2001 18:58:48 +0200 (CEST) Date: Tue, 26 Jun 2001 18:58:48 +0200 (CEST) From: Mauro Tortonesi To: Francis Dupont Cc: , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106260923.f5Q9NZO87198@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 26 Jun 2001, Francis Dupont wrote: > => you can use it with the V6ONLY stuff. yes, but on rfc2553-compliant system you cannot have both an AF_INET and an AF_INET6 socket listening on the same port. > => this is the standard way but with the V6ONLY way you can use the > single socket (my favorite) or the socket per IP version (Itojun's > favorite). The user shall choice his own favorite or the one which > matches the application constraints. the user can't choose anything! if he wants to listen both ipv4 and ipv6 traffic, he has to use an AF_INET6 socket with V6ONLY turned off. no other choice. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 16:01:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QN1QdP010606 for ; Tue, 26 Jun 2001 16:01:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QN1QQW010605 for ipng-dist; Tue, 26 Jun 2001 16:01:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QN1LdP010598 for ; Tue, 26 Jun 2001 16:01:21 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03502 for ; Tue, 26 Jun 2001 16:01:30 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17503 for ; Tue, 26 Jun 2001 16:01:29 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 75EA27BC; Wed, 27 Jun 2001 07:57:34 +0900 (JST) To: Mauro Tortonesi Cc: ipng@sunroof.eng.sun.com In-reply-to: mauro's message of Tue, 26 Jun 2001 18:58:48 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Wed, 27 Jun 2001 07:57:34 +0900 Message-Id: <20010626225734.75EA27BC@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> => you can use it with the V6ONLY stuff. >yes, but on rfc2553-compliant system you cannot have both an AF_INET >and an AF_INET6 socket listening on the same port. (just a picky comment) RFC2553 does not talk about the behavior when try to bind(2) to both :: and 0.0.0.0 on the same port. some systems reject bind(2) to 0.0.0.0, some does not. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 16:20:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QNKsdP010651 for ; Tue, 26 Jun 2001 16:20:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5QNKsls010650 for ipng-dist; Tue, 26 Jun 2001 16:20:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5QNKodP010643 for ; Tue, 26 Jun 2001 16:20:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07647 for ; Tue, 26 Jun 2001 16:20:59 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA20764 for ; Tue, 26 Jun 2001 17:20:57 -0600 (MDT) Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Jun 2001 09:03:43 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Jun 2001 09:05:23 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2883); Tue, 26 Jun 2001 09:04:24 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Jun 2001 09:04:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 2553 bind semantics harms the way to AF independence Date: Tue, 26 Jun 2001 09:04:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2553 bind semantics harms the way to AF independence Thread-Index: AcD+JneuFixGCHwTQ9KAzYfdums7UgAMZbxw From: "Christian Huitema" To: "Francis Dupont" , "Mauro Tortonesi" Cc: "JINMEI Tatuya / ????" , X-OriginalArrivalTime: 26 Jun 2001 16:04:44.0071 (UTC) FILETIME=[B6EA0B70:01C0FE59] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5QNKodP010644 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > then why bothering to write RFC2553? if any ISV can do what he wants it > has been only a useless effort. There is a strong case to be made that the IETF should limit itself to the definition of protocols, i.e. the bits that flow on the wire, and should not be concerned with APIs. APIs are typically determined by two factors, the function that you want to provide and the environment in which you provide it. The IETF knows a lot about what function to provide, but it generally does not know all that much about the environment. Would you still use the socket API in a firmware implementation? Would it be the same in a massively parallel machine? What about a quantum computer? API definition in the IETF is always an exception, not a norm. In fact, we may observe that RFC 2553 is an informational document, not a standard track document. It was produced by the WG in a burst of enthusiasm, but it is a strange beast when in comes to process. How does one apply the "implementation that interoperate" test? How do we progress a document and drop features that were not in fact implemented? How does it apply to hardware implementations of TCP/IP? If there are not enough compliant implementations, does one obsolete the document and forget about it? On the other hand, the subject makes for volume of exchanges on the WG list, which gives us a comforting sense of liveness... -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 20:50:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R3oodP010930 for ; Tue, 26 Jun 2001 20:50:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R3onsr010929 for ipng-dist; Tue, 26 Jun 2001 20:50:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R3okdP010922 for ; Tue, 26 Jun 2001 20:50:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14232 for ; Tue, 26 Jun 2001 20:50:55 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA09817 for ; Tue, 26 Jun 2001 20:50:54 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04473; Tue, 26 Jun 2001 23:50:33 -0400 Date: Tue, 26 Jun 2001 23:50:33 -0400 (EDT) From: Jim Bound To: Pekka Savola Cc: Jun-ichiro itojun Hagino , Mauro Tortonesi , Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by sunroof.eng.sun.com id f5R3okdP010923 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I was directly speaking of implementations that make billions of dollars. That is not Linux or BSD. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Pekka Savola wrote: > On Mon, 25 Jun 2001, Jim Bound wrote: > > we do not document product platform differences in the IETF. > > > > but here is how the market will work. > > > > the market picks a market leader. today that market leader for most of IP > > stuff for "Servers" is Sun Microsystems (not all but most if you look at > > market share). For the client its Microsoft. > > [ I don't want to start an OS flamewar here (or anywhere else), but I > think this has to be clarified as it is important in your argumentation. ] > > I'm sorry, but the above for servers seems to be explainable only by > assuming some interesting definition for "market leader". Does it have to > be sold for an expensive price to qualify? > > I don't have the detailed numbers handy, but a google search pointed to, > for example: > > http://news.cnet.com/news/0-1003-200-4979275.html?tag=prntfr > (IDC Server OS market share in 2000) > > Windows: 41% > Linux: 27% > Netware: 17% > Unix: 14% > Other: 2% > > For example, Linux is about twice as popular as Solaris, HP-UX, Aix, > Tru64, etc. *combined*. > > Granted these are for all kinds of servers, but give some figure for > popularity. > > For small to medium-sized IP servers, I couldn't find any statistics but > I'd estimate: > > 40% BSD + Linux > 25% Solaris > 20% Windows > 15% Rest > > (personally I've a feeling that BSD+Linux should have a lot higher > percentage, but I tried to be unbiased) > > Large IP servers (GB's of memory, etc.) are a small minority of all IP > server and should not spell out the way we're heading. > > Lies, damned lies, statistics etc. aside, I think you can _at least_ > safely assume that free operating systems are a major, if not dominant, > player in IP server markets. > > Please open the windows of your office and look outside :-) > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:11:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4BbdP010955 for ; Tue, 26 Jun 2001 21:11:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4BaIT010954 for ipng-dist; Tue, 26 Jun 2001 21:11:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4BXdP010947 for ; Tue, 26 Jun 2001 21:11:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06744 for ; Tue, 26 Jun 2001 21:11:42 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA00974 for ; Tue, 26 Jun 2001 22:12:37 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04253; Wed, 27 Jun 2001 00:11:32 -0400 Date: Wed, 27 Jun 2001 00:11:32 -0400 (EDT) From: Jim Bound To: Erik Nordmark Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jinmei, > > > Just to make it sure, if you mean "accepting IPv4 packets on an > > AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in > > 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable > > the model by default. > > What aspect of this do you believe is not there is Solaris? > Solaris by default accepts IPv4 packets on an AF_INET6 socket bound to > in6addr_any, so there must be some sutble detail that you're referring to. > So does Compaq T64 UNIX. The point is that we are both shipping products that code is be developed on. That customers plan on using. I am not hearing strong enough arguments to break existing products on an API that has 6 years and at least 100's of man years invested in the design and the model for programming. From very bright people who have written this code and shipped it into production operating systems. Thats running code test par excellence in this community. Also I have not heard one ISV complain about the defaults. I still think we made the correct decision. I wish I could capture a 2 hour conversation Jack and I had on this and we both wrote our versions of the code real time in a room. Both presented all the arguments many we are hearing now. What the bottom line is thats supports the model in 2553 is that IPv6 is not an orthogonal address family to IPv4 but an extension. The conceptual model of AF independence is an illusion if one considers the transitions ISVs will have to define. Some will force V6ONLY and we added that option. But the default is to treat IPv4 and IPv6 as a cohesive abstraction that can be programmed inline once using only AF_INET6. The other view can be supported but yes to use it one must do a setsockopt in the code. I think we made the correct decision in 1995. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:13:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4DBdP010972 for ; Tue, 26 Jun 2001 21:13:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4DAQn010971 for ipng-dist; Tue, 26 Jun 2001 21:13:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4D7dP010964 for ; Tue, 26 Jun 2001 21:13:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16140 for ; Tue, 26 Jun 2001 21:13:16 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA02067 for ; Tue, 26 Jun 2001 22:14:11 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA03562; Wed, 27 Jun 2001 00:13:08 -0400 Date: Wed, 27 Jun 2001 00:13:08 -0400 (EDT) From: Jim Bound To: Pekka Savola Cc: Erik Nordmark , Jun-ichiro itojun Hagino , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have passed the point of no return as far as real products are concerned. A patch will not work on the OS's. Nor is it justified. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Pekka Savola wrote: > On Tue, 26 Jun 2001, Erik Nordmark wrote: > > > > >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > > > > > > > Then the IPv6 sockets would have to be explicitly allowed to accept > > > > IPv4 connections. So the programs that use the IPv6 centric way have > > > > to be modified a bit, but the buggy implementations and the unworkable > > > > one could be corrected without losing features. Just making > > > > IPV6_V6ONLY default to on would have the same results. > > > > > > I really love to see this happen (polarity change is enough). > > > also, if IPv4 mapped address support becomes optional (explicitly) > > > to OS implementers it would be much better. > > > > In hindsight I agree that the default should have been different - forcing > > applications to explicitly request use of IPv4-mapped addresses on AF_INET6 > > sockets. > > But I suspect that folks have different opinions on the cost of changing > > the default at this point in time :-( > > What do you suspect the cost would be in 2-3 years? > > I don't think the _current_ amount of IPv6 applications is that huge. > Almost all of these are simple tools by OS vendors, or open source. I > don't think the change would be too big _now_, especially if the change > was detected by people who don't necessarily read RFC's (e.g. compilation > fail => forced to look at issue and spend an hour thinking about it). > > IMO, we haven't passed the point of no return yet. In 2-3 years we have. > And hindsight then won't be fun. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:18:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4I7dP010991 for ; Tue, 26 Jun 2001 21:18:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4I6DS010990 for ipng-dist; Tue, 26 Jun 2001 21:18:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4I3dP010983 for ; Tue, 26 Jun 2001 21:18:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07332 for ; Tue, 26 Jun 2001 21:18:13 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA06153 for ; Tue, 26 Jun 2001 22:19:05 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA05063; Wed, 27 Jun 2001 00:17:55 -0400 Date: Wed, 27 Jun 2001 00:17:55 -0400 (EDT) From: Jim Bound To: Dave Thaler Cc: horape@tinuviel.compendium.net.ar, Jun-ichiro itojun Hagino , Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com Subject: RE: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC101671E21@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yep I am still with you on this one but if it ever happen we have to permit a transition. I think the argument was now. why do this to the programmer cause we could not pick a default. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Dave Thaler wrote: > Jim Bound: > > we did suggest that there be no default for v6only (in fact I > suggested > > it) and no one on either side wanted that. thinking was even if one > did > > not get their choice then its better to have default for the users. > > Actually I suggested it as well, so I wouldn't have a problem with no > default. Anyone who wants portable apps would just always set the > option, no problem. > > -Dave > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:19:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4JudP011008 for ; Tue, 26 Jun 2001 21:19:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4Jtf5011007 for ipng-dist; Tue, 26 Jun 2001 21:19:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4JqdP011000 for ; Tue, 26 Jun 2001 21:19:52 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16800 for ; Tue, 26 Jun 2001 21:20:01 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA01966 for ; Tue, 26 Jun 2001 21:20:00 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04246; Wed, 27 Jun 2001 00:19:30 -0400 Date: Wed, 27 Jun 2001 00:19:30 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Francis Dupont , Pekka Savola , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this api was always based on bsd and still is. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Mauro Tortonesi wrote: > On Mon, 25 Jun 2001, Jim Bound wrote: > > > As far as the default it is you will get v4mapped on AF_INET6 unless you > > set v6only sockopt. > > ok, but a good working of v6only sockopt can be obtained only if bind > and getaddrinfo behave like on *BSD. that's the point. > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:32:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4WCdP011080 for ; Tue, 26 Jun 2001 21:32:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4WCtE011079 for ipng-dist; Tue, 26 Jun 2001 21:32:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4W8dP011072 for ; Tue, 26 Jun 2001 21:32:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06660 for ; Tue, 26 Jun 2001 21:32:18 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id WAA18624 for ; Tue, 26 Jun 2001 22:33:13 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA31254; Wed, 27 Jun 2001 00:32:05 -0400 Date: Wed, 27 Jun 2001 00:32:05 -0400 (EDT) From: Jim Bound To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com Subject: Re: summary of discussions about the semantics of sin6_scope_id In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk that was very useful thank you. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Wed, 27 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > The following is a summary of discussions about the semantics of > sin6_scope_id (aka flat 32 vs 4+28 split issue) we have had in the API > list. Since some of key members of this issue are (accidentally) not > on the list, I think this list is the best place to get a consensus. > > Please note that the text below is not the conclusion, but just a > memo. I'd like to hear from others about the issues on this list > based on the memo, discuss further if necessary, and try to get a > consensus hopefully in a week or so. Then the result will (probably) > be in the next revision of the scope architecture draft. > > In the following memo, I'll first show you definitions of the > semantics, which will fall into 3 categories. I'll then describe (a > summary of) opinions about each definition that I've heard in the > discussions. I tried to be fair when describing them, but if I was > wrong on some points or I missed something, please point it out. > > DEFINITIONS > > We have seen 3 definitions of semantics. I call them > (A) the flat 32 > (B) the strict 4+28 split > (C) the flexible 4+28 split > respectively. > > (A) The flat 32 uses the whole space (i.e. 32 bits) per scope. The > uniqueness of IDs are only ensured in a single scope. > > Both (B) and (C) embed a scope type (4 bits) into the ID space. IDs > in a particular scope is specified by the remaining 28 bits. And the > 28-bit ID for a particular zone must also be unique in the scope. > We can choose the 28-bit ID for a particular zone in any way, but > Francis showed a concrete example: the interface index of a particular > interface that belongs to the zone. I'll use this definition in the > following examples, with the smallest interface index in the zone as > the particular one. > > The only difference between (B) and (C) is about the usage. In "the > strict strip", > - if an ID is given with a (non-unspecified) address, the ID must be > in the same scope type as the address in any context (including in a > sockaddr_in6 structure). > - even if the accompanying address is unspecified, we do not allow a > non-zero ID for specifying a particular (or any) zone of a particular > scope type. > > "The flexible split", on the other hand, does not have any such > restriction; we allow any combination of a (scoped) address and a zone > ID, provided that the scope type of the ID is equal to or smaller than > the scope type of the address. > > Examples. > > The following topology is described in the scope architecture draft. > > --------------------------------------------------------------- > | a node | > | | > | | > | | > | | > | | > | /--------------------site1--------------------\ /--site2--\ | > | | > | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | > | | > | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | > --------------------------------------------------------------- > : | | | | > : | | | | > : | | | | > (imaginary ================= a point- a > loopback an Ethernet to-point tunnel > link) link > > A) Using the "flat 32", the zone indices are as follows: > > ID(intf1) = 1, ID(intf2) = 2, ..., ID(intf5) = 5 > ID(link1) = 1, ID(link2) = 2, ..., ID(link4) = 4 > ID(site1) = 1, ID(site2) = 2 > > where ID(x) means the zone identifier for the zone "x". > > B&C) Using the strict/flexible 4+28 split, the zone indices are > > ID(intf1) = 0x10000001, ID(intf2) = 0x10000002, ..., ID(intf5) = 0x10000005 > ID(link1) = 0x20000001, ID(link2) = 0x20000002, > ID(link3) = 0x20000004, ID(link4) = 0x20000005 > ID(site1) = 0x50000001, ID(site2) = 0x50000005 > > (assuming scope types like the "scop" field for multicast addresses.) > > And, if we take (B), the strict 4+28 split, then > if we have a sockaddr_in6 structure, whose sin6_addr member is > "fec0::1234", then its sin6_scope_id must be in the site scope, like > 0x50000001. > if we have a sockaddr_in6 structure, whose sin6_addr member is > in6addr_any, then its sin6_scope_id must be 0. > > If we take (C), the flexible split, then > if we have a sockaddr_in6 structure, whose sin6_addr member is > "fec0::1234", then the scope type of its sin6_scope_id can be any > scope which is equal to or smaller than the site scope. > if we have a sockaddr_in6 structure, whose sin6_addr member is > in6addr_any, the the sin6_scope_id is in any type of scope. > > Example usages of the flexibility are: > > 1) binding to "any interface in a given scope zone". This would mean, > when sa.sin6_addr = unspecified, and sa.sin6_scope_id = 0x50000001, > then bind(&sa) specifies the kernel to accept any packet arrived at > the interface which belongs to the site zone 1. > 2) when sa.sin6_addr = fec0::1234, and sa.sin6_scope_id = > 0x20000002, then sendto(&sa) specifies the kernel to send the > corresponding packet to one of the interfaces in the link zone 2. > 3) allow IPV6_MULTICAST_IF (and IPV6_JOIN_GROUP) to use a scope > id rather than just an ifindex, to let the stack choose the > best interface in a given scope zone, similar to passing > 0 today. > > OPINIONS > > Opinions from those who support A (including Steve and I): > > A-1 It provides backward compatibility to existing implementations that > use interface indices as link indices, assuming one-to-one mapping > between interfaces and links. > A-2 There is no chance of misusages such as specifying a site zone ID > for a link-local address. > A-3 Since the IDs are typically specified with a (non-unspecified) > address, like in the sockaddr_in6 structure, and the accompanying > address itself provides the appropriate scope type, the strict > split does not have much merit. We'd rather keep it "simple" to > avoid misconfiguration described in A-2. > A-4 The flexible split would make comparison of two scoped addresses > (in a same scope type) more complicated; we may have a > chance to compare {sin6_addr = fec0::1234, sin6_scope_id = > 0x50000001} and {sin6_addr = fec0::1234, sin6_scope_id = 0x20000002} > which may or may not specify a same single node, and we can't just > compare the scope ID part by a "simple" operator '='. > A-5 It would be the most readable, especially when we use digit integers > for IDs, as specified in the current scope architecture draft. > (e.g. recall the fact that 0x50000001 = 1342177281). Even if we > allow hex integers or a dotted notation like 5.1, the flat ID > would still be the most readable, and we'll see some situations > that we want to type the ID itself, not an alias name of the ID, > in some configuration files or something. > A-6 We've never seen realistic examples of the flexibility that the > flexible split would provide. On the other hand, we will see (or > even have seen) some situations where we just want to disambigute > scoped addresses (with the same scope type of the address). We > should implement the "advanced" flexibility in a kind of advanced > API, not using a part of the basic API; sin6_scope_id. > > (Note: I'm probably biased, and might not be fair, in this section. I > have to say that some people pointed out that some of the points were > just a matter of taste, and some points did not provide much > difference. Also, please make additions in the items below, and > corrections to the items above.) > > Opinions from those who support B (including Francis and Vlad - please > add if I miss anyone): > > B-1 It provides global uniqueness. > B-2 It provides zone IDs by themselves. > B-3 It has no possible conflict with the interface index space. > B-4 As for the readability, we should change the current definition, > so that hex integers or the dotted notation would be allowed. > B-5 It can provide the backward compatibility described in A-2 above and > the readability in A-5, by specifying that the scope type 0 means > the same scope type of the corresponding address (assuming a non > unspecified address is given). > B-6 the flexibility that the flexible split would provide is a "too > much" or "too clever" stuff, and should not be in the basic API > (basically the same argument as A-6 above) > > Opinions from those who support C (including Dave and Markku - please > add if I miss anyone): > > C-1: the same benefits as B-1 to B-3 are applied to C. > C-2: the same argument as B-4 as for the readability. > C-3: the example usages described in "Example usages of the > flexibility" above really benefits of this approach. > C-4: we should not add API knobs to implement the flexibility, because > it would confuse the users. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:40:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4endP011120 for ; Tue, 26 Jun 2001 21:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4em3R011119 for ipng-dist; Tue, 26 Jun 2001 21:40:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4ejdP011112 for ; Tue, 26 Jun 2001 21:40:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07249 for ; Tue, 26 Jun 2001 21:40:55 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA16757 for ; Tue, 26 Jun 2001 22:40:50 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04057; Wed, 27 Jun 2001 00:40:44 -0400 Date: Wed, 27 Jun 2001 00:40:44 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Brian Zill , ipng@sunroof.eng.sun.com Subject: RE: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maruo, OK I will do solicit equal numbers who want it to stay the same. And no one said that it was a good idea. I think being late to the party does not give one more rights than those that took the risk either. Add the two other authors on 2553 in favor and I will go get 10 other implementors to say don't change it and I will get people in Sun who don't agree with Erik and we can do what Tim said and rehash this again for the 16th time. And I can find people in compaq who disagree with me and agree with Erik. Its a gigantic circle. Also do you know how many times those of us early to the party ported the base apps for IP because of working this API. I had to port two apps 3 times. I did not mind we were adding technical value. Like getaddrinfo. This is not the case here its style. And there is running code. The AF indepence point is illusion. We don't change RFCs because of illusion esp the principles of those RFCs. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Mauro Tortonesi wrote: > On Tue, 26 Jun 2001, Brian Zill wrote: > > > >From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > >> >Deprecate IPV6_V6ONLY, add IPV6_ACCEPTV4MAPPED option > > >> > > > >> > Then the IPv6 sockets would have to be explicitly > > >> > allowed to accept IPv4 connections. So the programs > > >> > that use the IPv6 centric way have to be modified a > > >> > bit, but the buggy implementations and the unworkable > > >> > one could be corrected without losing features. Just > > >> > making IPV6_V6ONLY default to on would have the same > > >> > results. > > >> > > >> I really love to see this happen (polarity change is enough). > > >> also, if IPv4 mapped address support becomes optional > > >> (explicitly) to OS implementers it would be much better. > > > > > >In hindsight I agree that the default should have been > > >different - forcing applications to explicitly request use of > > >IPv4-mapped addresses on AF_INET6 sockets. But I suspect that > > >folks have different opinions on the cost of changing the > > >default at this point in time :-( > > > > I have absolutely no problem with changing the default at this time. As > > several other posters have suggested, I think this would be a really > > good thing to do. > > it seems that there are many people in favor of changing the behaviour > of AF_INET6 sockets: itojun, pekka, me, horape, brian, erik. > only jim and francis do not agree. is it necessary to have consensus > of EVERYBODY to change something in a draft, or is 75% a sufficient > percentage? > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:45:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4jodP011140 for ; Tue, 26 Jun 2001 21:45:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4jmW5011139 for ipng-dist; Tue, 26 Jun 2001 21:45:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4jidP011132 for ; Tue, 26 Jun 2001 21:45:45 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA07555 for ; Tue, 26 Jun 2001 21:45:55 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA06236 for ; Tue, 26 Jun 2001 21:45:54 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA04974; Wed, 27 Jun 2001 00:45:43 -0400 Date: Wed, 27 Jun 2001 00:45:43 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Francis Dupont , itojun@iijlab.net, horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => you can use it with the V6ONLY stuff. > > yes, but on rfc2553-compliant system you cannot have both an AF_INET > and an AF_INET6 socket listening on the same port. Sure you can. By using V6ONLY. Thats the point of the option. It is just you must set it via setsocopt. With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one using AF_INET and the other AF_INET6. Any IPv4 addreses entering the system will not be permitted to reach any AF_INET6 socket. This permits the shared port space model. > > => this is the standard way but with the V6ONLY way you can use the > > single socket (my favorite) or the socket per IP version (Itojun's > > favorite). The user shall choice his own favorite or the one which > > matches the application constraints. > > the user can't choose anything! if he wants to listen both ipv4 and ipv6 > traffic, he has to use an AF_INET6 socket with V6ONLY turned off. > no other choice. That is correct because its not the default. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:46:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4kedP011159 for ; Tue, 26 Jun 2001 21:46:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4kekQ011158 for ipng-dist; Tue, 26 Jun 2001 21:46:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4kadP011151 for ; Tue, 26 Jun 2001 21:46:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA09339 for ; Tue, 26 Jun 2001 21:46:46 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA19689 for ; Tue, 26 Jun 2001 22:46:44 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27164; Wed, 27 Jun 2001 00:46:41 -0400 Date: Wed, 27 Jun 2001 00:46:41 -0400 (EDT) From: Jim Bound To: Jun-ichiro itojun Hagino Cc: Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010626225734.75EA27BC@starfruit.itojun.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and it should not but an implementation that does not permit this is not optimal. we cannot force this behavior on implementors either. thats why it is not in 2553. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Wed, 27 Jun 2001, Jun-ichiro itojun Hagino wrote: > > >> => you can use it with the V6ONLY stuff. > >yes, but on rfc2553-compliant system you cannot have both an AF_INET > >and an AF_INET6 socket listening on the same port. > > (just a picky comment) RFC2553 does not talk about the behavior > when try to bind(2) to both :: and 0.0.0.0 on the same port. some > systems reject bind(2) to 0.0.0.0, some does not. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 21:57:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4vJdP011176 for ; Tue, 26 Jun 2001 21:57:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R4vJ2S011175 for ipng-dist; Tue, 26 Jun 2001 21:57:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R4vFdP011168 for ; Tue, 26 Jun 2001 21:57:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10090 for ; Tue, 26 Jun 2001 21:57:25 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA24948 for ; Tue, 26 Jun 2001 22:57:23 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA05163; Wed, 27 Jun 2001 00:57:14 -0400 Date: Wed, 27 Jun 2001 00:57:14 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I "think" this is supported now.........but I need to check...... /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Tue, 26 Jun 2001, Mauro Tortonesi wrote: > On Mon, 25 Jun 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > > > >>>>> On Fri, 22 Jun 2001 16:51:25 -0300, > > >>>>> horape@tinuviel.compendium.net.ar said: > > > > >> >> for example: on linux system, if you would like to turn IPV6_V6ONLY > > >> >> option on, you can only accept IPv6 traffic with getaddrinfo(3) loop. > > >> >If that changes were done, turning IPV6_V6ONLY on would not be frequently d= > > >> >one. > > > > >> if you want to see IPv4 traffic on AF_INET socket (so that we don't > > >> get confused by bogus source address, and generating bogus traffic > > >> when responding) you will want to do IPV6_V6ONLY. > > > > > Yes, maybe a flag telling that the old behaviour should be used would be need > > > to be added too. > > > > Then we'll see unreadable conditionals or ifdef tricks. I'd rather > > prefer just skipping possible errors against multiple calls of bind(2) > > for each addrinfo element returned by getaddrinfo(3), as itojun > > suggested. If we take this approach, though, then we'll need one > > constraint of getaddrinfo(3); it should return the AF_INET6 wildcard > > address before the AF_INET one on those stacks that do not allow > > conflict of an AF_INET6 wildcard socket and an AF_INET one. > > (Otherwise, the already bound AF_INET socket would reject binding the > > AF_INET6 one, and we would not receive IPv6 packets.) > > good idea. at least this behaviour for getaddrinfo (returning first :: and > then 0.0.0.0) could be specified. jim, what do you think? > > -- > Aequam memento rebus in arduis servare mentem... > > Mauro Tortonesi mauro@ferrara.linux.it > Ferrara Linux User Group http://www.ferrara.linux.it > Project6 - IPv6 for Linux http://project6.ferrara.linux.it > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 26 23:48:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R6mrdP011339 for ; Tue, 26 Jun 2001 23:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R6mr4d011338 for ipng-dist; Tue, 26 Jun 2001 23:48:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R6mndP011331 for ; Tue, 26 Jun 2001 23:48:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15520 for ; Tue, 26 Jun 2001 23:48:58 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24758 for ; Wed, 27 Jun 2001 00:48:56 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.1/8.11.1) with ESMTP id f5R6mDs25540; Wed, 27 Jun 2001 09:48:14 +0300 Date: Wed, 27 Jun 2001 09:48:13 +0300 (EEST) From: Pekka Savola To: Jim Bound cc: Jun-ichiro itojun Hagino , Mauro Tortonesi , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Jun 2001, Jim Bound wrote: > and it should not but an implementation that does not permit this is not > optimal. we cannot force this behavior on implementors either. thats why > it is not in 2553. The API is informational document anyway. It would be nice is this kind of implementation gotcha's would be noted (no need to force a "proper" behaviour) so all people would realize a possible problem area. :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 01:35:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R8ZHdP011531 for ; Wed, 27 Jun 2001 01:35:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R8ZHhO011530 for ipng-dist; Wed, 27 Jun 2001 01:35:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R8ZCdP011523 for ; Wed, 27 Jun 2001 01:35:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23759 for ; Wed, 27 Jun 2001 01:35:23 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02002 for ; Wed, 27 Jun 2001 02:36:16 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA04521 for ; Wed, 27 Jun 2001 17:36:21 +0900 (JST) Date: Wed, 27 Jun 2001 17:35:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Wed_Jun_27_17:35:16_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 87 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Wed_Jun_27_17:35:16_2001-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 26 Jun 2001 14:30:05 +0200 (CEST), >>>>> Erik Nordmark said: >> Just to make it sure, if you mean "accepting IPv4 packets on an >> AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in >> 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable >> the model by default. > What aspect of this do you believe is not there is Solaris? > Solaris by default accepts IPv4 packets on an AF_INET6 socket bound to > in6addr_any, so there must be some sutble detail that you're referring to. Umm, then I may have misunderstood a former discussion about itojun's very 1st bindtest questionnaire (around August 2000). Perhaps I misunderstood the fact that Solaris supported separate port space for IPv4 and IPv6. Sorry, I should've been more careful when talking about others' implementation. By the way, I'm still collecting the differences among implementations (see the attached message, and the latest version contains a test to see which type of socket accepts which type of pakcets.) Could someone try the test on Solaris (and of course other implementations that has not been tested), and send the result to me, please? Then I'll never misunderstand such fundamental point. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Jun_27_17:35:16_2001-1 Content-Type: message/rfc822 Date: Wed, 09 May 2001 08:24:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: users@ipv6.org, ipng@sunroof.eng.sun.com Subject: questionnaire: bind(2) (and IPV6_V6ONLY) behavior User-Agent: Wanderlust/2.5.8 (Smooth) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Hello, (sorry for cross-posting). I'm now looking at how each IPv6 implementation is friendly with bind9, especially on the bind(2) system call ordering issues. As the first step, I'd like to collect differences among implementations using some test scripts. So, if you have time, could you spend some time to do the test on your system(s)? The test tool is freely available at the following URL: http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/ and the results so far at http://www.kame.net/newsletter/20010504/ Here is a step by step instruction of the test: - compile bindtest (see Makefile) - run test.sh like this: % sh test.sh myplatform.txt - send myplatform.txt to me, with exact indication of OS name/version number/build date/whatever I hear that some systems have already supported a new IPv6 socket option "IPV6_V6ONLY". I'm particularly interested in the results on such systems (the latest test.sh contains some tests with the option). We'll basically put the results on the URL above, so that everyone can refer to it. If you can do tests but do not want to make the result open, please explicitly say so when sending the result. Thanks in advance, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Jun_27_17:35:16_2001-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 01:47:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R8l6dP011571 for ; Wed, 27 Jun 2001 01:47:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R8l6VX011570 for ipng-dist; Wed, 27 Jun 2001 01:47:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R8l1dP011563 for ; Wed, 27 Jun 2001 01:47:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24607 for ; Wed, 27 Jun 2001 01:47:12 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA17189 for ; Wed, 27 Jun 2001 01:47:10 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id RAA04582; Wed, 27 Jun 2001 17:47:58 +0900 (JST) Date: Wed, 27 Jun 2001 17:46:52 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <200106260827.f5Q8RGO86850@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200106260827.f5Q8RGO86850@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 37 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 26 Jun 2001 10:27:16 +0200, >>>>> Francis Dupont said: > Just to make it sure, if you mean "accepting IPv4 packets on an > AF_INET6 socket as IPv4-mapped IPv6 addresses" by "the model in > 2553", Solaris does not follow the model, AFAIK. Also, NetBSD disable > the model by default. > => I agree with the definition of the model... and any implementation > which doesn't follow it or disables it by default is not compliant. > We can't support every not compliant implementations just because > there are too many ways to be not compliant so your argument (we have > to support everything) is not admissible: AF independent coding style > is perhaps better but we haven't to enforce it. I don't oppose to your opinion above, but I don't intend to force application programmers to be friendly with the "non-compliant" systems. I just want to understand the differences among the implementations on the standpoint that - there are surely "non-compliant" systems. - they (the developers of the systems) have their own policy not to be compliant (e.g. security issues), and will never change their policy. - still, I have to write some applications including these "non-compliant" systems for various reasons such as users' requests. Perhaps the message of mine above sounded too strong, but I don't intend to force my opinion on others as an admissible one. I just described the current reality, and am wondering how I can deal with the differences as a single programmer who has to write code for both "compliant" and "non-compliant" systems. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 02:03:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R93UdP011649 for ; Wed, 27 Jun 2001 02:03:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5R93UXs011648 for ipng-dist; Wed, 27 Jun 2001 02:03:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5R93PdP011641 for ; Wed, 27 Jun 2001 02:03:25 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29871 for ; Wed, 27 Jun 2001 02:03:36 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27770 for ; Wed, 27 Jun 2001 02:03:34 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA04712 for ; Wed, 27 Jun 2001 18:04:41 +0900 (JST) Date: Wed, 27 Jun 2001 18:03:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200106261007.f5QA7XO87396@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200106261007.f5QA7XO87396@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 26 Jun 2001 12:07:33 +0200, >>>>> Francis Dupont said: > The most difficult issue would be the one for extension headers. > According to a recent discussion about MIP6 issues, the API should be > flexible enough to send/receive extension headers in any order, whereas > rfc2292bis basically assumes the recommended order of the headers > specified in RFC2460. Since it could be a fundamental change of the > API spec, I'm not sure if we can get a consensus so smoothly. > Anyways, I'll raise this issue later in a separate thread. > => this is a deep change but not in a very used part of the spec so > perhaps we should split the advanced API into two parts in order to > be able to publish a document soon? Well, actually, I was thinking about the same idea. If we can split this part, things will go quite smoothly. How do others think of this? > If possible, I'd like to see the next revision of the draft before the > next IETF meeting in London. > => two procedural questions: > - is the change of the name of the working group makes the counter to > restart at 0? I don't think so, but I don't have the authoritative answer for this question... > - if we split the document into two parts, can you keep the name? > I.e. is the deadline 13 July or not? I'm not sure if this is acceptable, but I think we would be able to keep the same draft name for the easier part (i.e. rfc2292bis-02 - extension header related parts), just like when we separated jumbo gram issues from the basic specification of IPv6. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 05:25:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RCPBdP011814 for ; Wed, 27 Jun 2001 05:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RCPABG011813 for ipng-dist; Wed, 27 Jun 2001 05:25:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RCP7dP011806 for ; Wed, 27 Jun 2001 05:25:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24765 for ; Wed, 27 Jun 2001 05:25:16 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26388 for ; Wed, 27 Jun 2001 06:26:10 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5RCP1029747 for ; Wed, 27 Jun 2001 08:25:01 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 27 Jun 2001 08:25:05 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N43SNCJQ; Wed, 27 Jun 2001 08:25:05 -0400 Received: from nortelnetworks.com (deathvalley.us.nortel.com [47.141.233.58]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9FPSD3; Wed, 27 Jun 2001 08:25:06 -0400 Message-ID: <3B39D08C.79798429@nortelnetworks.com> Date: Wed, 27 Jun 2001 08:24:44 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: updated unicast-prefix-based multicast draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, I have updated the above draft based on IESG comments. Due to the number of changes, the AD's would like to solicit working group comments on them. One big change is the removal of the IANA section from this document and putting it in the corresponding MALLOC WG companion document. If you cannot wait for the I-D editor's announcement, the draft is available at the following URL: http://www.innovationslab.net/~haberman/draft-ietf-ipngwg-uni-based-mcast-02.txt - Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 06:23:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RDNidP011890 for ; Wed, 27 Jun 2001 06:23:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RDNiBY011889 for ipng-dist; Wed, 27 Jun 2001 06:23:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RDNedP011882 for ; Wed, 27 Jun 2001 06:23:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22788 for ; Wed, 27 Jun 2001 06:23:49 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01837 for ; Wed, 27 Jun 2001 06:23:47 -0700 (PDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA122912; Wed, 27 Jun 2001 09:16:18 -0500 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5RDNKU73104; Wed, 27 Jun 2001 09:23:21 -0400 Subject: Re: RFC 2553 bind semantics harms the way to AF independence To: Jim Bound Cc: Francis Dupont , horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com, itojun@iijlab.net, Mauro Tortonesi X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Wed, 27 Jun 2001 09:22:26 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 06/27/2001 09:23:22 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From my reading of 2553bis, there seem to be at least two ways this can be implemented (not counting the semantic changes being proposed): - The IPv4 address space is part of (a subset of, actually) the IPv6 address space. With this approach, 0.0.0.0 can be thought of as a more specific address in the combined address space than the IPv6 unspecified address ::. If an application binds to ::, then it will receive all traffic (IPv4 and IPv6). Only if IPV6_V6ONLY is set will it not receive IPv4 traffic. A second application can bind to a specific IPv6 address (say fec0::1) and begin to receive traffic for that specific IPv6 address while all other IPv6 traffic is received by the application which bound to ::. In the same manner, a second application can bind to 0.0.0.0 and it will begin to receive all IPv4 traffic, while the IPv6 traffic continues to be received by the initial application. This happens irrespective of whether IPV6_V6ONLY is set. The basic rationale behind this is 0.0.0.0 is, when encoded in IPv6 format (::ffff:0.0.0.0), is a more specific address than ::, much in the same way that fec0::1 was in the example above, and should be treated in the same way. - The IPv4 address space is separate from the IPv6 address space. When an application binds to ::, it is the equivalent of binding to the IPv6 unspecified address and the IPv4 equivalent, 0.0.0.0. As before, a second application can bind to a specific IPv6 address (say fec0::1) and begin to receive traffic for that specific IPv6 address while all other IPv6 traffic is received by the application which bound to ::. However, a second application can only bind to 0.0.0.0 if the first application has set IPV6_V6ONLY. This is because the first application is already (conceptually) listening on 0.0.0.0. 2553 doesn't seem to specify which is the correct behavior. We've implemented the second approach, and it sounds like several others (Jim included if I'm reading it right) have as well. Roy On Wednesday, 06/27/2001 at 12:45 AST, Jim Bound wrote: > > > => you can use it with the V6ONLY stuff. > > > > yes, but on rfc2553-compliant system you cannot have both an AF_INET > > and an AF_INET6 socket listening on the same port. > > Sure you can. By using V6ONLY. Thats the point of the option. It is > just you must set it via setsocopt. > > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one > using AF_INET and the other AF_INET6. > > Any IPv4 addreses entering the system will not be permitted to reach any > AF_INET6 socket. > > This permits the shared port space model. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 06:27:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RDR5dP011912 for ; Wed, 27 Jun 2001 06:27:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RDR5VF011911 for ipng-dist; Wed, 27 Jun 2001 06:27:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RDR0dP011904 for ; Wed, 27 Jun 2001 06:27:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00750; Wed, 27 Jun 2001 06:27:10 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19434; Wed, 27 Jun 2001 06:27:07 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA06468; Wed, 27 Jun 2001 22:28:13 +0900 (JST) Date: Wed, 27 Jun 2001 22:27:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Wed_Jun_27_22:27:07_2001-1" X-Dispatcher: imput version 980905(IM100) Lines: 677 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Wed_Jun_27_22:27:07_2001-1 Content-Type: text/plain; charset=US-ASCII >>>>> On Tue, 26 Jun 2001 14:20:48 +0200 (CEST), >>>>> Erik Nordmark said: >> If possible, I'd like to see the next revision of the draft before the >> next IETF meeting in London. So my question is: >> >> does anyone (especially in the authors) try to revise the draft now? > I'd like to see the document finished. But I don't have any cycles > to actually drive the open issues to conclusion. > If folks can agree on text to add/change I can do the editing of the document. > Or I can take on a co-author that will help drive this to conclusion > and also do the edits. Okay, then I'll try to drive the discussion, and, if necessary, will contribute the result as text. >> - Add credits for UDP MTU stuff >> - Move information about mapping from inet6_opt to setsockopt and >> cmsg. >> >> What exactly do these two items mean? > The issue about UDP MTU for DNS servers was brought up > by somebody on this list and there was a separate I-D (expired long time ago) > which had one proposal for this. The document should give due credit to > that individual. I searched for the materials in the web, and got the following items: Subject: (IPng 1494) BSD API spec/Path MTU From: "Thomas Narten" Date: Wed, 28 Feb 1996 09:22:43 -0400 http://www.wcug.wwu.edu/lists/ipng/199602/msg00158.html "Forcing Fragmentation to Network MTU" by Mark Andrews which can be found at http://www.join.uni-muenster.de/JOIN/ipv6/drafts/draft-ietf-ipngwg-bsd-frag-01.txt Are these the ones we are looking for? > The second one is about the structure of the document. > The inet6_opt routines are described as having to do with ancillary data > and in a separate place it is pointed out that the routines > also apply to the same information in setsockopt. This organization could > be better. I'm still not sure about it, but (for example) are you talking about the following paragraph, When using ancillary data a Hop-by-hop options is passed between the application and the kernel as follows: The cmsg_level member will be IPPROTO_IPV6 and the cmsg_type member will be IPV6_HOPOPTS. These options are then processed by calling the inet6_opt_next(), inet6_opt_find(), and inet6_opt_get_val() functions, described in Section 10.6. (in Section 8.1) intending that we should mention socket option cases as well? By the way, I found some typo in the 02 version: 8.2. Sending Hop-by-Hop Options All the Hop-by-Hop options must specified by a single ancillary data object. The cmsg_level member is set to IPPROTO_IPV6 and the cmsg_type member is set to IPV6_HOPOPTS. The option is normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_set_val() functions, described in inet6_set_val() should be inet6_opt_set_val(). 9.2. Sending Destination Options The Destination options are normally constructed using the inet6_opt_init(), inet6_opt_append(), inet6_opt_finish(), and inet6_set_val() functions, described in Section 10. Same here. >> - Fix Authors address wrt Rich. >> >> It's an editorial issue. (But what is the best "address" for him?) > I don't know what is traditionally done in cases like this > thus any guidance would be quite helpful. If he is listed > as an author we need to say something in the address section. > Alternatively we can list him at the top of the acknowldgement section > e.g. with something like > Previous versions of this document [RFC 2292] was co-authored by > the late Rich Stevens. I don't know a common sense in such a case, either. rfc2553bis has the same issue, and the latest draft simply removed his address. >> - Specify "change" for TCP especially when there are multiple HBH >> option headers etc. >> >> ??? what does "multiple HBH option headers" mean? The IPv6 spec >> requirs a HBH option header appear only once in a single packet. Is >> this a typo, and should this be "multiple DST option headers"? > I guess the comment is generic - applies indepedently of the type of > repeated extension headers. > Is there really something in RFC 2460 which says that packets with multiple > HBH headers should be dropped? I believe the last sentence of the following paragraph in RFC2460 specifies the behavior: If, as a result of processing a header, a node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. So, we should be able to assume we'll never see multiple hop-by-hop options headers in the API layer. BTW, I mentioned a same kind of issue for the sending size far back in the past, and your answer was "implentation defined", with which I'm okay (see a comment about Section 8.2 in the attached message below.) >> - If the home address option passed out in If so >> what address value does it contain? >> >> As I said above, I'd prefer a separate option if we really need to >> pass the home address to applications. > I'd be fine with that approach. This means adding some text to say that > the home address option should not be passed to the application when > the application has specified IPV6_RECVDSTOPTS?, right? > Or do you envision two different mechanisms by which the application can > receive this information? Oops, sorry, I was a bit confused. I meant how to pass the care-of address to the application. As for the home address, it should be passed to the application as if it was really in the source address field of the IPv6 header (e.g. in the "from" address returned by recvmsg, or through the getpeername function), if I remember correclty a succeeding discussion. Anyway, the home address option (if any) should be passed 'as is' to the application that specifies IPV6_RECVDSTOPTS, IMO. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Wed_Jun_27_22:27:07_2001-1 Content-Type: message/rfc822 Return-Path: owner-ipng@sunroof.eng.sun.com Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA28313 for ; Sat, 8 Jan 2000 18:16:53 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id SAA14191 for ; Sat, 8 Jan 2000 18:28:19 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id SAA04689 for ; Sat, 8 Jan 2000 18:28:19 +0900 (JST) Received: from maltese.wide.toshiba.co.jp ([202.249.10.99]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.4) with ESMTP id SAA21984 for ; Sat, 8 Jan 2000 18:28:19 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id SAA04685 for ; Sat, 8 Jan 2000 18:28:18 +0900 (JST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by tsbgw.wide.toshiba.co.jp (8.9.3/8.9.1) with ESMTP id SAA14183 for ; Sat, 8 Jan 2000 18:27:53 +0900 (JST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25407; Sat, 8 Jan 2000 01:27:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id BAA28725; Sat, 8 Jan 2000 01:27:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e088Dfv19004 for ipng-dist; Sat, 8 Jan 2000 00:13:44 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e0889IY18781 for ; Sat, 8 Jan 2000 00:09:35 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA01171 for ; Sat, 8 Jan 2000 00:09:14 -0800 (PST) Received: from internexus.net (internexus.net [206.152.14.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA18655 for ; Sat, 8 Jan 2000 00:09:11 -0800 (PST) Received: (qmail 27010 invoked by uid 8079); 8 Jan 2000 08:08:02 -0000 MBOX-Line: From owner-ipng@sunroof.eng.sun.com Thu Jan 06 00:33:17 2000 Delivered-To: ry@internexus.net Received: (qmail 12332 invoked from network); 6 Jan 2000 00:33:16 -0000 Received: from lukla.sun.com (192.18.98.31) by internexus.net with SMTP; 6 Jan 2000 00:33:16 -0000 Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA24144; Wed, 5 Jan 2000 17:33:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id QAA11663; Wed, 5 Jan 2000 16:33:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) id e060SXV09536 for ipng-dist; Wed, 5 Jan 2000 16:28:33 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.0.Beta10+Sun/8.10.0.Beta10) with ESMTP id e060SMY09529 for ; Wed, 5 Jan 2000 16:28:22 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA22775; Wed, 5 Jan 2000 16:28:05 -0800 (PST) Date: Wed, 5 Jan 2000 16:27:42 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: comments on ipngwg-rfc2292bis-01 Cc: erik.nordmark@eng.sun.com, matt@3am-software.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-UIDL: d59f09da321cd82db426b0e2757ffee2 Status: O X-Keywords: X-UID: 4638 To: ry@tmgi.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks for all the careful comments. I'll fix the ones I'm not explicitly including in the reply (and most of the ones below as well - I just thought I should respond to your comments explicitly on these ones). > 2.1.2. IPv6 Extension Headers > > I think it would be useful to define a generic structure to specify > IPv6 extension headers, since we sometimes encounter a situation where > we can't detect the type of an extension header but should deal with > the header. As an example, here is the KAME's structure for this > purpose: > > struct ip6_ext { > u_char ip6e_nxt; > u_char ip6e_len; > }; I will add that unless somebody disagrees. > 2.1.3. IPv6 Options > (snip) > /* IPv6 options */ > structip6_opt { > uint8_tip6o_type; > uint8_tip6o_len; > }; > > There seems to be lack of white spaces in the above code. Yes, lots of whitespace is missing in the structures. I sent an email about this to ipng back in November when I realized the bug. > 2.2.1. ICMPv6 Type and Code Values > ... > #define ICMP6_MEMBERSHIP_QUERY 130 > #define ICMP6_MEMBERSHIP_REPORT 131 > #define ICMP6_MEMBERSHIP_REDUCTION 132 > > These macro names are based on terms of IGMPv2, not MLD. So I prefer > the names like the followings: > > #define MLD_LISTENER_QUERY 130 > #define MLD_LISTENER_REPORT 131 > #define MLD_LISTENER_DONE 132 > > I don't necessarily argue that the old names should be removed. I'm > glad if the latter names are *added* in the specification. I'll switch to the new ones. If implementations want to provide the old as well as new they can do that. But we don't want to clutter up the specification. > 2.2.2. ICMPv6 Neighbor Discovery Type and Code Values > > #define ND_OPT_PI_FLAG_ONLINK 0x80 > #define ND_OPT_PI_FLAG_AUTO 0x40 > > We may have to define macro names for the "Router Address bit" used in > mobile-ipv6 and the "Site Prefix flag" used in the > ipngwg-site-prefixes draft. > (I'm not sure this is good since they are not officially > standardized. This is just a comment.) My take is that if we are pretty sure that things will become a standard we can add it to the API. Thus I added router renumbering stuff and I should add the mobile IPv6 pieces. But I might hold off for a while on icmp name lookups and site prefixes so we can see what will happen with those. If somebody wants to convince me that the WG will approve of that work I'm game to add it to the API spec. So I'll add ND_OPT_PI_FLAG_ROUTER. Is there something else missing from the mobile IPv6 specification? > 2.2.3. Multicast Listener Discovery Type and Code Values > > Although the section title contains "Type and Code Values", there are > no such definitions in this section. Only a struture for MLD headers > and short cut macros are defined. Is this your intention? > (it may be good to define MLD_LISTENER_QUERY, etc in this section.) OK. I'll move the type definition down to be consistent across the section. > 2.2.4. ICMPv6 Router Renumbering Type and Code Values > > Again, there are no "Type and Code Values" definitions in this > section. > > FYI, we use the following definition to specify the type of router > renumbering in the KAME implementation: > > #define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */ I'll add that one. > /* PCI code values */ > #define RPM_PCO_ADD 1 > #define RPM_PCO_CHANGE 2 > #define RPM_PCO_SETGLOBAL 3 > > I think that "PCI" in the comment line is misspelled and should be > "PCO" (Prefix Control Operations). Ack. > 4. Access to IPv6 and Extension Headers > > Two different mechanisms exist for sending this optional information: > > 1. Using setsockopt to specify the option content for a socket. > These are known an "sticky" options since they affect all > transmitted packets on the socket until either the a new > setsockopt is done or the options are overridden using ancillary > data. > > When an error occurs during a process of setting a sticky option > (e.g. length mismatch), should a previously specified value of the > option (if any) be kept or be cleared anyway? I guess it should be > kept, but I'm not sure about this point from the draft. (Note that > IPv4 implementation in 4.4 BSD always clears existing IPv4 options > regardless of the result of overriding procedure.) What do others think? Should we specify this amount of detail? > 6. Packet Information > > An > application can clear any sticky IPV6_PKTINFO option by either doing > a setsockopt for option with optlen being zero, or by doing a > "regular" setsockopt with ipi6_addr being in6addr_any and > ipi6_ifindex being zero. > > Is the latter way necessary? This prohibits implementation from > specifing the unspecified address as source address. (I'm not sure if > it should be allowed, but it might be useful for some purposes.) Since PKTINFO contains two pieces of information (ifindex and source address) and applications might only want to set one of the two the semantics of ipi6_ifindex = X (X != 0) and ipi6_addr is all zero (unpspecified) must mean "the application does not want to control the source address". Thus you can't really use this to set the source address to the unspecified address. > 6.1. Specifying/Receiving the Interface > > When the IPV6_PKTINFO socket option is enabled, the received > interface index is always returned as the ipi6_ifindex member of the > in6_pktinfo structure. > > Is the option name (IPV6_PKTINFO) correct? Shouldn't it be > IPV6_RECVPKTINFO? Yes. Good catch. I'll fix. > 6.3. Specifying/Receiving the Hop Limit > > In this section, there is no (explicit) description of how to clear an > existing IPV6_HOPLIMIT sticky option. If specifying -1 is the only > way, it would be better to clearly state the fact in the draft. I'll add that. Using a zero length option should also work. > 6.4. Specifying the Next Hop Address > > There is no description of how to remove an existing IPV6_NEXTHOP > sticky option in this section. I guess that it can be removed by > specifying the option with optlen being zero. I'll add that. > Three functions build a Routing header: > > inet6_rth_space() - return #bytes required for Routing header > inet6_rth_init() - initialize buffer data for Routing header > inet6_rth_add() - add one IPv6 address to the Routing header > > It might be better to define an additional function to finalize a > Routing header, since we don't necessary know the number of > intermediate hops when initialization. Actually, I encountered such a > situtaion when implementing source routing in traceroute. Note that we > don't necessarily have to define a new function; we can extend > inet6_rth_add() so that the function updates all fields (at least > including the header length field) of the routing header each time it > is called. If you don't know the number of hops before starting to build the routing header you don't know how much memory to allocate for the option/ancillary data. Thus I think applications like traceroute first need to parse its arguments to get a list of hops (e.g. stored in an array) and then build the routing header. > To receive a Routing header the application must enable the > IPV6_RECVRTHDR socket option: > > int on = 1; > setsockopt(fd, IPPROTO_IPV6, IPV6_RECVRTHDR, &on, sizeof(on)); > > There chould be two or more routing headers in a received packet > (although this wouldn't usually happen). How can we access the second, > third, ... routing headers? Is the each routing header stored in a > separate ancillary data object? Or are all the routing headers stored > in a single object? If the latter is the case, how do we access the > second, third, ... routing headers in the single ancillary data object > (with the defined library functions only)? The API isn't really designed to deal with anything but the recommended way of doing extension headers i.e. at most one hbh header, at most one destination header before a routing header, at most one routing header, and at most one destination header after the routing header. For transmitting it is impossible to construct something different than the above using the API. While the receive side could provide more I don't see any reason to specify that in the API. (But if I ever felt the urge to implement something like that having one ancillary data item per extension header would make the most sense - and keeping the ancillary data items in the order the extension headers were received in the packet.) > Also, the description of the function is a bit unclear to me. It only > mentions how the address fields are changed. Are other fields > (especially the segment-left field) also updated? Or should a caller > adjust the fields by itself in order to reuse (e.g. resend) the > header? In our implementation, I took the former approach; the value > of the segment-left field will be changed to the number of segments in > the function procedure. The intent was the former. I will add: The function reverses the order of the addresses and sets the segleft member in the new Routing header to the number of segments. > 8.2. Sending Hop-by-Hop Options > > All the Hop-by-Hop options must specified by a single ancillary data > object. > > What should the kernel do if an ancillary data contains multiple > IPV6_HOPOPTS objects? Should it take just one of them or should it > discard the entire ancillary data and return an error? If the former > is the case, which one should the kernel take? I don't really care and I don't see a good reason for nailing down this behavior in the specification. "Implementation defined". > 9.1. Receiving Destination Options > > All the Destination options appearing before a Routing header are > returned as one ancillary data object described by a cmsghdr > structure (with cmsg_type set to IPV6_RTHDRDSTOPTS) and all the > Destination options appearing after a Routing header (or in a packet > without a Routing header) are returned as another ancillary data > object described by a cmsghdr structure (with cmsg_type set to > IPV6_DSTOPTS). > > A same kind of question of receiving multiple routing headers can be > applied to the destination options header as well; How can we access > the second, third, ... destination options headers before/after a > routing header? Also, if there is more than one routing header in a > received packet and there is a destination options header between two > routing headers, which part is the destination options header > regarded as, before a routing header or after? And the same type of answer applies. > 9.2. Sending Destination Options > > As described in Section 6 one set of Destination options can appear > before a Routing header, and one set can appear after a Routing > header (or in a packet with no Routing header). Each set can consist > of one or more options but each set is a single extension header. > > What should the kernel do if an ancillary data contains multiple > IPV6_DSTOPTS or IPV6_RTHDRDSTOPTS objects? Should it take just one of > them or should it discard the entire ancillary data and return an > error? If the former is the case, which one should the kernel take? Implementation defined. > 10.1. inet6_opt_init > > int inet6_opt_init(void *extbuf, size_t extlen); > > This function returns the number of bytes needed for the empty > extension header i.e. without any options. If extbuf is not NULL it > also initializes the extension header to have the correct length > field. If the extlen value is not a positive (i.e., non-zero) > multiple of 8 the function fails and returns -1. > > In spite of the last sentence, the sample code in section 24.1 passes > 0 as the second argument of the function: The intent is that is extbuf is not NULL then extlen has to satisfy the above requirement. I'll clarify. > The align parameter must have a value of 1, 2, 4, or 8. The align > value can not exceed the value of len. > > Is this enough to implement all "Xn + Y" alignment requirements? For > example, can we specify "4n + 3" as alignment requirement using a > single alignment parameter? It is sufficient to specify all alignments according to the rules of appendix B in the IPv6 specification. In addition on Xn+Y that spec says "order the fields from smallest to largest". If you have an option with alignment 4n+3 it's size must be 4m+1 to follow the rules in appendix B. In that case you set len to 4m+1 and align to 4. (The rules in appendix B requires an option with alignment Xn+Y to end at a multiple of X bytes, which is why Y doesn't have to be specified.) > 10.4. inet6_opt_set_val > > Databuf should be a pointer returned by inet6_opt_append(). This > function inserts data items of various sizes (1, 2, 4, or 8 bytes) in > the data portion of the option. > > "(1, 2, 4, or 8 bytes)" seems confusing; it can be interpreted that > only the 4 sizes can be specified. I think it would be better to > simply remove the parenthesis. While I see the point this statement in RFC 2460 o One desirable feature is that any multi-octet fields within the Option Data area of an option be aligned on their natural boundaries, i.e., fields of width n octets should be placed at an integer multiple of n octets from the start of the Hop-by- Hop or Destination Options header, for n = 1, 2, 4, or 8. seems to imply that those are the only supported sizes of the option data. If we don't have that constraint you could interpret the above to mean that a 5 octet value should be aligned on its natural boundary i.e. a 5 octet alignment. While I think you could align it on a multiple of 5 from the beginning of the option that carries that value, you can't both do this and have it be aligned on a multiple of 5 bytes from the beginning of the option header or from the beginning of the packet. So if somebody is designing options with data items that are not a power of two in size they need to decide which power of two they need for alignment. But I guess your point is that they should be able to use inet6_opt_set_val to set e.g. a 5 byte value. Point taken. I just have to think about how to describe this in a concise way. > 10.5. inet6_opt_next > > This function parses received extension headers returning the next > option. > > Since the function is used only for HbH/Destination options headers, > it would be better to replace "received extension headers" with "(a) > received options header(s)". > > When there are no more options the return value is -1. > > What if an error occurs? Also -1. I'll add that. > 10.7. inet6_opt_get_val > > This function extracts data items of various sizes > (1, 2, 4, or 8 bytes) in the data portion of the option. > > Again, I think it would be better to remove the parenthesis (see the > first comment on section 10.4.) I'll try to come up with concise text. > XXX Perhaps we should add a note to point out that > robust receivers should verify alignment before calling > inet6_opt_get_val(). XXX Or check alignment and fail by returning > -1? > > I think the former is better, since we can't assume that the function > knows the alignment requirements for all options (including ones > defined in the future and unstandardized options.) While the function doesn't know the alignment of future option content it could verify that they have natural alignment i.e. that an N octet field (for N = 1,2,4,8) is aligned on an N octet boundary. > In our implementation the function always uses memcpy to copy the data > (i.e. not using cast to a specific type) for safety. My draft implementation also uses bcopy. > 15. Summary of New Definitions > > int inet6_opt_append(void *, size_t, int, > uint8_t, size_t, uint_8, void > **); > > I think the type of the sixth argument should be "uint8_t", not > "uint_8". Actually, uint_t is the correct type. > 23.1. Sending a Routing Header > > The six values in the column beneath node S are the values in the > Routing header specified by the sending application using sendmsg() > of setsockopt(). The function calls by the sender would look like: > > void *extptr; > int extlen; > struct msghdr msg; > ... > > The variable "extptr" is declared but unused in the example. This > should be "optptr", or all the occurrences of "optptr" should be > replaced with "extptr". Ack. optlen/extlen has the same issue. I'll use "ext*" since it is the length and pointer to the extension header. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --Multipart_Wed_Jun_27_22:27:07_2001-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 07:23:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RENMdP012073 for ; Wed, 27 Jun 2001 07:23:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RENL4s012072 for ipng-dist; Wed, 27 Jun 2001 07:23:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RENIdP012065 for ; Wed, 27 Jun 2001 07:23:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01710 for ; Wed, 27 Jun 2001 07:23:26 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12790 for ; Wed, 27 Jun 2001 08:23:24 -0600 (MDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 57E415690; Wed, 27 Jun 2001 10:23:25 -0400 (EDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5398557B4 for ; Wed, 27 Jun 2001 10:23:25 -0400 (EDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 256875AD; Wed, 27 Jun 2001 10:23:25 -0400 (EDT) Received: from oflume.zk3.dec.com (oflume.zk3.dec.com [16.140.112.3]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 1979963E for ; Wed, 27 Jun 2001 10:23:25 -0400 (EDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id KAA0000011808; Wed, 27 Jun 2001 10:23:24 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id KAA0000079952; Wed, 27 Jun 2001 10:23:23 -0400 (EDT) Message-ID: <3B39EC5B.3E2D88DB@zk3.dec.com> Date: Wed, 27 Jun 2001 10:23:23 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: ru, en MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I tried to resist jumping in here, but I guess it's time... 1. Protocol independance is an extremely rare ideal (I would not call it a myth precisely). Having ported a bunch of simple and complex application, I can say now that only about 5% of them were really protocol independent. Most apps do all sorts of loging, setting socket options, etc... that is really difficult to not have even one if (af == AF_INET) ... else if (af == AF_INET6) .... If you have even one of these, you loose protocol independence, so the ideal goes out the window. 2. All the talk about specifying bind() constraints should not be specified in RFC. It may be considered as an Appendix, but it is very difficult to get all of the behavior from all different systems. Jinmey's collection of results from the bind test program Kame guys have created shows a lot of different way of doing this. Documenting this would be nightmare. 3. As Tim already pointed out, changing polarity of V6ONLY would break some things. A quick glance through my code shows at lest 10 apps that would have to be ported again (for the 5th time). As an implementor, NO THANKS. I am in the camp of people who think the currenlty specified behavior should be kept. It works and allows flexibility to try for protocol independence (which will be hard to achieve in complex applications even if polarity of V6ONLY changes). I personally prefere a single socket approach to writing apps. -vlad P.S. I have actually once implemented once the 0.0.0.0 and :: on the same port without any socket options. This worked for a while untill we put a load on the system though port-trollers. This cause all sort of havok as these port-torllers started stealing traffic from applications that did not have 2 sockets and expected V4 traffic on V6 wildcard. I don't know if anyone else has seen this. ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 07:50:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5REowdP012136 for ; Wed, 27 Jun 2001 07:50:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5REovhN012135 for ipng-dist; Wed, 27 Jun 2001 07:50:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5REordP012128 for ; Wed, 27 Jun 2001 07:50:53 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5REoxU216572; Wed, 27 Jun 2001 07:50:59 -0700 (PDT) Date: Wed, 27 Jun 2001 16:50:58 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: RFC 2553 bind semantics harms the way to AF independence To: Dave Thaler Cc: Jim Bound , horape@tinuviel.compendium.net.ar, Jun-ichiro itojun Hagino , Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC101671E21@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jim Bound: > > we did suggest that there be no default for v6only (in fact I > suggested > > it) and no one on either side wanted that. thinking was even if one > did > > not get their choice then its better to have default for the users. > > Actually I suggested it as well, so I wouldn't have a problem with no > default. Anyone who wants portable apps would just always set the > option, no problem. The benefit of changing the default would be that applications using getaddrinfo could be more address independent. With either the current default or an unspecified default those applications need code to say if AF_INET6 turn on IPv6_V6ONLY Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 08:00:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RF0rdP012153 for ; Wed, 27 Jun 2001 08:00:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RF0rs5012152 for ipng-dist; Wed, 27 Jun 2001 08:00:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RF0ndP012145 for ; Wed, 27 Jun 2001 08:00:49 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5RF0uU218915; Wed, 27 Jun 2001 08:00:56 -0700 (PDT) Date: Wed, 27 Jun 2001 17:00:42 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2553 bind semantics harms the way to AF independence To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200106261912.MAA01191@feller.mentat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > With regard to the IPV6_V6ONLY option, it made and makes little difference to > me what value the option defaults to. No matter which we choose code will > break. We have also had this discussion before. I see that Erik and Brian > are for changing the default value to true. I didn't say that. I said if I had a time machine and could be back N years I would change the default. What to do at this point in time is far from clear. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 08:03:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RF3VdP012175 for ; Wed, 27 Jun 2001 08:03:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RF3VtM012174 for ipng-dist; Wed, 27 Jun 2001 08:03:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RF3RdP012167 for ; Wed, 27 Jun 2001 08:03:27 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5RF3YU219322; Wed, 27 Jun 2001 08:03:35 -0700 (PDT) Date: Wed, 27 Jun 2001 17:03:33 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: summary of discussions about the semantics of sin6_scope_id To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We have seen 3 definitions of semantics. I call them > (A) the flat 32 > (B) the strict 4+28 split > (C) the flexible 4+28 split > respectively. (A) makes the most sense to me since it seems simpler. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 08:17:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RFHKdP012207 for ; Wed, 27 Jun 2001 08:17:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RFHKIN012206 for ipng-dist; Wed, 27 Jun 2001 08:17:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RFHGdP012199 for ; Wed, 27 Jun 2001 08:17:16 -0700 (PDT) Received: from buse (buse.France.Sun.COM [129.157.212.11]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with SMTP id f5RFHNU226002; Wed, 27 Jun 2001 08:17:23 -0700 (PDT) Date: Wed, 27 Jun 2001 17:17:19 +0200 (MEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RFC 2553 bind semantics harms the way to AF independence To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Umm, then I may have misunderstood a former discussion about itojun's > very 1st bindtest questionnaire (around August 2000). Perhaps I > misunderstood the fact that Solaris supported separate port space for > IPv4 and IPv6. Sorry, I should've been more careful when talking > about others' implementation. Solaris does effectively have a separate port space for IPv4 and IPv6 as well as supporting IPv4-mapped addresses on AF_INET6 sockets. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 08:37:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RFbrdP012237 for ; Wed, 27 Jun 2001 08:37:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RFbrRG012236 for ipng-dist; Wed, 27 Jun 2001 08:37:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RFbndP012229 for ; Wed, 27 Jun 2001 08:37:49 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15625 for ; Wed, 27 Jun 2001 08:37:58 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07737 for ; Wed, 27 Jun 2001 08:37:54 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5RFb5h03283; Wed, 27 Jun 2001 22:37:05 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jun 2001 22:37:05 +0700 Message-ID: <3281.993656225@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 27 Jun 2001 22:27:07 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | >> - Fix Authors address wrt Rich. | I don't know a common sense in such a case, either. rfc2553bis has | the same issue, and the latest draft simply removed his address. I'd wait and see how much of the doc ends up changing. If it is comparatively little, leave him as an author for the next rfc version then move him to acks for the one after that (if there ever is another). If there are lots of changes, do it now. If he stays as an author, in the authors' address section, just list him as "W.Richard Stevens (deceased)" | > Is there really something in RFC 2460 which says that packets with | > multiple HBH headers should be dropped? | | I believe the last sentence of the following paragraph in RFC2460 | specifies the behavior: Yes, looks right - certainly it is the sane way to define things. | > 2.1.2. IPv6 Extension Headers | > | > I think it would be useful to define a generic structure to specify | > IPv6 extension headers, since we sometimes encounter a situation where | > we can't detect the type of an extension header but should deal with | > the header. Huh? If you can't detect the type of the header, you can't do anything with it at all, you certainly can't find its length, or what the next header type will be (there's certainly no expectation that all future headers will necessarily follow the most common layout of those fields, and without that you're sunk). Unknown headers are "drop the packet" and always have been (as in the paragraph you quoted). | I will add that unless somebody disagrees. So, count one disagreement. In any case a u_char for the length is not necessarily going to be enough. | But I might hold off for a while on icmp name lookups and site prefixes | so we can see what will happen with those. | If somebody wants to convince me that the WG will approve of that work | I'm game to add it to the API spec. Add it to the drafts now, so the API can be considered, on the assumption that the specs will be accepted. It takes no time at all to yank that part if that turns out to be an unwarranted assumption, but quite a long time of review and updates to add it later if it turns out to be needed. The name lookups spec in particular needs attention, as it needs to be determined just how the name that is returned is obtained. Is it always to be the same value as hostname(2) or can a node set one name to be used as the result of hostname() (to be used in local log reports, prompts, ...) and another to be returned to other nodes? No opinion at the minute, just a question that needs an answer. | > 4. Access to IPv6 and Extension Headers | What do others think? | Should we specify this amount of detail? Yes. That's one of the most important factors in an API spec - what state the world will be left in when things go wrong. Otherwise, on any error, the only option is to close everything down and start again. Often that's not practical. | > 6.3. Specifying/Receiving the Hop Limit | I'll add that. | Using a zero length option should also work. Pick one preferred way, and doc that one, not several variations that all should work. | If you don't know the number of hops before starting to build the routing | header you don't know how much memory to allocate for the option/ancillary | data. What this leads to is the question of who is responsible for the accounting. That can be either way - it can be done inside the API, or by the application. A decision just needs to be made (doing it inside the API functions makes for a simpler interface, but generally one with greater overheads). | The API isn't really designed to deal with anything but the recommended | way of doing extension headers i.e. at most one hbh header, | at most one destination header before a routing header, Yes - the "get the header by name" type interface is fine for some applications, but not nearly powerful enough in general, what is most likely needed is a "get the next header" interface, which returns the header type, its length, and its data, as well as a cookie to hand to the API the next time it is called (0 for the first call) so the API knows where it was up to in the list. The caller should provide space for the data - with as much as fits being returned (the returned length will indicate whether all of the data was included or not - by passing a data buffer length of 0 the application just gets the header type/length info back, so it can see what headers exist, and how big they are). With that, the "get the routing header" can be implemented as library routines rather than via the interface to the stack if desired. | While the receive side could provide more I don't see any reason to specify | that in the API. if anything, this is what the API ought be specifying, that's more general and more useful than the "get the routing header" types functions. Knowing what is in a header is typically only going to provide precise info as to what it all means when the position in the sequence of headers, and often, the actual data in the other headers, is examined. | (But if I ever felt the urge to implement something like that | having one ancillary data item per extension header would make the most | sense - and keeping the ancillary data items in the order the extension | headers were received in the packet.) Perhaps - that's going to return the whole thing to the app in one hit, right? That would be appropriate for some apps, but it makes it hard to work out how to provide adequate buffers. | > 8.2. Sending Hop-by-Hop Options | > What should the kernel do if an ancillary data contains multiple | > IPV6_HOPOPTS objects? | | I don't really care and I don't see a good reason for nailing down | this behavior in the specification. "Implementation defined". That seems reasonable - it is an "only buggy apps do that" type thing. But the doc needs to actually say that, not just ignore it. | > 9.1. Receiving Destination Options | > A same kind of question of receiving multiple routing headers can be | > applied to the destination options header as well; | And the same type of answer applies. Yes, the API needs to be able to deal with any sequence of known header types (other than HBH, which is very precisely defined to make it easier for the routers). | > 9.2. Sending Destination Options | > What should the kernel do if an ancillary data contains multiple | > IPV6_DSTOPTS or IPV6_RTHDRDSTOPTS objects? | Implementation defined. This one is probably going to depend on what the API for sending an arbitrary header sequence looks like. | > 10.4. inet6_opt_set_val | While I see the point this statement in RFC 2460 | o One desirable feature is that any multi-octet fields within the | Option Data area of an option be aligned on their natural | boundaries, i.e., fields of width n octets should be placed at | an integer multiple of n octets from the start of the Hop-by- | Hop or Destination Options header, for n = 1, 2, 4, or 8. | seems to imply that those are the only supported sizes of the | option data. That's not how I read it. I read it as requiring that an option that happens to be 1 2 4 or 8 bytes should be naturally aligned, whereas options of other lengths go wherever they best fit. In practice, whenever a new option is defined, its layout will be specified by those who define it - the 2460 comment is just trying to guide those designers to "do the right thing". But they will end up doing whatever best suits the demands of the option they're creating, and if that means defining a 7 byte option, that's what will happen - or an option containing a 2 byte field followed by a 4 byte field, with 2 bytes of trailing padding (so the 4 byte field is not aligned). Nothing we do now can prevent that from happening. | If we don't have that constraint you could interpret the above to mean that | a 5 octet value should be aligned on its natural boundary i.e. a 5 octet | alignment. The "for n = ..." constraint avoids that conclusion. It makes it clear that the alignment only applies to data items of those lengths. | So if somebody is designing options with data items that are not a power | of two in size they need to decide which power of two they need for | alignment. Yes, exactly - or more correctly, they need to define the layout of the option data. As does anyone designing an option. | While the function doesn't know the alignment of future option content | it could verify that they have natural alignment i.e. that an N octet | field (for N = 1,2,4,8) is aligned on an N octet boundary. That's probably not a good idea - just in case some future spec, for what are good reasons at the time, decides to do away with that suggestion from 2460. It is only a suggestion after all (and cannot possibly be more). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 08:42:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RFg5dP012257 for ; Wed, 27 Jun 2001 08:42:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RFg5Ii012256 for ipng-dist; Wed, 27 Jun 2001 08:42:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RFg1dP012249 for ; Wed, 27 Jun 2001 08:42:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16585 for ; Wed, 27 Jun 2001 08:42:10 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA03629 for ; Wed, 27 Jun 2001 09:43:01 -0600 (MDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5RFfth03299 for ; Wed, 27 Jun 2001 22:41:55 +0700 (ICT) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: again: draft-blanchet-ipngwg-testadd-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Jun 2001 22:41:55 +0700 Message-ID: <3297.993656515@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It has been almost 2 weeks now since I suggested fe00::/9 as the prefix to use in Marc's draft to use for examples in doc and such. Aside from having my notational stupidity pointed out, there's been no comment at all on that suggestion. So, can we take it as accepted that that address block is now reserved for this purpose, and Marc can go ahead and send in an updated version of his draft using that as the prefix? The draft would contain an IANA considerations section that requests IANA to list that address block as "reserved for use in documentation" or similar. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 09:50:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGoLdP012441 for ; Wed, 27 Jun 2001 09:50:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RGoK3Z012440 for ipng-dist; Wed, 27 Jun 2001 09:50:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGoEdP012425; Wed, 27 Jun 2001 09:50:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04897; Wed, 27 Jun 2001 09:50:24 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA12322; Wed, 27 Jun 2001 10:50:37 -0600 (MDT) Received: from CLASSIC.viagenie.qc.ca (modemcable245.48-201-24.que.mc.videotron.ca [24.201.48.245]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f5RH71149927; Wed, 27 Jun 2001 13:07:01 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010627122759.020b2d20@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 12:33:00 -0400 To: Robert Elz , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com From: Marc Blanchet Subject: Re: again: draft-blanchet-ipngwg-testadd-00.txt In-Reply-To: <3297.993656515@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At/À 22:41 2001-06-27 +0700, Robert Elz you wrote/vous écriviez: >It has been almost 2 weeks now since I suggested fe00::/9 as the >prefix to use in Marc's draft to use for examples in doc and such. > >Aside from having my notational stupidity pointed out, there's been >no comment at all on that suggestion. > >So, can we take it as accepted that that address block is now reserved >for this purpose, and Marc can go ahead and send in an updated version >of his draft using that as the prefix? - a new draft was issued but the filename was changed with the advice of the ngtrans chairs. (draft-blanchet-ngtrans-exampleaddr-00.txt) - I announced it in ngtrans list two days ago. - the discussion of this draft is moved to ngtrans. Could anybody please _not_ reply to ipng so we will avoid multiple cross-postings. (I kept ipng so ipng people can see the answer). - the suggestion of the ngtrans chairs was to use 3ffe:ffff::/32. I was for something else (i.e. 3ffe:ff00::/24), but I loose... ;-)) >The draft would contain an IANA considerations section that requests >IANA to list that address block as "reserved for use in documentation" >or similar. this was already in the first version of the draft and kept. Alain Durand told me that he is looking at it (don't know what that means, but I'm expecting modifications of the text). Marc. PS. thanks for all comments! >kre > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 09:54:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGs0dP012474 for ; Wed, 27 Jun 2001 09:54:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RGs07I012473 for ipng-dist; Wed, 27 Jun 2001 09:54:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGrtdP012466 for ; Wed, 27 Jun 2001 09:53:56 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09377 for ; Wed, 27 Jun 2001 09:54:06 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06096 for ; Wed, 27 Jun 2001 10:54:04 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 2B1167BB; Thu, 28 Jun 2001 01:49:23 +0900 (JST) To: Vladislav Yasevich Cc: ipng@sunroof.eng.sun.com In-reply-to: vlad's message of Wed, 27 Jun 2001 10:23:23 -0400. <3B39EC5B.3E2D88DB@zk3.dec.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Thu, 28 Jun 2001 01:49:23 +0900 Message-Id: <20010627164923.2B1167BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1. Protocol independance is an extremely rare ideal (I >would not call it a myth precisely). Having ported a bunch >of simple and complex application, I can say now that only >about 5% of them were really protocol independent. Most >apps do all sorts of loging, setting socket options, etc... >that is really difficult to not have even one > if (af == AF_INET) > ... > else if (af == AF_INET6) > .... >If you have even one of these, you loose protocol independence, >so the ideal goes out the window. i'm just curious, but how come did you get so many "if-else" clause? for example, i grepped through the source code like "grep -l AF_INET". in some of NetBSD source code I had on my laptop. - finger, fingerd: totally AF independent - ftp, ftpd: AF dependent (PORT, PASV or EPRT, EPSV) - telnet, telnetd: AF dependent, but not the fundamental part (source routing for client side, IP_TOS setting for daemon side) - tftp, tftpd: tftp is clean. in tftpd there's one switch statement, which can easily be avoided by getaddrinfo/getnameinfo (will do). since it is a bit off-topic, please respond privately if you prefer. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 09:58:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGwAdP012515 for ; Wed, 27 Jun 2001 09:58:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RGwAVb012514 for ipng-dist; Wed, 27 Jun 2001 09:58:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RGw5dP012507 for ; Wed, 27 Jun 2001 09:58:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04150 for ; Wed, 27 Jun 2001 09:58:15 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17114 for ; Wed, 27 Jun 2001 10:58:49 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id BAA08013; Thu, 28 Jun 2001 01:56:22 +0900 (JST) Date: Thu, 28 Jun 2001 01:55:13 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <3281.993656225@brandenburg.cs.mu.OZ.AU> References: <3281.993656225@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 27 Jun 2001 22:37:05 +0700, >>>>> Robert Elz said: > | > 2.1.2. IPv6 Extension Headers > | > > | > I think it would be useful to define a generic structure to specify > | > IPv6 extension headers, since we sometimes encounter a situation where > | > we can't detect the type of an extension header but should deal with > | > the header. > Huh? oops...the attache message was too old, and most of them have already been discussed. I only noted a possibility of "multiple HbH issue" in the sending side by citing the old message. Sorry for taking your time...but thanks for the comments, anyway. I'll read and reply to them later. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 10:17:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RHHFdP012577 for ; Wed, 27 Jun 2001 10:17:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RHHFob012576 for ipng-dist; Wed, 27 Jun 2001 10:17:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RHHBdP012569 for ; Wed, 27 Jun 2001 10:17:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11159 for ; Wed, 27 Jun 2001 10:17:22 -0700 (PDT) Received: from frantic.weston.bsdi.com (frantic-dmz.weston.BSDI.COM [206.196.54.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22825 for ; Wed, 27 Jun 2001 11:17:37 -0600 (MDT) Received: (from dab@localhost) by frantic.weston.bsdi.com (8.10.1/8.10.1) id f5RH8Jv18412 for ipng@sunroof.eng.sun.com; Wed, 27 Jun 2001 12:08:19 -0500 (CDT) Date: Wed, 27 Jun 2001 12:08:19 -0500 (CDT) From: David Borman Message-Id: <200106271708.f5RH8Jv18412@frantic.weston.bsdi.com> To: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In seems to me that all this discussion about what the default behavior should be when binding to a wildcarded AF_INET6 socket doesn't address the issue: deterministic behavior for portable application across multiple operating systems. And just to lay my cards on the table, I support the current default behavior of having AF_INET6 sockets receive both IPv4 and IPv6 packets. Isn't the real problem that we have added an IPV6_V6ONLY option, but not an IPV6_V4ANDV6 option?. If we add that, then portable applications can explictly state what actions they want, and they don't have to worry about OS defaults. The success and failure cases are then obvious and well defined: bind#1 AF_INET6 w/IPV6_ONLY bind#2 AF_INET6 - fail bind#2 AF_INET4 - succeed bind#1 AF_INET6 w/IPV6_V4ANDV6 bind#2 AF_INET6 - fail bind#2 AF_INET4 - fail bind#1 AF_INET4 bind#2 AF_INET6 w/IPV6_ONLY - succeed bind#2 AF_INET6 w/IPV6_V4ANDV6 - fail Thus, you have deterministic behavior. And that's the end goal for portable applications, isn't it? -David Borman, dab@bsdi.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 10:18:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RHIUdP012594 for ; Wed, 27 Jun 2001 10:18:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RHIUY4012593 for ipng-dist; Wed, 27 Jun 2001 10:18:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RHIQdP012586 for ; Wed, 27 Jun 2001 10:18:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09722 for ; Wed, 27 Jun 2001 10:18:36 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01663 for ; Wed, 27 Jun 2001 11:18:34 -0600 (MDT) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f5RHIE019133 for ; Wed, 27 Jun 2001 13:18:14 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 27 Jun 2001 13:18:07 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id N43SNC8T; Wed, 27 Jun 2001 13:18:07 -0400 Received: from nortelnetworks.com (deathvalley.us.nortel.com [47.141.233.58]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JM9FPSPK; Wed, 27 Jun 2001 13:18:08 -0400 Message-ID: <3B3A153A.62382D08@nortelnetworks.com> Date: Wed, 27 Jun 2001 13:17:47 -0400 X-Sybari-Space: 00000000 00000000 00000000 From: "Brian Haberman" Reply-To: "Brian Haberman" X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Re: updated unicast-prefix-based multicast draft References: <3B39D08C.79798429@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, As clarification, the changes made to this doc are: 1. Moved the IANA considerations to the MALLOC WG guidelines doc 2. Added an address lifetime restriction corresponding to the unicast prefix lifetime in the router advertisement 3. Clarified the usage for Source-specific multicast in section 4 4. Clarified the definition of the 'plen' field in section 3 Regards, Brian "Haberman, Brian [NCWIN:6T50:EXCH]" wrote: > > All, > I have updated the above draft based on IESG comments. Due to > the number of changes, the AD's would like to solicit working group > comments on them. One big change is the removal of the IANA section > from this document and putting it in the corresponding MALLOC WG > companion document. > > If you cannot wait for the I-D editor's announcement, the draft > is available at the following URL: > > http://www.innovationslab.net/~haberman/draft-ietf-ipngwg-uni-based-mcast-02.txt > > - Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 11:32:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RIW4dP012760 for ; Wed, 27 Jun 2001 11:32:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RIW4Cr012759 for ipng-dist; Wed, 27 Jun 2001 11:32:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RIW0dP012752 for ; Wed, 27 Jun 2001 11:32:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28221 for ; Wed, 27 Jun 2001 11:32:08 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA29577 for ; Wed, 27 Jun 2001 11:32:07 -0700 (PDT) Received: from 157.54.9.100 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 27 Jun 2001 11:25:07 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 11:24:48 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 11:24:57 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Jun 2001 11:24:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: RFC 2553 bind semantics harms the way to AF independence Date: Wed, 27 Jun 2001 11:24:16 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1B58068@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2553 bind semantics harms the way to AF independence Thread-Index: AcD/GIPHi8AUSQzPTOCmbHjzr5ybtwAHJARQ From: "Dave Thaler" To: "Erik Nordmark" Cc: "Jim Bound" , , "Jun-ichiro itojun Hagino" , "Mauro Tortonesi" , "Francis Dupont" , X-OriginalArrivalTime: 27 Jun 2001 18:24:18.0014 (UTC) FILETIME=[609617E0:01C0FF36] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f5RIW0dP012753 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: > > Actually I suggested it as well, so I wouldn't have a problem with no > > default. Anyone who wants portable apps would just always set the > > option, no problem. > > The benefit of changing the default would be that applications using > getaddrinfo could be more address independent. > With either the current default or an unspecified default those > applications need code to say > if AF_INET6 > turn on IPv6_V6ONLY Someone else suggested that getaddrinfo (with AF_UNSPEC and AI_PASSIVE) should return :: if the OS has IPV6_V6ONLY default to off, and both :: and 0.0.0.0 if the OS has IPV6_V6ONLY default to on, and I agree with this. Another problem I have with the current default is that app writers that want IPv6-only need to know about the IPV6_V6ONLY option, and those that want both IPv4+IPv6 need to know about the AI_V4MAPPED flag. So there's no "simple" api, you have your choice of 2 special cases. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 11:40:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RIeUdP012800 for ; Wed, 27 Jun 2001 11:40:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RIeUAk012799 for ipng-dist; Wed, 27 Jun 2001 11:40:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RIeQdP012792 for ; Wed, 27 Jun 2001 11:40:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03927 for ; Wed, 27 Jun 2001 11:40:35 -0700 (PDT) Received: from starfruit.itojun.org (openbsd-0.lcs.mit.edu [18.26.4.157]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05049 for ; Wed, 27 Jun 2001 11:40:30 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id BA5657C1 for ; Thu, 28 Jun 2001 03:02:14 +0900 (JST) To: ipng X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: ipng webpage troubles From: Jun-ichiro itojun Hagino Date: Thu, 28 Jun 2001 03:02:14 +0900 Message-Id: <20010627180214.BA5657C1@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://playground.sun.com/pub/ipng/html/ipng-main.html now forbids accesses over IPv6. please fix, or if it is not maintained, remove AAAA record (which is pity). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 11:42:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RIgSdP012820 for ; Wed, 27 Jun 2001 11:42:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RIgSl2012819 for ipng-dist; Wed, 27 Jun 2001 11:42:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RIgPdP012812 for ; Wed, 27 Jun 2001 11:42:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09915 for ; Wed, 27 Jun 2001 11:42:34 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA22453 for ; Wed, 27 Jun 2001 12:42:32 -0600 (MDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20243; Wed, 27 Jun 2001 14:42:21 -0400 Date: Wed, 27 Jun 2001 14:42:21 -0400 (EDT) From: Jim Bound To: Pekka Savola Cc: Jun-ichiro itojun Hagino , Mauro Tortonesi , ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think having an appendix with issues and documenting them makes sense too. /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Wed, 27 Jun 2001, Pekka Savola wrote: > On Wed, 27 Jun 2001, Jim Bound wrote: > > and it should not but an implementation that does not permit this is not > > optimal. we cannot force this behavior on implementors either. thats why > > it is not in 2553. > > The API is informational document anyway. It would be nice is this kind > of implementation gotcha's would be noted (no need to force a "proper" > behaviour) so all people would realize a possible problem area. :-) > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 12:01:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RJ1XdP012890 for ; Wed, 27 Jun 2001 12:01:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5RJ1XMI012889 for ipng-dist; Wed, 27 Jun 2001 12:01:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5RJ1TdP012882 for ; Wed, 27 Jun 2001 12:01:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08702 for ; Wed, 27 Jun 2001 12:01:39 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA17619 for ; Wed, 27 Jun 2001 12:01:37 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20782; Wed, 27 Jun 2001 15:01:13 -0400 Date: Wed, 27 Jun 2001 15:01:13 -0400 (EDT) From: Jim Bound To: Erik Nordmark Cc: Dave Thaler , horape@tinuviel.compendium.net.ar, Jun-ichiro itojun Hagino , Mauro Tortonesi , Francis Dupont , ipng@sunroof.eng.sun.com Subject: RE: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is not a problem just a solution ..... /jim "Shout it out G.L.O.R.I.A." (Them [Van Morrison]) On Wed, 27 Jun 2001, Erik Nordmark wrote: > > Jim Bound: > > > we did suggest that there be no default for v6only (in fact I > > suggested > > > it) and no one on either side wanted that. thinking was even if one > > did > > > not get their choice then its better to have default for the users. > > > > Actually I suggested it as well, so I wouldn't have a problem with no > > default. Anyone who wants portable apps would just always set the > > option, no problem. > > The benefit of changing the default would be that applications using > getaddrinfo could be more address independent. > With either the current default or an unspecified default those > applications need code to say > if AF_INET6 > turn on IPv6_V6ONLY > > Erik > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 27 20:06:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S36udP015674 for ; Wed, 27 Jun 2001 20:06:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5S36u0a015673 for ipng-dist; Wed, 27 Jun 2001 20:06:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5S36qdP015666 for ; Wed, 27 Jun 2001 20:06:52 -0700 (PDT) Received: from rouget.sun.com (vpn-129-150-4-32.EBay.Sun.COM [129.150.4.32]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5S371U410694; Wed, 27 Jun 2001 20:07:01 -0700 (PDT) Message-Id: <5.1.0.14.0.20010627200759.02eb1c58@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Jun 2001 20:12:45 -0700 To: Jun-ichiro itojun Hagino , ipng From: Alain Durand Subject: Re: ipng webpage troubles In-Reply-To: <20010627180214.BA5657C1@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:02 AM 6/28/2001 +0900, Jun-ichiro itojun Hagino wrote: > http://playground.sun.com/pub/ipng/html/ipng-main.html > now forbids accesses over IPv6. please fix, or if it is not > maintained, > remove AAAA record (which is pity). I wanted to wait few more days before announcing it, but now, I do not have the choice anymore ;-) We have created an IPv6 replica of http://playground.sun.com that is physically on a different machine that runs an iPlanet IPv6 web server (iWS6.0). This server is still experimental and may change in the future. Thank you to Itojun for reporting a problem on the machine, it is now fixed. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 04:14:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SBEDdP016191 for ; Thu, 28 Jun 2001 04:14:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SBED5K016190 for ipng-dist; Thu, 28 Jun 2001 04:14:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SBE9dP016183 for ; Thu, 28 Jun 2001 04:14:09 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16684 for ; Thu, 28 Jun 2001 04:14:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18264 for ; Thu, 28 Jun 2001 04:14:17 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10676; Thu, 28 Jun 2001 07:13:36 -0400 (EDT) Message-Id: <200106281113.HAA10676@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-02.txt Date: Thu, 28 Jun 2001 07:13:35 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-02.txt Pages : 5 Date : 27-Jun-01 This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-uni-based-mcast-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010627132323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-uni-based-mcast-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010627132323.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 06:18:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SDIWdP016424 for ; Thu, 28 Jun 2001 06:18:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SDIWGK016423 for ipng-dist; Thu, 28 Jun 2001 06:18:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SDIRdP016416 for ; Thu, 28 Jun 2001 06:18:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05069 for ; Thu, 28 Jun 2001 06:18:37 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05385 for ; Thu, 28 Jun 2001 06:18:36 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA15952; Thu, 28 Jun 2001 22:17:10 +0900 (JST) Date: Thu, 28 Jun 2001 22:15:59 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <3281.993656225@brandenburg.cs.mu.OZ.AU> References: <3281.993656225@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 136 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 27 Jun 2001 22:37:05 +0700, >>>>> Robert Elz said: > | >> - Fix Authors address wrt Rich. > | I don't know a common sense in such a case, either. rfc2553bis has > | the same issue, and the latest draft simply removed his address. > I'd wait and see how much of the doc ends up changing. If it is > comparatively little, leave him as an author for the next rfc version > then move him to acks for the one after that (if there ever is another). > If there are lots of changes, do it now. If he stays as an author, in > the authors' address section, just list him as "W.Richard Stevens (deceased)" I think it's a reasonable approach. > | > 2.1.2. IPv6 Extension Headers > | > > | > I think it would be useful to define a generic structure to specify > | > IPv6 extension headers, since we sometimes encounter a situation where > | > we can't detect the type of an extension header but should deal with > | > the header. > Huh? Please forget about this topic. It was once discussed, and the discussion was over with the result that you just want (i.e. we do not include this structure). > | But I might hold off for a while on icmp name lookups and site prefixes > | so we can see what will happen with those. > | If somebody wants to convince me that the WG will approve of that work > | I'm game to add it to the API spec. > Add it to the drafts now, so the API can be considered, on the assumption > that the specs will be accepted. It takes no time at all to yank that > part if that turns out to be an unwarranted assumption, but quite a long > time of review and updates to add it later if it turns out to be needed. > The name lookups spec in particular needs attention, as it needs to be > determined just how the name that is returned is obtained. Is it always > to be the same value as hostname(2) or can a node set one name to be used > as the result of hostname() (to be used in local log reports, prompts, ...) > and another to be returned to other nodes? No opinion at the minute, > just a question that needs an answer. Hmm, as I wrote in a previous message, I myself we should fix the API without these "ongoing" stuff. If we're taking this approach, we'd have to include structures for draft-ietf-ipngwg-router-selection-00.txt or even draft-vida-mld-v2-00.txt (although the latter one is an individual draft at this moment), and probably more. > | > 4. Access to IPv6 and Extension Headers > | What do others think? > | Should we specify this amount of detail? > Yes. That's one of the most important factors in an API spec - what > state the world will be left in when things go wrong. Otherwise, on > any error, the only option is to close everything down and start again. > Often that's not practical. > | > 6.3. Specifying/Receiving the Hop Limit > | I'll add that. > | Using a zero length option should also work. > Pick one preferred way, and doc that one, not several variations that > all should work. The 02 draft has the following text. In order to clear a sticky IPV6_HOPLIMIT option the application can specify -1 as the value. Alternatively, the application can specify an IPV6_HOPLIMIT socket option with a zero length. I'm okay with this text, although this provides two different ways. > | If you don't know the number of hops before starting to build the routing > | header you don't know how much memory to allocate for the option/ancillary > | data. > What this leads to is the question of who is responsible for the accounting. > That can be either way - it can be done inside the API, or by the application. > A decision just needs to be made (doing it inside the API functions makes for > a simpler interface, but generally one with greater overheads). I agreed with the current spec in the past discussion, so let's keep this point. > | The API isn't really designed to deal with anything but the recommended > | way of doing extension headers i.e. at most one hbh header, > | at most one destination header before a routing header, > Yes - the "get the header by name" type interface is fine for some > applications, but not nearly powerful enough in general, what is most > likely needed is a "get the next header" interface, which returns the > header type, its length, and its data, as well as a cookie to hand to > the API the next time it is called (0 for the first call) so the API > knows where it was up to in the list. The caller should provide space > for the data - with as much as fits being returned (the returned length > will indicate whether all of the data was included or not - by passing > a data buffer length of 0 the application just gets the header type/length > info back, so it can see what headers exist, and how big they are). > With that, the "get the routing header" can be implemented as library > routines rather than via the interface to the stack if desired. We actually have to reconsider the extension header issues, as I said in the first message in this thread. Your idea above seems to be a good candidate. We'll discuss the issue in a separate thread later. (So I'll basically skip the discussions below related to this issue) > | > 8.2. Sending Hop-by-Hop Options > | > What should the kernel do if an ancillary data contains multiple > | > IPV6_HOPOPTS objects? > | > | I don't really care and I don't see a good reason for nailing down > | this behavior in the specification. "Implementation defined". > That seems reasonable - it is an "only buggy apps do that" type thing. > But the doc needs to actually say that, not just ignore it. I don't think so. I believe the protocol stack (normally the kernel) should prevent (at least) non-privileged users from sending invalid packets according to the protocol specification. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 06:49:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SDn7dP016477 for ; Thu, 28 Jun 2001 06:49:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SDn7SI016476 for ipng-dist; Thu, 28 Jun 2001 06:49:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SDn3dP016469 for ; Thu, 28 Jun 2001 06:49:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA01031 for ; Thu, 28 Jun 2001 06:49:13 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00837 for ; Thu, 28 Jun 2001 06:49:11 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id WAA16277 for ; Thu, 28 Jun 2001 22:50:20 +0900 (JST) Date: Thu, 28 Jun 2001 22:49:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: <200106261007.f5QA7XO87396@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 27 Jun 2001 18:03:35 +0900, >>>>> JINMEI Tatuya said: >> The most difficult issue would be the one for extension headers. >> According to a recent discussion about MIP6 issues, the API should be >> flexible enough to send/receive extension headers in any order, whereas >> rfc2292bis basically assumes the recommended order of the headers >> specified in RFC2460. Since it could be a fundamental change of the >> API spec, I'm not sure if we can get a consensus so smoothly. >> Anyways, I'll raise this issue later in a separate thread. >> => this is a deep change but not in a very used part of the spec so >> perhaps we should split the advanced API into two parts in order to >> be able to publish a document soon? > Well, actually, I was thinking about the same idea. If we can split > this part, things will go quite smoothly. How do others think of > this? Does anyone have an objection to this idea? If not, the procedure would be: 1. remove extension header issues from the current draft. 2. solve (a part of) open issues except extension header ones. 3. based on the result of 2, issue a revised version of the rfc2292bis draft. The draft name would be either draft-ietf-ipngwg-rfc2292bis-03.txt or draft-ietf-ipv6-rfc2292bis-00.txt 4. solve extension header issues, and issue a new draft entitled (e.g.) draft-ietf-ipv6-exthdr-api-00.txt JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 09:47:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SGlodP016821 for ; Thu, 28 Jun 2001 09:47:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SGlnCC016820 for ipng-dist; Thu, 28 Jun 2001 09:47:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SGlkdP016813 for ; Thu, 28 Jun 2001 09:47:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08398 for ; Thu, 28 Jun 2001 09:47:56 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15933 for ; Thu, 28 Jun 2001 10:48:50 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.142.141) by smtp2.libero.it (5.5.031) id 3B3A18720003EA29; Thu, 28 Jun 2001 18:47:48 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 66CB628A41; Thu, 28 Jun 2001 11:22:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 5935928A35; Thu, 28 Jun 2001 11:22:40 +0200 (CEST) Date: Thu, 28 Jun 2001 11:22:40 +0200 (CEST) From: Mauro Tortonesi To: Jun-ichiro itojun Hagino Cc: Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: <20010626225734.75EA27BC@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Jun 2001, Jun-ichiro itojun Hagino wrote: > > >> => you can use it with the V6ONLY stuff. > >yes, but on rfc2553-compliant system you cannot have both an AF_INET > >and an AF_INET6 socket listening on the same port. > > (just a picky comment) RFC2553 does not talk about the behavior > when try to bind(2) to both :: and 0.0.0.0 on the same port. some > systems reject bind(2) to 0.0.0.0, some does not. ok. i will try to explain better my thoughts. i don't want to change RFC2553. i think that V6ONLY is a very good feature and may be sufficient to achieve a good af-indipendence. however, this moves the focus on the behaviour of bind and getaddrinfo (which is not described in detail in RFC2553 - i suppose because there is no consensus). some implementations of bind(2) allow binding of 0.0.0.0 and :: address on the same port, and some do not. i think that this may be a problem for the developers which are working in multi-platform environments. i'd really like to minimize the negative effect of this behaviour, but i understand that there is not much that can be done about this. i hope that we will come to a *BSD-like de-facto standard for the behaviour of bind and getaddrinfo, but i wonder if having no standard is even worse than having a bad standard (linux-like). -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 09:48:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SGmMdP016831 for ; Thu, 28 Jun 2001 09:48:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SGmMcq016830 for ipng-dist; Thu, 28 Jun 2001 09:48:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SGmIdP016823 for ; Thu, 28 Jun 2001 09:48:18 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08615 for ; Thu, 28 Jun 2001 09:48:28 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16187 for ; Thu, 28 Jun 2001 10:49:22 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.26.142.141) by smtp3.libero.it (5.5.025) id 3AE9822800E14F34; Thu, 28 Jun 2001 18:47:47 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 8CC2328A43; Thu, 28 Jun 2001 11:38:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 86A9228A35; Thu, 28 Jun 2001 11:38:54 +0200 (CEST) Date: Thu, 28 Jun 2001 11:38:54 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: Jun-ichiro itojun Hagino , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Jun 2001, Jim Bound wrote: > and it should not but an implementation that does not permit this is not > optimal. we cannot force this behavior on implementors either. thats why > it is not in 2553. can't RFC2553 say something like "a good implementation SHOULD allow binding of AF_INET and AF_INET6+V6ONLY on the same port"? such a recommendation would not be a bad thing. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 09:48:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SGmrdP016855 for ; Thu, 28 Jun 2001 09:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SGmrMT016854 for ipng-dist; Thu, 28 Jun 2001 09:48:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SGmmdP016840 for ; Thu, 28 Jun 2001 09:48:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02889 for ; Thu, 28 Jun 2001 09:48:57 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29568 for ; Thu, 28 Jun 2001 09:48:51 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.26.142.141) by smtp3.libero.it (5.5.025) id 3AE9822800E14FC2; Thu, 28 Jun 2001 18:48:11 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 500) id 1124028A42; Thu, 28 Jun 2001 11:35:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 0ABF628A35; Thu, 28 Jun 2001 11:35:53 +0200 (CEST) Date: Thu, 28 Jun 2001 11:35:53 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: Francis Dupont , , , Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 27 Jun 2001, Jim Bound wrote: > > > => you can use it with the V6ONLY stuff. > > > > yes, but on rfc2553-compliant system you cannot have both an AF_INET > > and an AF_INET6 socket listening on the same port. > > Sure you can. By using V6ONLY. Thats the point of the option. It is > just you must set it via setsocopt. > > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one > using AF_INET and the other AF_INET6. RFC2553 does not state this behaviour. in fact many implementations do not allow to do this. can you explain better? let's take two sockets, an AF_INET and an AF_INET6+V6ONLY one. can i bind them on the same port only if i bind first to 0.0.0.0 and then to ::? or is it also correct to bind first to :: and then to 0.0.0.0? RFC2553 is silent about this. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.it -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 11:52:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SIq2dP017051 for ; Thu, 28 Jun 2001 11:52:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SIq1mR017050 for ipng-dist; Thu, 28 Jun 2001 11:52:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SIpvdP017043 for ; Thu, 28 Jun 2001 11:51:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09256 for ; Thu, 28 Jun 2001 11:52:06 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09676 for ; Thu, 28 Jun 2001 11:52:06 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA12736 for ; Thu, 28 Jun 2001 11:52:37 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA10088 for ; Thu, 28 Jun 2001 11:52:35 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA00855 for ipng@sunroof.eng.sun.com; Thu, 28 Jun 2001 11:54:24 -0700 (PDT) Date: Thu, 28 Jun 2001 11:54:24 -0700 (PDT) From: Tim Hartrick Message-Id: <200106281854.LAA00855@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Does anyone have an objection to this idea? If not, the procedure > would be: > > 1. remove extension header issues from the current draft. > 2. solve (a part of) open issues except extension header ones. > 3. based on the result of 2, issue a revised version of the rfc2292bis > draft. The draft name would be either > draft-ietf-ipngwg-rfc2292bis-03.txt > or > draft-ietf-ipv6-rfc2292bis-00.txt > 4. solve extension header issues, and issue a new draft entitled > (e.g.) draft-ietf-ipv6-exthdr-api-00.txt > Hmm.. I would say I do object for this reason. If I remember the issues related to MIPv6 binding updates and the like and I remember the discussions that occurred on this list regarding them I wasn't under the impression that we were substantially far from being able to solve some of the in- flexibility issues. I wouldn't want to see us rip all that content out of the spec unless we are pretty sure that consensus can't be reached. What scares me about splitting this content off is that it opens up an opportunity for complete redesign of the entire mechanism if it is not tightly controlled. We don't have a history of that kind of discipline in these areas and I am concerned that we will get a complete redesign, and pile and piles of obsoleted code, when only tweaks are required. What I would prefer is that we take the discussion to the apifolks mailing list, where we have a good focused group, so that we can actually get the work done. We aren't that far away. It just requires cycles to be applied. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 12:59:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SJxqdP017120 for ; Thu, 28 Jun 2001 12:59:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SJxqFS017119 for ipng-dist; Thu, 28 Jun 2001 12:59:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SJxmdP017112 for ; Thu, 28 Jun 2001 12:59:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23739 for ; Thu, 28 Jun 2001 12:59:57 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [64.81.48.19]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00485 for ; Thu, 28 Jun 2001 12:59:53 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id C1FA21805; Thu, 28 Jun 2001 12:59:50 -0700 (PDT) Date: Thu, 28 Jun 2001 12:59:50 -0700 From: David Terrell To: Jim Bound Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence Message-ID: <20010628125950.A6811@pianosa.catch22.org> Reply-To: David Terrell References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: ; from seamus@bit-net.com on Tue, Jun 26, 2001 at 11:50:33PM -0400 X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 12:57PM up 108 days, 12:02, 45 users, load averages: 0.24, 0.29, 0.28 X-Baby: Theodore Marvin Wolpinsky Terrell born 120 days, 22 hours, 11 minutes, 50 seconds ago Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Jun 26, 2001 at 11:50:33PM -0400, Jim Bound wrote: > I was directly speaking of implementations that make billions of dollars. > That is not Linux or BSD. With all due respect, when you're talking about implementor eyeballs, a huge percentage of unix server implementors learn based on whatever linux supports, because that's what they have to play with when they're learning something new. And BSD is also very significant in this rather powerful niche. Both specifically because of their price and because having the source available is a powerful learning aid. -- David Terrell | "Please note that calling an attacker dbt@meat.net | 'lame' is not an approved security method." http://wwn.nebcorp.com/ | - Benjy Feen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 15:17:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SMHMdP017237 for ; Thu, 28 Jun 2001 15:17:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SMHM6j017236 for ipng-dist; Thu, 28 Jun 2001 15:17:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SMHHdP017229 for ; Thu, 28 Jun 2001 15:17:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21965 for ; Thu, 28 Jun 2001 15:17:26 -0700 (PDT) Received: from starfruit.itojun.org (tserver.conference.usenix.org [199.103.159.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16668 for ; Thu, 28 Jun 2001 16:18:22 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id C559F7BB; Fri, 29 Jun 2001 07:11:33 +0900 (JST) To: Alain Durand Cc: ipng In-reply-to: Alain.Durand's message of Wed, 27 Jun 2001 20:12:45 MST. <5.1.0.14.0.20010627200759.02eb1c58@jurassic> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: ipng webpage troubles From: Jun-ichiro itojun Hagino Date: Fri, 29 Jun 2001 07:11:33 +0900 Message-Id: <20010628221133.C559F7BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>http://playground.sun.com/pub/ipng/html/ipng-main.html >>now forbids accesses over IPv6. please fix, or if it is not maintained, >>remove AAAA record (which is pity). >I wanted to wait few more days before announcing it, but now, I do not have >the choice >anymore ;-) actually this has been widely known quite a while, since the previous trouble (out of sync content). >We have created an IPv6 replica of http://playground.sun.com that is >physically on a different >machine that runs an iPlanet IPv6 web server (iWS6.0). >This server is still experimental and may change in the future. >Thank you to Itojun for reporting a problem on the machine, it is now fixed. I have a very serious request. for those of us who constantly use http over IPv6, it is very very annoying to see non-synchronized content (imagine how you feel when you look for some document, and you don't find it on IPv4 server and but on IPv6 server). could you just mount the partition for web content by NFS and make them 100% synchronized? if it is not possible to synchronize them, I can live without IPv6 server (and I'll use translator to contact IPv4 server). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 16:05:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SN5tdP017307 for ; Thu, 28 Jun 2001 16:05:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SN5t6Z017306 for ipng-dist; Thu, 28 Jun 2001 16:05:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SN5mdP017299 for ; Thu, 28 Jun 2001 16:05:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11915 for ; Thu, 28 Jun 2001 16:05:57 -0700 (PDT) Received: from nebula.sm.sony.co.jp (nebula.sm.sony.co.jp [133.138.10.5]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16971; Thu, 28 Jun 2001 16:05:56 -0700 (PDT) Received: from duplo.sm.sony.co.jp (localhost [[UNIX: localhost]]) by nebula.sm.sony.co.jp (8.11.4/8.11.3) with ESMTP id f5SN5tB28114; Fri, 29 Jun 2001 08:05:55 +0900 (JST) Received: (from onoe@localhost) by duplo.sm.sony.co.jp (8.11.4/8.10.2) id f5SN64M03757; Fri, 29 Jun 2001 08:06:04 +0900 (JST) Date: Fri, 29 Jun 2001 08:06:04 +0900 (JST) From: Atsushi Onoe Message-Id: <200106282306.f5SN64M03757@duplo.sm.sony.co.jp> To: itojun@iijlab.net Cc: Alain.Durand@sun.com, ipng@sunroof.eng.sun.com Subject: Re: ipng webpage troubles In-Reply-To: Your message of "Fri, 29 Jun 2001 07:11:33 +0900" <20010628221133.C559F7BB@starfruit.itojun.org> References: <20010628221133.C559F7BB@starfruit.itojun.org> X-Mailer: Cue version 0.6 (010601-1259/onoe) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This topic should go ngtrans, but ... > I have a very serious request. for those of us who constantly use > http over IPv6, it is very very annoying to see non-synchronized > content And, we have no way to know if the contents is outdated, since we can't guess our proxy connect to the server via IPv4 or via IPv6. Atsushi Onoe -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 16:18:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SNIFdP017339 for ; Thu, 28 Jun 2001 16:18:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5SNIFDW017338 for ipng-dist; Thu, 28 Jun 2001 16:18:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.88.31]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5SNIBdP017331 for ; Thu, 28 Jun 2001 16:18:11 -0700 (PDT) Received: from rouget.sun.com ([129.146.99.78]) by jurassic.eng.sun.com (8.11.4+Sun/8.11.4) with ESMTP id f5SNIJU676143; Thu, 28 Jun 2001 16:18:19 -0700 (PDT) Message-Id: <5.1.0.14.0.20010628161845.030d8000@jurassic> X-Sender: durand@jurassic X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Jun 2001 16:24:10 -0700 To: Atsushi Onoe , itojun@iijlab.net From: Alain Durand Subject: Re: ipng webpage troubles Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200106282306.f5SN64M03757@duplo.sm.sony.co.jp> References: <20010628221133.C559F7BB@starfruit.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:06 AM 6/29/2001 +0900, Atsushi Onoe wrote: >This topic should go ngtrans, but ... > > > I have a very serious request. for those of us who constantly use > > http over IPv6, it is very very annoying to see non-synchronized > > content > >And, we have no way to know if the contents is outdated, since we can't >guess our proxy connect to the server via IPv4 or via IPv6. Both machines are synchronized every 30 minutes. - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 22:30:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T5U9dP017654 for ; Thu, 28 Jun 2001 22:30:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5T5U9ra017653 for ipng-dist; Thu, 28 Jun 2001 22:30:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T5U6dP017646 for ; Thu, 28 Jun 2001 22:30:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA18372 for ; Thu, 28 Jun 2001 22:30:16 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15041 for ; Thu, 28 Jun 2001 22:30:14 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5T5T6m02093; Fri, 29 Jun 2001 12:29:11 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: <3281.993656225@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Jun 2001 12:29:06 +0700 Message-ID: <2091.993792546@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 28 Jun 2001 22:15:59 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | Please forget about this topic. Done... Apologies for sending lengthy comments on stuff that was old - I half thought I'd seen it before, but my memory just isn't that good... | Hmm, as I wrote in a previous message, I myself we should fix the API | without these "ongoing" stuff. OK. | I don't think so. I believe the protocol stack (normally the kernel) | should prevent (at least) non-privileged users from sending invalid | packets according to the protocol specification. Sure. But that wasn't the point - the point is exactly what does get sent (if anything) when the user does something invalid. I think it is OK to say that that is implementation defined. No correct application will ever care. That broken applications behave differently on different stacks should be a feature, not a bug - it helps identify them as broken sooner. I certainly wasn't suggesting that the stack should be creating invalid packets out of invalid user input, and sending that. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 28 23:00:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T60JdP017696 for ; Thu, 28 Jun 2001 23:00:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5T60JNb017695 for ipng-dist; Thu, 28 Jun 2001 23:00:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5T60EdP017688 for ; Thu, 28 Jun 2001 23:00:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03951 for ; Thu, 28 Jun 2001 23:00:23 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA25767 for ; Thu, 28 Jun 2001 23:00:22 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id PAA22703; Fri, 29 Jun 2001 15:01:28 +0900 (JST) Date: Fri, 29 Jun 2001 15:00:15 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200106281854.LAA00855@feller.mentat.com> References: <200106281854.LAA00855@feller.mentat.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 28 Jun 2001 11:54:24 -0700 (PDT), >>>>> Tim Hartrick said: >> 1. remove extension header issues from the current draft. >> 2. solve (a part of) open issues except extension header ones. >> 3. based on the result of 2, issue a revised version of the rfc2292bis >> draft. The draft name would be either >> draft-ietf-ipngwg-rfc2292bis-03.txt >> or >> draft-ietf-ipv6-rfc2292bis-00.txt >> 4. solve extension header issues, and issue a new draft entitled >> (e.g.) draft-ietf-ipv6-exthdr-api-00.txt >> > Hmm.. I would say I do object for this reason. If I remember the issues > related to MIPv6 binding updates and the like and I remember the discussions > that occurred on this list regarding them I wasn't under the impression > that we were substantially far from being able to solve some of the in- > flexibility issues. I wouldn't want to see us rip all that content out of > the spec unless we are pretty sure that consensus can't be reached. > What scares me about splitting this content off is that it opens up an > opportunity for complete redesign of the entire mechanism if it is not > tightly controlled. We don't have a history of that kind of discipline > in these areas and I am concerned that we will get a complete redesign, > and pile and piles of obsoleted code, when only tweaks are required. I do understand the concern...but, then, do you have a concrete idea to realize the flexibility? > What I would prefer is that we take the discussion to the apifolks mailing > list, where we have a good focused group, so that we can actually get the > work done. We aren't that far away. It just requires cycles to be applied. As for the place to discuss the issue, I don't mind to go to the apifolks list. A possible problem of the list, though, is that it is not so widely common, and some people who are interested in the topic and are writing code may not able to join the discussion (actually, I've already got several e-mail messages about what the list was or howb an interested person could subscribe to the list). So, unless there is a strong objection to being stay here, I think we should still discuss the issue in the list. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 05:12:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TCCMdP018315 for ; Fri, 29 Jun 2001 05:12:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TCCKJ5018314 for ipng-dist; Fri, 29 Jun 2001 05:12:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TCCGdP018307 for ; Fri, 29 Jun 2001 05:12:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18380 for ; Fri, 29 Jun 2001 05:12:26 -0700 (PDT) Received: from ims.hub.nih.gov (ims.hub.nih.gov [128.231.90.111]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01764 for ; Fri, 29 Jun 2001 05:12:06 -0700 (PDT) Received: by ims.hub.nih.gov with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 08:11:44 -0400 Message-ID: From: "Januszewski, Joseph (CIT)" To: "'ipng@sunroof.eng.sun.com'" Subject: BugTraq IPv6 Post from SANS.org Date: Fri, 29 Jun 2001 08:11:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This was apparently posted first to BugTraq, and was included in this AMs SANS.org/Network Computing "Security Alert Consensus". Apologies in advance for the cross-post, but wasn't sure of the numbers of IPv6ers on BugTraq, part of SANS, etc. *** {01.26.040} Cross - IPv6 mishandling of embedded IPv4 addresses concern An interesting post was made about potential malicious situations that could arise from improperly implemented IPv6 stacks. The problems range from network-based packet games (denial of service floods, etc.), to various ways to bypass IPv4 access control restrictions. Anyone interested in the issue are encouraged to look at the test script included with the post. Source: SecurityFocus Bugtraq http://archives.neohapsis.com/archives/bugtraq/2001-06/0321.html Copyright (c) 2001 Network Computing, a CMP Media LLC publication. All Rights Reserved. Joseph J. Januszewski, III National Institutes of Health Center for Information Technology Bethesda, Maryland jjanusze@mail.nih.gov -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 09:39:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TGdNdP018643 for ; Fri, 29 Jun 2001 09:39:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TGdMFl018642 for ipng-dist; Fri, 29 Jun 2001 09:39:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TGdIdP018635 for ; Fri, 29 Jun 2001 09:39:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17273 for ; Fri, 29 Jun 2001 09:39:28 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01705 for ; Fri, 29 Jun 2001 10:39:26 -0600 (MDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA17310; Fri, 29 Jun 2001 09:39:26 -0700 (PDT) Received: from garcia.mentat.com (garcia [192.88.122.235]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id JAA08707; Fri, 29 Jun 2001 09:39:26 -0700 (PDT) Received: (from tim@localhost) by garcia.mentat.com (8.9.3+Sun/8.9.3) id JAA03836; Fri, 29 Jun 2001 09:42:59 -0700 (PDT) Date: Fri, 29 Jun 2001 09:42:59 -0700 (PDT) From: Tim Hartrick Message-Id: <200106291642.JAA03836@garcia.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: complete the advanced API (rfc2292bis) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > > What scares me about splitting this content off is that it opens up an > > opportunity for complete redesign of the entire mechanism if it is not > > tightly controlled. We don't have a history of that kind of discipline > > in these areas and I am concerned that we will get a complete redesign, > > and pile and piles of obsoleted code, when only tweaks are required. > > I do understand the concern...but, then, do you have a concrete idea > to realize the flexibility? > I was pretty sure that I and others made some proposals during the last discussion of this topic that were close to working for at least the receiving and sending of ancillary data. It has been a while but I am sure we started down the path of a solution. I guess I can try and dredge the discussion out of the archives. As I understand the issues, applications may want to be able to specify where the non-fragmentable part of the datagram ends and where the fragmentable part begins. They also need to be able to specify where in a chain of extension headers the stack should insert AUTH or ESP headers. Similarly we need a mechanism which allows an application to determine when receiving a datagram where the fragmentable part of the datagram begins and where in the chain of extension headers an AUTH or ESP header had been located. Are there other areas of inflexibility that are causing real problems today as opposed to possible problems a few years from now? > > What I would prefer is that we take the discussion to the apifolks mailing > > list, where we have a good focused group, so that we can actually get the > > work done. We aren't that far away. It just requires cycles to be applied. > > As for the place to discuss the issue, I don't mind to go to the > apifolks list. A possible problem of the list, though, is that it is > not so widely common, and some people who are interested in the topic > and are writing code may not able to join the discussion (actually, > I've already got several e-mail messages about what the list was or howb > an interested person could subscribe to the list). So, unless there > is a strong objection to being stay here, I think we should still > discuss the issue in the list. > I have sympathy for this view. My only concern is that we have people that write the code to implement the API driving the discussion. People that don't have a dog in the fight are free to propose all sorts of crazy things which will translate into long discussions that lead nowhere but wasted time on im- plementing things that won't work or won't be used. We are now in the process of doing our third attempt at finishing the coding of this API. The first implementation was completely wasted because the original advanced API draft was essentially thrown out. There will soon be a need for adding the API extensions for scoped addresses. I don't think any implementor has the luxury of writing anymore throw away API code. We certainly don't. If we keep the discussion focused on the immediate problems then we certainly can get this done without breaking out yet another API document. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 10:43:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5THhtdP018717 for ; Fri, 29 Jun 2001 10:43:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5THhsRI018716 for ipng-dist; Fri, 29 Jun 2001 10:43:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5THhndP018709 for ; Fri, 29 Jun 2001 10:43:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02547 for ; Fri, 29 Jun 2001 10:43:59 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04662 for ; Fri, 29 Jun 2001 11:44:17 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA27114; Sat, 30 Jun 2001 02:19:11 +0900 (JST) Date: Sat, 30 Jun 2001 02:12:35 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <2091.993792546@brandenburg.cs.mu.OZ.AU> References: <3281.993656225@brandenburg.cs.mu.OZ.AU> <2091.993792546@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Jun 2001 12:29:06 +0700, >>>>> Robert Elz said: > | Please forget about this topic. > Done... Apologies for sending lengthy comments on stuff that was > old - I half thought I'd seen it before, but my memory just isn't that > good... No, that was my bad, I should've cited the related part only. Anyway, thanks for the kind reply. > | I don't think so. I believe the protocol stack (normally the kernel) > | should prevent (at least) non-privileged users from sending invalid > | packets according to the protocol specification. > Sure. But that wasn't the point - the point is exactly what does get > sent (if anything) when the user does something invalid. I think it is > OK to say that that is implementation defined. No correct application will > ever care. That broken applications behave differently on different stacks > should be a feature, not a bug - it helps identify them as broken sooner. > I certainly wasn't suggesting that the stack should be creating invalid > packets out of invalid user input, and sending that. Hmm, I see. So, "the API does not prohibit the bad behavior, but the underlying kernel would (or might) prevent the bad packets from beiing sent on the wire." Right? Then, I'm perhaps okay with it. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 11:39:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TIdrdP018885 for ; Fri, 29 Jun 2001 11:39:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TIdrvH018884 for ipng-dist; Fri, 29 Jun 2001 11:39:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TIdndP018877 for ; Fri, 29 Jun 2001 11:39:49 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16221 for ; Fri, 29 Jun 2001 11:39:57 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09297 for ; Fri, 29 Jun 2001 12:39:48 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id DAA29606; Sat, 30 Jun 2001 03:39:39 +0900 (JST) Date: Sat, 30 Jun 2001 03:38:24 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200106291642.JAA03836@garcia.mentat.com> References: <200106291642.JAA03836@garcia.mentat.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 80 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Jun 2001 09:42:59 -0700 (PDT), >>>>> Tim Hartrick said: > I was pretty sure that I and others made some proposals during the last > discussion of this topic that were close to working for at least the receiving > and sending of ancillary data. It has been a while but I am sure we started > down the path of a solution. I guess I can try and dredge the discussion > out of the archives. Okay, then I'll wait for the archive. > As I understand the issues, applications may want to be able to specify > where the non-fragmentable part of the datagram ends and where the fragmentable > part begins. They also need to be able to specify where in a chain of > extension headers the stack should insert AUTH or ESP headers. > Similarly we need a mechanism which allows an application to determine > when receiving a datagram where the fragmentable part of the datagram begins > and where in the chain of extension headers an AUTH or ESP header had > been located. Hmm, this approach seems to be able to keep compatibility with the current rfc2292bis spec. So, if this kind of approach can get a consensus, I think I'm happy with it. > Are there other areas of inflexibility that are causing real problems today > as opposed to possible problems a few years from now? I hope not, but just like MIP6 broke the existing recommended order of extension headers, I'm not sure even about the near future. However, I agree that we should try to keep the change as minimum as possible while introducing minimum flexibility. >> > What I would prefer is that we take the discussion to the apifolks mailing >> > list, where we have a good focused group, so that we can actually get the >> > work done. We aren't that far away. It just requires cycles to be applied. >> >> As for the place to discuss the issue, I don't mind to go to the >> apifolks list. A possible problem of the list, though, is that it is >> not so widely common, and some people who are interested in the topic >> and are writing code may not able to join the discussion (actually, >> I've already got several e-mail messages about what the list was or howb >> an interested person could subscribe to the list). So, unless there >> is a strong objection to being stay here, I think we should still >> discuss the issue in the list. > I have sympathy for this view. My only concern is that we have people that > write the code to implement the API driving the discussion. People that don't > have a dog in the fight are free to propose all sorts of crazy things which > will translate into long discussions that lead nowhere but wasted time on im- > plementing things that won't work or won't be used. Right, that's exactly the reason why the api list was created. > We are now in the process of doing our third attempt at finishing the coding > of this API. The first implementation was completely wasted because the > original advanced API draft was essentially thrown out. There will soon be > a need for adding the API extensions for scoped addresses. I don't think any > implementor has the luxury of writing anymore throw away API code. We certainly > don't. > If we keep the discussion focused on the immediate problems then we certainly > can get this done without breaking out yet another API document. I agree on this point. But as for the discussion place, I'd propose keep the ipngwg list for now. The important thing is, as you just mentioned, that those who are writing code speak up about based on their standpoints. (Even if we can make a "reasonable" consensus, we'll eventually have to discuss it here at the ipngwg list, and will have a possibility of suffering from "crazy" ideas). But I don't stick to the place. If many implementors want to move the place to the API list, I'm willing to follow the decision. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 12:31:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TJVsdP019006 for ; Fri, 29 Jun 2001 12:31:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TJVsWw019005 for ipng-dist; Fri, 29 Jun 2001 12:31:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TJVodP018998 for ; Fri, 29 Jun 2001 12:31:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04741 for ; Fri, 29 Jun 2001 12:31:59 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13973 for ; Fri, 29 Jun 2001 13:31:56 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA27174 for ; Fri, 29 Jun 2001 15:24:48 -0500 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v4.96) with ESMTP id f5TJVu796266 for ; Fri, 29 Jun 2001 15:31:56 -0400 Subject: Duplicate Address Detection on a link-local address To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Fri, 29 Jun 2001 15:31:06 -0400 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 06/29/2001 03:31:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've got a question on Duplicate Address Detection for link-local addresses. DAD states that a node must join the solicited-node multicast group for the tentative address before beginning DAD. Multicast Listener Discovery states that as part of joining a link-scope multicast groups, other than the all-nodes group, a MLD Report message must be sent. MLD also states that the source IP address in the MLD message must be a link-local address. So, what should be put in the source address for the MLD Report when the a link-local address is being assigned and no other addresses exist for the link? Since the link-local address is tentative, it shouldn't be placed as the source address in the MLD Report. Since the MLD Report requires a link-local source IP address, an MLD Report can't be sent. I'm guessing that the correct behavior is as follows when assigning the initial link-local address to an interface: - We notify the adapter that we want to receive any packets destined for the solicited-node multicast group derived from the link-local address. We do *not* send a MLD Report at this time, though, as we do not have a non-tentative link-local address to place in the source IP address. I've been told that this might cause problems when a LAN is bridged a bridge is checking MLD messages to determine where listeners are in an effort to avoid forwarding packets when there are no listeners. - We perform Duplicate Address Detection. Since we have notified the adapter to forward multicast packets for the solicited node multicast group, we should receive any Neighbor Solicitations from other nodes performing DAD as well (assuming that bridges are forwarding multicast packets in the absence of MLD messages). - If we fail DAD, we would notify the adapter that we no longer want to receive packets destined for the solicited-node multicast group which we previously registered. If we succeed with DAD, we send an MLD Report for the solicited-node multicast group. There are some other alternatives which might make sense if bridges are keying off MLD Reports to determine whether to forward multicast packets: - When assigning a tentative link-local address and no other address exists for the router, send an MLD Report with the source address set to the unspecified address. This is currently not allowed by MLD and might result in the packet failing verification by a bridge/router and therefore being discarded. - Send the MLD report using the tentative link-local address as the source IP address. We aren't supposed to use a tentative address as the source IP address, but I don't think it will break anything in this case. If a node already owns the IP address or is itself running DAD, this would result in an extra MLD Report being sent to the bridge/router. And if the address is not currently in use and no one is performing DAD then I would need to send an MLD Report after assigning the link-local address anyway. Still, I'm not real fond of idea of sending a packet using a tentative address as the source IP address. This only applies for the first (and, for us anyway, the only) link-local address assigned to the interface. All subsequent addresses would be processed as described in the RFCs: we would join the appropriate solicited-node multicast group prior to starting DAD vs. waiting until DAD is completed. Roy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 13:19:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TKJXdP019263 for ; Fri, 29 Jun 2001 13:19:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TKJXxE019262 for ipng-dist; Fri, 29 Jun 2001 13:19:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TKJRdP019255 for ; Fri, 29 Jun 2001 13:19:27 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.3+Sun/8.11.3) id f5TKIRT29119 for ipng@sunroof.eng.sun.com; Fri, 29 Jun 2001 13:18:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5PDwldP003399 for ; Mon, 25 Jun 2001 06:58:47 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24853 for ; Mon, 25 Jun 2001 06:58:55 -0700 (PDT) From: Roland.Meyer@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23307 for ; Mon, 25 Jun 2001 06:58:54 -0700 (PDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f5PDvu922530 for ; Mon, 25 Jun 2001 16:57:56 +0300 (EET DST) Received: from esebh03nok.ntc.nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 25 Jun 2001 16:58:52 +0300 Received: by esebh03nok with Internet Mail Service (5.5.2652.78) id ; Mon, 25 Jun 2001 16:58:53 +0300 Message-ID: To: ipv6mib@ibr.cs.tu-bs.de, ipng@sunroof.eng.sun.com, mibs@ops.ietf.org Subject: IPv6MIB Design Date: Mon, 25 Jun 2001 16:58:49 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Perhaps somebody can answer the following questions: What is the current state of the IPv6MIB design? Where can one find (preliminary) results of the design work? Thanks, Roland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 14:15:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TLFndP019421 for ; Fri, 29 Jun 2001 14:15:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TLFn6n019420 for ipng-dist; Fri, 29 Jun 2001 14:15:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TLFjdP019413 for ; Fri, 29 Jun 2001 14:15:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18514 for ; Fri, 29 Jun 2001 14:15:55 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20480 for ; Fri, 29 Jun 2001 15:15:53 -0600 (MDT) Received: from mira-sjc5-2.cisco.com (mira-sjc5-2.cisco.com [171.71.163.16]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f5TLFRr04721; Fri, 29 Jun 2001 14:15:29 -0700 (PDT) Received: from stewart.chicago.il.us (sj-dial-6-206.cisco.com [10.21.58.207]) by mira-sjc5-2.cisco.com (Mirapoint) with ESMTP id AJZ01310 (AUTH rrs); Fri, 29 Jun 2001 14:15:17 -0700 (PDT) Message-ID: <3B3CEFDC.5D43631A@stewart.chicago.il.us> Date: Fri, 29 Jun 2001 16:15:08 -0500 From: Randall Stewart at work X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: IPNG , TSV WG list Subject: SCTP and address scoping Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All: I have just released to the drafts editor: draft-stewart-tsvwg-sctpipv6-txt.00 It should be showing up soon :> Now this still is NOT totally complete.. Steve Deering still had some text to add, but I ran out of time considering my vacation and the upcoming drafts cut off .. sorry Steve :< So I am going to, so to speak, submit and run :) I am sure I will return to a nice long discussion thread to find amongst the email barage while I am gone for the next few weeks :) Please take a moment and read this document it is only a few pages (3) and it would be helpful if all you NG'ers could put some input into the document to make sure we have covered all the bases.. The concept here, for those of you that may have missed some of this talk a few months ago is that in SCTP the INIT/INIT-ACK (similar to SYN/SYN-ACK in TCP) carries with it lists of addresses IPv4 AND IPv6. This gives the peers multi-homing in the association. But there is a slight rub with address scoping in IPv6... i.e. which addresses do you include when? This draft discusses this issue and I kindly ask for all of your input.. Thanks R -- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 14:17:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TLHMdP019440 for ; Fri, 29 Jun 2001 14:17:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TLHMSs019439 for ipng-dist; Fri, 29 Jun 2001 14:17:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TLHHdP019432 for ; Fri, 29 Jun 2001 14:17:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25505 for ; Fri, 29 Jun 2001 14:17:27 -0700 (PDT) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11620 for ; Fri, 29 Jun 2001 14:17:27 -0700 (PDT) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA18487; Fri, 29 Jun 2001 14:17:26 -0700 (PDT) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA19006; Fri, 29 Jun 2001 14:17:26 -0700 (PDT) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id OAA01216; Fri, 29 Jun 2001 14:19:14 -0700 (PDT) Date: Fri, 29 Jun 2001 14:19:14 -0700 (PDT) From: Tim Hartrick Message-Id: <200106292119.OAA01216@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp Subject: Re: complete the advanced API (rfc2292bis) Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, > > > I was pretty sure that I and others made some proposals during the last > > discussion of this topic that were close to working for at least the receiving > > and sending of ancillary data. It has been a while but I am sure we started > > down the path of a solution. I guess I can try and dredge the discussion > > out of the archives. > > Okay, then I'll wait for the archive. > Rather than repost a lot of messages from the archive I will simply give you a pointer into the archive where you can find the discussion. I believe that the core of the last discussion on this topic began with a message by Francis Dupont on December 15, 2000. The subject of that message was "destination option update". In the discussion that followed there was the beginnings of a design to solve the problem, I hope. If so we can just jump right into the middle of that six month old discussion and finish off this issue. Tim Hartrick Mentat Inc. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 16:26:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TNQhdP019608 for ; Fri, 29 Jun 2001 16:26:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5TNQhrJ019607 for ipng-dist; Fri, 29 Jun 2001 16:26:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5TNQddP019600 for ; Fri, 29 Jun 2001 16:26:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13593 for ; Fri, 29 Jun 2001 16:26:49 -0700 (PDT) Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29005 for ; Fri, 29 Jun 2001 17:26:47 -0600 (MDT) Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.40 2001/06/06 21:14:49 root Exp $) with SMTP id XAA22770; Fri, 29 Jun 2001 23:26:45 GMT Received: from fmsmsx18.intel.com ([132.233.48.18]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 29 Jun 2001 23:26:45 0000 (GMT) Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Jun 2001 16:26:43 -0700 Message-ID: <3677E033A5F3D211AC4000A0C96B53EB05C2EA38@FMSMSX94> From: "Herbert, Howard C" To: "'rja@extremenetworks.com'" , "'ipng@sunroof.eng.sun.com'" , "'wg@juniper.net'" Cc: "Connor, Patrick" , "Luhmann, Patrick J" , "Tsao, Gary Y" , "Wartski, Dan" Subject: RE: IPv6 over GigE Date: Fri, 29 Jun 2001 16:26:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ran: We have reviewed your referenced draft including the appendices at: http://www.ietf.org/internet-drafts/draft-ietf-isis-ext-eth-00.txt Intel concurs with the analysis that there is no increase in undetected errors using a jumbo frame size of 9018 bytes. Intel believes that frames as large as 16K bytes are feasible and in fact our current gigabit products support frames sizes up to 16132 bytes (although we are not aware of any switches that support jumbo frames this large). Intel believes that frames larger than 16K are not feasible because of clock resolution issues. Is the IS-IS WG planning to get this proposal standardized through the IEEE 802.3 committee? If not, why not? Intel believes that the best way to proceed in this area is to have these issues (MTU and encapsulation formats) worked in conjunction with the IEEE 802.3 committee. Howard C. Herbert Product Architect Intel Corporation LAN Access Division 480-554-3116 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 20:35:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5U3ZZdP019812 for ; Fri, 29 Jun 2001 20:35:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5U3ZYHI019811 for ipng-dist; Fri, 29 Jun 2001 20:35:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5U3ZSdP019804 for ; Fri, 29 Jun 2001 20:35:28 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA22771 for ; Fri, 29 Jun 2001 20:35:37 -0700 (PDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA01666 for ; Fri, 29 Jun 2001 20:35:36 -0700 (PDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25404; Fri, 29 Jun 2001 23:32:48 -0400 Date: Fri, 29 Jun 2001 23:32:47 -0400 (EDT) From: Jim Bound To: Mauro Tortonesi Cc: Francis Dupont , itojun@iijlab.net, horape@tinuviel.compendium.net.ar, ipng@sunroof.eng.sun.com Subject: Re: RFC 2553 bind semantics harms the way to AF independence In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mauro, Sorry for late response. Also I could be out of it till July 16th going on the road to do edu, evangelize, and meet offline with seriously deploying IPv6 enterprises for a few weeks for Ipv6 Forum and U.S. customer of IPv6. But will try to check mail. Don't wait for me to keep talking...............if I don't respond I will if I have to when I get back.......its good for engineers to go on the road once in awile and eat their own dog food so they know if it still tastes good and has nourishment :-----) > > > > => you can use it with the V6ONLY stuff. > > > > > > yes, but on rfc2553-compliant system you cannot have both an AF_INET > > > and an AF_INET6 socket listening on the same port. > > > > Sure you can. By using V6ONLY. Thats the point of the option. It is > > just you must set it via setsocopt. > > > > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one > > using AF_INET and the other AF_INET6. > > RFC2553 does not state this behaviour. in fact many implementations do > not allow to do this. That is unfortuneate. I will make sure this is added to the IPv6 test suites at UNH and ETSI and ask folks at Sun to test for this at Connectathon. KAME should be pretty much ready to test this too. > > can you explain better? let's take two sockets, an AF_INET and an > AF_INET6+V6ONLY one. can i bind them on the same port only if i > bind first to 0.0.0.0 and then to ::? or is it also correct to bind > first to :: and then to 0.0.0.0? > > RFC2553 is silent about this. As I think I said before? Consensus was to keep RFC 2553 silent about this on purpose. You can bind either way as they will be treated as two distinct addresses spaces within the IP protocol suite. So 0.0.0.0,23 and ::,23 is fine because they are different address space now if V6ONLY option is set. I am thinking if others agree we could write all this up in appendix of RFC2553+++bis+IEEE update.................... regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 29 20:40:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5U3eIdP019832 for ; Fri, 29 Jun 2001 20:40:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5U3eIue019831 for ipng-dist; Fri, 29 Jun 2001 20:40:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5U3eEdP019824 for ; Fri, 29 Jun 2001 20:40:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03033 for ; Fri, 29 Jun 2001 20:40:23 -0700 (PDT) Received: from starfruit.itojun.org (tserver.conference.usenix.org [199.103.159.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA16135 for ; Fri, 29 Jun 2001 21:41:21 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id 36D567BB for ; Sat, 30 Jun 2001 12:34:05 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: seamus's message of Fri, 29 Jun 2001 23:32:47 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: RFC 2553 bind semantics harms the way to AF independence From: Jun-ichiro itojun Hagino Date: Sat, 30 Jun 2001 12:34:05 +0900 Message-Id: <20010630033405.36D567BB@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> > With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one >> > using AF_INET and the other AF_INET6. >> RFC2553 does not state this behaviour. in fact many implementations do >> not allow to do this. >That is unfortuneate. I will make sure this is added to the IPv6 test >suites at UNH and ETSI and ask folks at Sun to test for this at >Connectathon. KAME should be pretty much ready to test this too. http://www.kame.net/dev/cvsweb.cgi/kame/kame/kame/bindtest/ checks this case. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 30 08:16:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5UFGpdP020623 for ; Sat, 30 Jun 2001 08:16:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5UFGp1E020622 for ipng-dist; Sat, 30 Jun 2001 08:16:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5UFGldP020615 for ; Sat, 30 Jun 2001 08:16:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11548 for ; Sat, 30 Jun 2001 08:16:55 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07767 for ; Sat, 30 Jun 2001 08:16:50 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C1E0D4D345; Sat, 30 Jun 2001 11:16:36 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA13547; Sat, 30 Jun 2001 11:16:35 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id IAA26450; Sat, 30 Jun 2001 08:16:35 -0700 (PDT) Message-Id: <200106301516.IAA26450@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: roland.meyer@nokia.com Subject: Re: IPv6MIB Design Cc: ipng@sunroof.eng.sun.com, mibs@ops.ietf.org Date: Sat, 30 Jun 2001 08:16:35 -0700 Versions: dmail (solaris) 2.2g/makemail 2.9a Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >What is the current state of the IPv6MIB design? It's more or less waiting for comments from implementors. >Where can one find (preliminary) results of the design work? http://www.aciri.org/fenner/mibs/v6/ or draft-ops-rfc{2011,2012,2013,2096}-update-00.txt Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 30 09:19:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5UGJQdP020675 for ; Sat, 30 Jun 2001 09:19:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f5UGJQ7B020674 for ipng-dist; Sat, 30 Jun 2001 09:19:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f5UGJMdP020667 for ; Sat, 30 Jun 2001 09:19:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03420 for ; Sat, 30 Jun 2001 09:19:31 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.28.96.13]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19065 for ; Sat, 30 Jun 2001 09:19:30 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id f5UGIYm15492; Sat, 30 Jun 2001 23:18:35 +0700 (ICT) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: References: <3281.993656225@brandenburg.cs.mu.OZ.AU> <2091.993792546@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Jun 2001 23:18:34 +0700 Message-ID: <15490.993917914@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sat, 30 Jun 2001 02:12:35 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | Hmm, I see. So, "the API does not prohibit the bad behavior, but the | underlying kernel would (or might) prevent the bad packets from beiing | sent on the wire." Right? Then, I'm perhaps okay with it. It isn't so much that the API doesn't prohibit the bad behaviour, it can - but whether the API says something is legal or not, people are still going to do it. Sometimes it is important to specify exactly what does happen when the user does something stupid, other times it isn't. So, you could say "if the ancillary data contains multiple IPV6_HOPOPTS objects" (which was the particular case in question) "only the first is used", or "only the last is used", or "E2BIG is returned" or ... But there's no real need - allow any of those the implementation prefers and just say it is "implementation defined". This is generally a reasonable response to what are programming errors. On the other hand, errors that the programmer didn't cause (like sending into a socket that has been reset, or to a mobile node's care of address, after it has moved again, or to a global address before the node has acquired one of its own, or ...) need to be specified more precisely, as for those a careful program can look at what happens, and proceed accordingly. And (other than use of raw sockets and similar) the kernel certainly should be avoiding sending bad packets on the wire (not just might). No matter what I do as an idiot programmer, the kernel shouldn't be allowing my mess to escape - or not where it can tell it is wrong. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 30 20:53:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f613rNdP021352 for ; Sat, 30 Jun 2001 20:53:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f613rMFK021351 for ipng-dist; Sat, 30 Jun 2001 20:53:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f613rFdP021341 for ; Sat, 30 Jun 2001 20:53:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19858 for ; Sat, 30 Jun 2001 20:53:25 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11197 for ; Sat, 30 Jun 2001 20:53:24 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA07146 for ; Sun, 1 Jul 2001 12:54:37 +0900 (JST) Date: Sun, 01 Jul 2001 12:51:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <200106292119.OAA01216@feller.mentat.com> References: <200106292119.OAA01216@feller.mentat.com> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Jun 2001 14:19:14 -0700 (PDT), >>>>> Tim Hartrick said: >> > I was pretty sure that I and others made some proposals during the last >> > discussion of this topic that were close to working for at least the receiving >> > and sending of ancillary data. It has been a while but I am sure we started >> > down the path of a solution. I guess I can try and dredge the discussion >> > out of the archives. >> >> Okay, then I'll wait for the archive. > Rather than repost a lot of messages from the archive I will simply give you > a pointer into the archive where you can find the discussion. > I believe that the core of the last discussion on this topic began with > a message by Francis Dupont on December 15, 2000. The subject of that > message was "destination option update". In the discussion that followed > there was the beginnings of a design to solve the problem, I hope. > If so we can just jump right into the middle of that six month old > discussion and finish off this issue. Thanks for the pointer. I'll reread the past discussion from the list archive, and will continue the discussion later. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Jun 30 20:53:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f613rMdP021349 for ; Sat, 30 Jun 2001 20:53:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) id f613rLLC021348 for ipng-dist; Sat, 30 Jun 2001 20:53:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Beta12+Sun/8.12.0.Beta12) with ESMTP id f613rEdP021334 for ; Sat, 30 Jun 2001 20:53:14 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19854 for ; Sat, 30 Jun 2001 20:53:24 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA12075 for ; Sat, 30 Jun 2001 20:53:22 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA07143 for ; Sun, 1 Jul 2001 12:54:35 +0900 (JST) Date: Sun, 01 Jul 2001 12:50:54 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: complete the advanced API (rfc2292bis) In-Reply-To: <15490.993917914@brandenburg.cs.mu.OZ.AU> References: <3281.993656225@brandenburg.cs.mu.OZ.AU> <2091.993792546@brandenburg.cs.mu.OZ.AU> <15490.993917914@brandenburg.cs.mu.OZ.AU> User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) Emacs/21.0 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 30 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 30 Jun 2001 23:18:34 +0700, >>>>> Robert Elz said: > | Hmm, I see. So, "the API does not prohibit the bad behavior, but the > | underlying kernel would (or might) prevent the bad packets from beiing > | sent on the wire." Right? Then, I'm perhaps okay with it. > It isn't so much that the API doesn't prohibit the bad behaviour, it > can - but whether the API says something is legal or not, people are > still going to do it. > Sometimes it is important to specify exactly what does happen when the > user does something stupid, other times it isn't. > So, you could say "if the ancillary data contains multiple IPV6_HOPOPTS > objects" (which was the particular case in question) "only the first is > used", or "only the last is used", or "E2BIG is returned" or ... > But there's no real need - allow any of those the implementation prefers > and just say it is "implementation defined". Okay, thanks for the explanation. Actually, I did not intend to require the spec to clearly state that "the underlying kernel would (or might) prevent the bad packets...", but just would like to make the background intention clear. Thanks for the explanation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------