From owner-ipng@sunroof.eng.sun.com Sat Sep 1 07:15:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81EFE40013742 for ; Sat, 1 Sep 2001 07:15:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81EFEnu013741 for ipng-dist; Sat, 1 Sep 2001 07:15: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81EFB40013734 for ; Sat, 1 Sep 2001 07:15:11 -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 HAA01007 for ; Sat, 1 Sep 2001 07:15:21 -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 HAA23846 for ; Sat, 1 Sep 2001 07:15:20 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f81EFJA20184 for ; Sat, 1 Sep 2001 17:15:19 +0300 Date: Sat, 1 Sep 2001 17:15:19 +0300 (EEST) From: Pekka Savola To: Subject: Routing Header Considered Harmful Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, When discussing Linux IPv6 implementation, David Stevens brought up a problem with routing header w/ Hosts. RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers) forward source routed packets. Routing header works so that the next hop is always written to destination address field and the rest of the path to routing header fields. Problem with this is that: 1) it's impossible to authenticate using AH or the like as the header is rewritten all the time 2) it allows you to use _any_ IPv6 node to reflect your traffic (, even to locations that wouldn't normally be routable) For example: or even: host1 --- rtr1 - INET - rtr2 --- host2 - rtr2 --- host2 | / | rtr3 -/ host3 | host3 or even (same link): - rtr2 -+- host2 | +- host3 rtr2 performs strict ingress filtering on tcp destination port 80. host2 is a web server. (IMO, we _cannot_ assume every device in the path must be knowledgeable of all the possible extension headers, and implications of parsing them). Now host1 could write a packet to dst host2, dport 80, with routing header to: 'rtr3, host3' (or even just 'host3', there need not necessarily be rtr3). (To avoid this, you would have to perform strict ingress filtering in _all_ of your links, be they internal or not). Now you can pass traffic unmolested to internal hosts. Or even John Doe in the Internet! Needless to say this will result in very, very much ugliness sooner or later! There is no reason to believe IPv6 Routing Header is any better from security point of view than IPv4 source routing. And IPv4 source routing is disabled, luckily, very often. This won't help: --8<-- Security Considerations The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401]. --8<-- At this point one could say a classic "WTF? Over." With this important core protocols, we definitely _must not_ hide _all_ the security considerations under the carpet by ambiguous reference to the ipsec security pixie dust. More discussion on approaches to tackle this is needed, but IMO: Forwarding datagrams with Routing Header SHOULD be configurable. On Hosts, Routing Header MUST be ignored by default. On Routers, Routing Header SHOULD be ignored by default. (I'd only recommend allowing routing header on in backbone routers) Does disabling routing header break anything significant? If it does, the security of that must be analyzed as well. -- 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 Sat Sep 1 08:06:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81F6d40013817 for ; Sat, 1 Sep 2001 08:06:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81F6dgs013816 for ipng-dist; Sat, 1 Sep 2001 08:06:39 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81F6Z40013809 for ; Sat, 1 Sep 2001 08:06:35 -0700 (PDT) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05198; Sat, 1 Sep 2001 11:06:46 -0400 (EDT) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.11.5+Sun/8.11.5) with ESMTP id f81F6fE21582; Sat, 1 Sep 2001 11:06:41 -0400 (EDT) Message-Id: <200109011506.f81F6fE21582@strat.East.Sun.COM> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Pekka Savola cc: ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: Re: Routing Header Considered Harmful In-Reply-To: Message from Pekka Savola of "Sat, 01 Sep 2001 17:15:19 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 01 Sep 2001 11:06:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Routing header works so that the next hop is always written to destination > address field and the rest of the path to routing header fields. > > Problem with this is that: > 1) it's impossible to authenticate using AH or the like as the header is > rewritten all the time AH has provisions for mutable but predictable data such as the contents of routing headers. See rfc2402 Appendix 2. -Sebastien -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 1 09:28:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81GSp40013892 for ; Sat, 1 Sep 2001 09:28:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81GSoW5013891 for ipng-dist; Sat, 1 Sep 2001 09:28: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81GSl40013884 for ; Sat, 1 Sep 2001 09:28:47 -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 JAA18636 for ; Sat, 1 Sep 2001 09:28:58 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16286 for ; Sat, 1 Sep 2001 09:28:56 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f81GSdt04300; Sat, 1 Sep 2001 18:28:39 +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 SAA04321; Sat, 1 Sep 2001 18:28:39 +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 f81GSdl99377; Sat, 1 Sep 2001 18:28:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109011628.f81GSdl99377@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Sat, 01 Sep 2001 17:15:19 +0300. Date: Sat, 01 Sep 2001 18:28:39 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers) forward source routed packets. => this is not true, hosts are not supposed to forward source routed packets to other nodes. Many implementations have a flag which enforces this behavior by default because disabling source route breaks things and enabling forwarding breaks security). Routing header works so that the next hop is always written to destination address field and the rest of the path to routing header fields. Problem with this is that: 1) it's impossible to authenticate using AH or the like as the header is rewritten all the time => this is not true (and AH authenticates routing headers, rewritting doesn't matter because it is predictable). 2) it allows you to use _any_ IPv6 node to reflect your traffic (, even to locations that wouldn't normally be routable) => this is not true if RFC 2460 section 8.4 is correctly implemented. For example: or even: host1 --- rtr1 - INET - rtr2 --- host2 - rtr2 --- host2 | / | rtr3 -/ host3 | host3 or even (same link): - rtr2 -+- host2 | +- host3 rtr2 performs strict ingress filtering on tcp destination port 80. host2 is a web server. (IMO, we _cannot_ assume every device in the path must be knowledgeable of all the possible extension headers, and implications of parsing them). Now host1 could write a packet to dst host2, dport 80, with routing header to: 'rtr3, host3' (or even just 'host3', there need not necessarily be rtr3). (To avoid this, you would have to perform strict ingress filtering in _all_ of your links, be they internal or not). Now you can pass traffic unmolested to internal hosts. Or even John Doe in the Internet! => host2 should drop the packet on the floor. There is no reason to believe IPv6 Routing Header is any better from security point of view than IPv4 source routing. => I disagree, read RFC 2460 section 8.4 (or better, ask your implementors to apply it :-). And IPv4 source routing is disabled, luckily, very often. => I am against this opinion that suggests to remove all devices which can give a security issue if misimplemented. This is not really better than the opposite (cf. active "attachement" discussions). This won't help: --8<-- Security Considerations The security features of IPv6 are described in the Security Architecture for the Internet Protocol [RFC-2401]. --8<-- At this point one could say a classic "WTF? Over." With this important core protocols, we definitely _must not_ hide _all_ the security considerations under the carpet by ambiguous reference to the ipsec security pixie dust. => I disagree (again). The security features of IPv6 are simply IPsec. More discussion on approaches to tackle this is needed, but IMO: Forwarding datagrams with Routing Header SHOULD be configurable. => I agree, in fact I believe all generic node (i.e. host and router) implementations have some flags to control this. On Hosts, Routing Header MUST be ignored by default. On Routers, Routing Header SHOULD be ignored by default. (I'd only recommend allowing routing header on in backbone routers) => I disagree because of: Does disabling routing header break anything significant? => YES, IT DOES! If it does, the security of that must be analyzed as well. => it was and it will be but the security argument should be applied against two address pseudo-firewalls, not against source routing. And if you need something to have nightmares this night, just look at the home address option (same property than a one address source route, but on the source address in place of the destination) or tunnelling, esp. ngtrans devices which can hide both the real source and destionation addresses without trails... 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 Sep 1 09:53:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81GrR40013928 for ; Sat, 1 Sep 2001 09:53:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81GrR9d013927 for ipng-dist; Sat, 1 Sep 2001 09:53:27 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81GrO40013920 for ; Sat, 1 Sep 2001 09:53:24 -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 JAA20620 for ; Sat, 1 Sep 2001 09:53:35 -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 KAA04625 for ; Sat, 1 Sep 2001 10:53:30 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f81GrQX20974; Sat, 1 Sep 2001 19:53:26 +0300 Date: Sat, 1 Sep 2001 19:53:26 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Subject: Re: Routing Header Considered Harmful In-Reply-To: <200109011628.f81GSdl99377@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, 1 Sep 2001, Francis Dupont wrote: > In your previous mail you wrote: > > RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers) > forward source routed packets. > > => this is not true, hosts are not supposed to forward source routed > packets to other nodes. Many implementations have a flag which enforces > this behavior by default because disabling source route breaks things > and enabling forwarding breaks security). Please read RFC2460 4.4. Nowhere does it say that hosts should not forward source-routed packets. E.g.: If, after processing a Routing header of a received packet, an intermediate node determines that the packet is to be forwarded onto a link whose link MTU is less than the size of the packet, the node must discard the packet and send an ICMP Packet Too Big message to the packet's Source Address. [...] note 'node' not 'router'; also forward 'forward'. > Routing header works so that the next hop is always written to destination > address field and the rest of the path to routing header fields. > > Problem with this is that: > 1) it's impossible to authenticate using AH or the like as the header is > rewritten all the time > > => this is not true (and AH authenticates routing headers, rewritting > doesn't matter because it is predictable). Ok granted, this can be done, but intermediate nodes should at least check for the existance of AH. > 2) it allows you to use _any_ IPv6 node to reflect your traffic (, even > to locations that wouldn't normally be routable) > > => this is not true if RFC 2460 section 8.4 is correctly implemented. > > For example: or even: > > host1 --- rtr1 - INET - rtr2 --- host2 - rtr2 --- host2 > | / | > rtr3 -/ host3 > | > host3 > or even (same link): > > - rtr2 -+- host2 > | > +- host3 > > rtr2 performs strict ingress filtering on tcp destination port 80. host2 > is a web server. (IMO, we _cannot_ assume every device in the path must > be knowledgeable of all the possible extension headers, and implications > of parsing them). > > Now host1 could write a packet to dst host2, dport 80, with routing header > to: 'rtr3, host3' (or even just 'host3', there need not necessarily be > rtr3). (To avoid this, you would have to perform strict ingress filtering > in _all_ of your links, be they internal or not). > > Now you can pass traffic unmolested to internal hosts. Or even John Doe > in the Internet! > > => host2 should drop the packet on the floor. No. AFAICS, RFC 2460 8.4 applies only to the end-node, here host3, replying to the packet: When an upper-layer protocol sends one or more packets in response to a received packet that included a Routing header, the response [...] Response in my book means the final endpoint, not a router or host forwarding the packet to the next hop. Please also note: When an upper-layer protocol sends one or more packets in response to a received packet that included a Routing header, the response packet(s) must not include a Routing header that was automatically derived by "reversing" the received Routing [...] forwarders don't reverse the order for their "responses" (which aren't responses as meant here) (unless they send out some ICMP6 messages, but that's a different story), which implies that response is one sent by the final destination. Thus here, if there is no AH, the packet could go: packet: host1 -> rtr1 -> ... -> rtr2 -> host2 -> rtr3 -> host3 (with routing header) response packet: host3 -> rtr3 -> rtr2 -> ... -> rtr1 -> host1 (without routing header) The defenses have been penetrated in this scenario; the return traffic can flow in asymmetric fashion. > There is no reason to believe IPv6 Routing Header is any better from > security point of view than IPv4 source routing. > > => I disagree, read RFC 2460 section 8.4 (or better, ask your implementors > to apply it :-). Please read it again keeping in mind what 'response' means. > --8<-- > Security Considerations > > The security features of IPv6 are described in the Security > Architecture for the Internet Protocol [RFC-2401]. > --8<-- > > At this point one could say a classic "WTF? Over." With this important > core protocols, we definitely _must not_ hide _all_ the security > considerations under the carpet by ambiguous reference to the ipsec > security pixie dust. > > => I disagree (again). The security features of IPv6 are simply IPsec. One can not say there aren't security considerations to the routing header use. IPSec can help with them, but unless they're identified, it's just some "magic" that may give a warm fuzzy feeling. > Does disabling routing header break anything significant? > > => YES, IT DOES! Please elaborate. Something related to Mobile IPv6? They should be using AH anyway. > If it does, the security of that must be analyzed as well. > > => it was and it will be but the security argument should be applied > against two address pseudo-firewalls, not against source routing. > And if you need something to have nightmares this night, just look at > the home address option (same property than a one address source route, > but on the source address in place of the destination) or tunnelling, > esp. ngtrans devices which can hide both the real source and destionation > addresses without trails... Most ngtrans methods can be used for some kind of DoS attacks; with some, you can even disguise yourself pretty well. These are being worked. This, on the other hand, gives the malicious party an active and really configurable to option to really work around even best defenses. I haven't taken a look at home address option too deeply, but wasn't it just that Mobile IPv6 was put to freeze due to improper security considerations? -- 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 Sat Sep 1 10:23:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81HN140013951 for ; Sat, 1 Sep 2001 10:23:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81HN1Qd013950 for ipng-dist; Sat, 1 Sep 2001 10:23: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81HMv40013943 for ; Sat, 1 Sep 2001 10:22:57 -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 KAA16123 for ; Sat, 1 Sep 2001 10:23:05 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28783 for ; Sat, 1 Sep 2001 11:23:34 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f81HMJt05674; Sat, 1 Sep 2001 19:22: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 TAA04559; Sat, 1 Sep 2001 19:22: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 f81HM7l99552; Sat, 1 Sep 2001 19:22:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Alex Conta , alh-ietf@tndh.net, Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Wed, 29 Aug 2001 10:15:02 PDT. <15245.8982.469052.649969@thomasm-u1.cisco.com> Date: Sat, 01 Sep 2001 19:22:07 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex, perhaps I was unfair about the c) option. I understood that you'd like to replace the MF classifier on the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call the 5F classifier by a simpler MF classifier with the flow label in place of protocol and ports. This cancels the efficiency issue of the extension header chain of IPv6. My first concern is the 5F reclassification is a bad idea because an ACL-like classifier will never give what I want as an user. This is too rigid, not real-time, ... The second concern is with ESP: the 5F classifier wants to look at bits I want to hide. No conciliation is possible, IPsec people (like Michael) will *never* accept to reveal transport layer or payload details for a 5F classifier. This point raises a real question about the c) option: what will be the content of a flow label with a diffserv semantic? There are two kinds of proposals: - to pack some bits from protocol/ports into the flow label (A.1 or A.2 appendix of your I-D). This will make mapping of a 5F classifier to a flow label based one easy but the two previous concerns apply. I vote no for this interpretation of c). - to use an opaque value (a PHB ID as in 7.1.1 of your I-D is an obvious candidate) but this doesn't work if a ISP doesn't trust you: - there is no easy map from a 5F classifier - or the PHB is standard and doesn't provide more information than the DSCP, or it is not and only some ISPs can interpret it. This kind of flow label is an extension of the DS field, it doesn't match the requirements for the (broken) MF reclassification and is too short for advanced features (for instance a ISP should not rewrite it because it is hard to restore it). I don't vote for or against the second interpretation of c) because something is clearly broken somewhere. Tony claims that Diffserv is broken and I believe he is right: at least the MF classifier stuff has to be more understable... This is a ISP requirement, can ISP people explain what they need? 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 Sep 1 10:43:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81Hhj40013981 for ; Sat, 1 Sep 2001 10:43:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81Hhikm013980 for ipng-dist; Sat, 1 Sep 2001 10:43: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81Hhf40013973 for ; Sat, 1 Sep 2001 10:43: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 KAA24075 for ; Sat, 1 Sep 2001 10:43:53 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25478 for ; Sat, 1 Sep 2001 11:43:48 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f81HhRt06243; Sat, 1 Sep 2001 19:43:27 +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 TAA04663; Sat, 1 Sep 2001 19:43:27 +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 f81HhRl99596; Sat, 1 Sep 2001 19:43:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109011743.f81HhRl99596@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Brian E Carpenter , ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) In-reply-to: Your message of Fri, 31 Aug 2001 17:53:29 +0700. <1797.999255209@brandenburg.cs.mu.OZ.AU> Date: Sat, 01 Sep 2001 19:43:27 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: | It's the former; if an ISP chooses to disbelieve the upstream ISP, | and re-classify the traffic, the semantics of the transport | header are exactly the information of interest. No they're not. There is nothing at all in any transport header of relevance that contains anything in any way related to QoS. => I agree, the whole stuff about MF re-classification on the 5/6 tuple seems silly to me. For diffserv, there's no out of band signalling, so every packet needs to be labelled so it can get the correct processing. => so even if MF re-classification on the 5/6 tuple is the wrong problem we still have to investigate (:-). But IPv6 has another way - you can simply request that the sender add a new header (more on that in a second), require it to appear immediately after the hop-by-hop options (if any, or the IPv6 header otherwise) for it to be effective anyway (ie: you look that far, and assume default processing if the header doesn't appear there). In this header you can stick all the QoS classification information you're ever going to need. That can even look like a transport protocol port number combination if you like - just don't expect the port numbers (or even transport protocol) to have any relationship at all with the ones the transport protocol or its ports that are actually being used. I'll pick values that generate the QoS effects that I desire (which might sometimes be a 1::1 mapping from the value actually being used, but also might not be). => this solution was suggested in the last discussion about how to do MF classification on the 5/6 tuple at very high speed (I believe this discussion was initiated by Thomas Eklund). My only concern is simple: is it a solution for the wrong problem? Regards Francis.Dupont@enst-bretagne.fr PS: I sent my mail to Brian before reading your mail... The PHB ID proposal can (should?) give better options than to put fake protocol/ports into the QoS option for silly MF classifiers. If the overhead of the QoS option is acceptable we should have to design smart way to use 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 Sep 1 11:20:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81IK140014037 for ; Sat, 1 Sep 2001 11:20:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81IK1DA014036 for ipng-dist; Sat, 1 Sep 2001 11:20: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81IJv40014029 for ; Sat, 1 Sep 2001 11:19:57 -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 LAA26060 for ; Sat, 1 Sep 2001 11:20:07 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27286 for ; Sat, 1 Sep 2001 12:20:35 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f81IJwt07285; Sat, 1 Sep 2001 20:19:58 +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 UAA04842; Sat, 1 Sep 2001 20:19: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 f81IJwl99735; Sat, 1 Sep 2001 20:19:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109011819.f81IJwl99735@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Sat, 01 Sep 2001 19:53:26 +0300. Date: Sat, 01 Sep 2001 20:19:58 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => this is not true, hosts are not supposed to forward source routed > packets to other nodes. Many implementations have a flag which enforces > this behavior by default because disabling source route breaks things > and enabling forwarding breaks security). Please read RFC2460 4.4. Nowhere does it say that hosts should not forward source-routed packets. => 4.4 just describes how to process a source route header, it doesn't specify if/why a node should process it. This is implementation dependent and of course a clever implementer won't blindly forward source routed packets. Of course the host requirement document should fix that (as RFC 1122 section 3.3.5). A statement like mine is likely to be in it... (note that RFC 1122 is applied to IPv6 too for many details, this doesn't really replace a real spec but it helps (:-), in your case RFC 1122 should be enough, not a surprise...) > => this is not true (and AH authenticates routing headers, rewritting > doesn't matter because it is predictable). Ok granted, this can be done, but intermediate nodes should at least check for the existance of AH. => I can't see the benefit because intermediate nodes won't be able to verify the AH (authenticated source routing is known to be unfeasible with IPsec, just check IPsec mailing list archives). > => host2 should drop the packet on the floor. No. AFAICS, RFC 2460 8.4 applies only to the end-node, here host3, replying to the packet: => 8.4 is for the final destination. Your issue is with an intermediate destination which is a host. If it doesn't forward packets there is no problem, isn't it? > Does disabling routing header break anything significant? > > => YES, IT DOES! Please elaborate. => any device which needs to set the path followed by a packet: - mobile IPv6 routing optimization (a case of source route without forwarding) - some multihoming solutions - policy routing etc. Something related to Mobile IPv6? They should be using AH anyway. => no, mobile IPv6 doesn't mandate AH for every packets! Most ngtrans methods can be used for some kind of DoS attacks; with some, you can even disguise yourself pretty well. These are being worked. => this is more serious issue than source routing, and the fix is not easy. I haven't taken a look at home address option too deeply, but wasn't it just that Mobile IPv6 was put to freeze due to improper security considerations? => no, for improper solution to security considerations (even I personally believe more work is needed for the home address option). Regards Francis.Dupont@enst-bretagne.fr PS: is my proposed fix for the future host requirement document enough for you? (for other implementors) is it acceptable? is it already what you do (or would like to do)? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 1 12:05:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81J5w40014063 for ; Sat, 1 Sep 2001 12:05:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81J5wZi014062 for ipng-dist; Sat, 1 Sep 2001 12:05:58 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81J5s40014055 for ; Sat, 1 Sep 2001 12:05:54 -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 MAA11783 for ; Sat, 1 Sep 2001 12:06:05 -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 NAA10436 for ; Sat, 1 Sep 2001 13:06:00 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f81J5uZ21710; Sat, 1 Sep 2001 22:05:56 +0300 Date: Sat, 1 Sep 2001 22:05:56 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Subject: Re: Routing Header Considered Harmful In-Reply-To: <200109011819.f81IJwl99735@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, 1 Sep 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > => this is not true, hosts are not supposed to forward source routed > > packets to other nodes. Many implementations have a flag which enforces > > this behavior by default because disabling source route breaks things > > and enabling forwarding breaks security). > > Please read RFC2460 4.4. Nowhere does it say that hosts should not > forward source-routed packets. > > => 4.4 just describes how to process a source route header, it doesn't > specify if/why a node should process it. This is implementation dependent > and of course a clever implementer won't blindly forward source routed > packets. Of course the host requirement document should fix that > (as RFC 1122 section 3.3.5). A statement like mine is likely to be in it... > (note that RFC 1122 is applied to IPv6 too for many details, this doesn't > really replace a real spec but it helps (:-), in your case RFC 1122 should > be enough, not a surprise...) All too true. Why would anyone want to comply with the standards anyway? ;-) > > => this is not true (and AH authenticates routing headers, rewritting > > doesn't matter because it is predictable). > > Ok granted, this can be done, but intermediate nodes should at least check > for the existance of AH. > > => I can't see the benefit because intermediate nodes won't be able to > verify the AH (authenticated source routing is known to be unfeasible > with IPsec, just check IPsec mailing list archives). It cannot be verified, but at least it would ensure the sender is serious about getting the source-routed packet through. This would avert implementations that don't require AH to be used for source-routed packets, not too bright crackers, etc. But now I agree that this would probably just add unnecessary, imperfect overhead (at least with the current AH usage guidelines). > > => host2 should drop the packet on the floor. > > No. AFAICS, RFC 2460 8.4 applies only to the end-node, here host3, > replying to the packet: > > => 8.4 is for the final destination. Your issue is with an intermediate > destination which is a host. If it doesn't forward packets there is no > problem, isn't it? Most, and worst problems are avoided, see below. > > Does disabling routing header break anything significant? > > > > => YES, IT DOES! > > Please elaborate. > > => any device which needs to set the path followed by a packet: > - mobile IPv6 routing optimization (a case of source route without > forwarding) > - some multihoming solutions > - policy routing > etc. One could argue whether IPv6 header is the right place for routing decisions, rather than the routing system itself. At least when there aren't secure guidelines on which routers can safely be used as "beacons". Routing header won't scale to real policy routing, I think (nice way to test and debugging of course). All in all, most of these seem to be scenarios where you know beforehand which routers (or at least, which group of routers) you're going to use as source-routing hops, right? So negotiating beforehand that source-routing will be accepted would be acceptable? > Most ngtrans methods can be used for some kind of DoS attacks; with some, > you can even disguise yourself pretty well. These are being worked. > > => this is more serious issue than source routing, and the fix is > not easy. DoS is always possible. It's boring, nasty or really nasty. Really nasty issues with ngtrans methods are being plugged, I hope, but some nasties will remain. In the end, they're only DoS attacks, though. In most cases they cannot be used to map your internal network, go around firewalls, bounce exploit traffic off real routers. Both are important, but source-routing without any controls (esp. if hosts can forward) is a disaster waiting to happen. > I haven't taken a look at home address option too deeply, but wasn't it > just that Mobile IPv6 was put to freeze due to improper security > considerations? > > => no, for improper solution to security considerations (even I personally > believe more work is needed for the home address option). Sigh.. I really hoped I wouldn't need to muck with Mobile IPv6, but perhaps I'll have to look at it... :-/ > PS: is my proposed fix for the future host requirement document enough > for you? (for other implementors) is it acceptable? is it already what > you do (or would like to do)? Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure that's what all would like to do. Is it enough in the long term? Probably not. As a short term, perhaps yes. Issue with the fix is that you can still do nasties, even though _way_ less (as router addresses don't usually have many services which have to be enabled in site ingress packet filters): host1 --- rtr1 --- rtr2 --- rtr3 -- \ Big internal topology \ \-- rtr4 -- Here, you could bounce off with e.g. ICMP echo requests, ICMP PMTU, or whatever from every site's internal router (even ending to those with e.g. site-local addresses), and map the network by ICMP unreachables you get back. In the long term, I think, this should be all of the below: 0) Rewriting the header based on routing header SHOULD be configurable (MAY be per-interface). 1) if the behaviour is configurable, on hosts it MUST default to disallow. 2) if the behaviour is configurable, on routers it SHOULD default to disallow. 3) if the behaviour is not configurable, on all nodes it MUST default to disallow. SHOULD in 2), at least, is debatable. ( 3) would make about all the existing implementations non-compliant, big deal :-) -- 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 Sat Sep 1 12:24:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81JOT40014085 for ; Sat, 1 Sep 2001 12:24:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f81JOSKh014084 for ipng-dist; Sat, 1 Sep 2001 12:24: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f81JON40014077 for ; Sat, 1 Sep 2001 12:24:23 -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 MAA29951 for ; Sat, 1 Sep 2001 12:24:30 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23081 for ; Sat, 1 Sep 2001 13:24:59 -0600 (MDT) 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 f81JONp03039; Sat, 1 Sep 2001 12:24: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 ABB03785; Sat, 1 Sep 2001 12:24:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA23248; Sat, 1 Sep 2001 12:24:11 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15249.13787.420304.172388@thomasm-u1.cisco.com> Date: Sat, 1 Sep 2001 12:24:11 -0700 (PDT) To: Francis Dupont Cc: Michael Thomas , Alex Conta , alh-ietf@tndh.net, Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> References: <15245.8982.469052.649969@thomasm-u1.cisco.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> 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 Just as a point of clarification, I'm not categorically against reclassification (though I'll admit to being wary). What I don't like is the idea that ESP protection of transport headers and some diffserv scenarios desire to have them in the clear are mutually exclusive. Placing some of those headers into the flow label in a way that can be analyzed is still subverting the intent of keeping the transport headers private and effectively the same as transport friendly ESP (though, IMO, inferior). I believe that the way things are being formulated here is mutually exclusive. The reason is that the host who ESP-encapsulates the datagram has no clue without signaling whether it should go the transport friendly route or the private route. What that probably means in practice is that privacy will lose, and that would suck. Like Francis, I think there is something fundamentally broken here. I suspect that it is the base assumption that middle boxen must always have access to the transport headers. This is a fundamental shift in the IP architecture, though I'll admit that it's pretty much as common as dirt with firewall filtering, NAT's, etc. If we really want to go here, we should just embrace that principle and fix the offending protocols. I don't think I agree with such an architectural change, but these half-baked attempts at having it both ways are the worst of both worlds. Mike Francis Dupont writes: > Alex, perhaps I was unfair about the c) option. > I understood that you'd like to replace the MF classifier on > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > the 5F classifier by a simpler MF classifier with the flow label > in place of protocol and ports. This cancels the efficiency issue > of the extension header chain of IPv6. > > My first concern is the 5F reclassification is a bad idea because > an ACL-like classifier will never give what I want as an user. > This is too rigid, not real-time, ... > > The second concern is with ESP: the 5F classifier wants to look at > bits I want to hide. No conciliation is possible, IPsec people > (like Michael) will *never* accept to reveal transport layer or > payload details for a 5F classifier. > > This point raises a real question about the c) option: what will > be the content of a flow label with a diffserv semantic? There are > two kinds of proposals: > - to pack some bits from protocol/ports into the flow label > (A.1 or A.2 appendix of your I-D). This will make mapping > of a 5F classifier to a flow label based one easy but > the two previous concerns apply. I vote no for this > interpretation of c). > - to use an opaque value (a PHB ID as in 7.1.1 of your I-D > is an obvious candidate) but this doesn't work if a ISP > doesn't trust you: > - there is no easy map from a 5F classifier > - or the PHB is standard and doesn't provide more information > than the DSCP, or it is not and only some ISPs can interpret it. > This kind of flow label is an extension of the DS field, it doesn't > match the requirements for the (broken) MF reclassification and > is too short for advanced features (for instance a ISP should not > rewrite it because it is hard to restore it). > > I don't vote for or against the second interpretation of c) because > something is clearly broken somewhere. Tony claims that Diffserv is > broken and I believe he is right: at least the MF classifier stuff > has to be more understable... This is a ISP requirement, can ISP people > explain what they need? > > 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 Sep 2 08:01:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82F1Y40014750 for ; Sun, 2 Sep 2001 08:01:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f82F1Ynv014749 for ipng-dist; Sun, 2 Sep 2001 08:01: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82F1U40014742 for ; Sun, 2 Sep 2001 08:01:30 -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 IAA08037 for ; Sun, 2 Sep 2001 08:01:41 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20854 for ; Sun, 2 Sep 2001 08:01:40 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f82F1Nt23770; Sun, 2 Sep 2001 17:01: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 RAA09365; Sun, 2 Sep 2001 17:01: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 f82F1Nl02082; Sun, 2 Sep 2001 17:01:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109021501.f82F1Nl02082@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Sat, 01 Sep 2001 22:05:56 +0300. Date: Sun, 02 Sep 2001 17:01:23 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > > Does disabling routing header break anything significant? > > > > => YES, IT DOES! > > Please elaborate. > > => any device which needs to set the path followed by a packet: > - mobile IPv6 routing optimization (a case of source route without > forwarding) > - some multihoming solutions > - policy routing > etc. One could argue whether IPv6 header is the right place for routing decisions, rather than the routing system itself. At least when there aren't secure guidelines on which routers can safely be used as "beacons". => source routing is more efficient and has less security problem than free tunnelling. I am afraid that to replace source routing by tunnels won't improve the security... Routing header won't scale to real policy routing, I think (nice way to test and debugging of course). => I disagree (about the scaling problem, no about the fact source routing is very nice for testing and/or debugging). All in all, most of these seem to be scenarios where you know beforehand which routers (or at least, which group of routers) you're going to use as source-routing hops, right? So negotiating beforehand that source-routing will be accepted would be acceptable? => yes but don't forget that immediate addresses can be subnet-router anycasts (RFC 2373 2.6.1) so the "or at least, which group of routers" can be the common case. Note: source routing with subnet-router anycasts is the best way to implement the requirement that an user should be able to choose transit ISPs. I've read this requirement is a legal one in USA (a rule from the telephony world). Both are important, but source-routing without any controls (esp. if hosts can forward) is a disaster waiting to happen. => you already know my opinion about forwarding by hosts... IMHO the real cause of disasters is the confusion between ACLs with two addresses and a real firewall, but this is a general security issue, source routing is just a piece of it. > PS: is my proposed fix for the future host requirement document enough > for you? (for other implementors) is it acceptable? is it already what > you do (or would like to do)? Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure that's what all would like to do. => please send bug reports! Is it enough in the long term? Probably not. => the long term solution is to use an up-to-date firewall with IPv6 support (unfortunately the only commercial firewall with IPv6 support I know, which has support for source-routing and home address option too, is not yet available... grrr!) Issue with the fix is that you can still do nasties, even though _way_ less (as router addresses don't usually have many services which have to be enabled in site ingress packet filters): => source routing doesn't fool ingress filtering (but home address option does). I can't see your issue. host1 --- rtr1 --- rtr2 --- rtr3 -- \ Big internal topology \ \-- rtr4 -- Here, you could bounce off with e.g. ICMP echo requests, ICMP PMTU, or whatever from every site's internal router (even ending to those with e.g. site-local addresses), => packets with scoped source addresses should not go outside their zone. and map the network by ICMP unreachables you get back. => this is a firewall problem. And I believe you agree that filter out ICMPs because they are a potential security problem is not what to do? In the long term, I think, this should be all of the below: 0) Rewriting the header based on routing header SHOULD be configurable (MAY be per-interface). => RFC 1122 3.3.5 and RFC 1812 5.3.13.4 1) if the behaviour is configurable, on hosts it MUST default to disallow. => this is too strong, what you want is disabling forwarding (my proposal) or disabling non-local forwarding (RFC 1122) 2) if the behaviour is configurable, on routers it SHOULD default to disallow. => read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow (with DISCUSSION and EDITORS+COMMENTS) 3) if the behaviour is not configurable, on all nodes it MUST default to disallow. => the current status is MAY for configurable, MUST be disallowed by default for hosts and MUST be allowed by default for routers. SHOULD in 2), at least, is debatable. => no because the rule I want is MUST NOT (:-). ( 3) would make about all the existing implementations non-compliant, big deal :-) => my implementation has the flag you want (currently it is a not-process intermediate source routes and its default is process them but I can change it for what I'd like (i.e. my proposal :-) in some seconds)... 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 Sep 2 08:50:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82FoL40014794 for ; Sun, 2 Sep 2001 08:50:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f82FoLiH014793 for ipng-dist; Sun, 2 Sep 2001 08:50: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82FoH40014786 for ; Sun, 2 Sep 2001 08:50: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 IAA10019 for ; Sun, 2 Sep 2001 08:50:28 -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 IAA01811 for ; Sun, 2 Sep 2001 08:50:27 -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 AAA08088; Mon, 3 Sep 2001 00:50:26 +0900 (JST) Date: Mon, 03 Sep 2001 00:25:25 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Cc: Subject: Re: Preferred and Valid Lifetimes In-Reply-To: <000601c129f4$a8891640$4906140a@future.futsoft.com> References: <000601c129f4$a8891640$4906140a@future.futsoft.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: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 21 Aug 2001 09:22:10 +0530, >>>>> "Sivaramakrishnan A" said: > When the ValidLifeTime and PreferredLifeTime are specified in two ways > given, there exists a conflict on when to set the > lifetime as fixed /decrementing. What is the condition under which the > LifeTime is set to be fixed and under which situation > is it to be set decrementing? In my understanding, spec does not say anything about the "conflict". Our implementation allows a router to configure two lifetimes separately; for example, valid lifetime can be decreased in real time, while preferred lifetime can be a static value, as long as the latter does not larger than the former. > Is there any way to configure them by SNMP > Manager. > If yes, what is the standard MIB to be used? (I couldn't find any relevant > object in standard MIB specified under RFC 2465!) I'm not sure about MIBs, but "Router Renumbering for IPv6" defined in RFC2894 might be used for this purpose. 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 Sep 2 16:01:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82N1e40015048 for ; Sun, 2 Sep 2001 16:01:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f82N1e1V015047 for ipng-dist; Sun, 2 Sep 2001 16:01:40 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f82N1a40015040 for ; Sun, 2 Sep 2001 16:01: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 QAA04829 for ; Sun, 2 Sep 2001 16:01:47 -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 QAA25787 for ; Sun, 2 Sep 2001 16:01:46 -0700 (PDT) Received: from CLASSIC.viagenie.qc.ca (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f82N1YQ35384; Sun, 2 Sep 2001 19:01:35 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010901184555.02100c98@127.0.0.1> X-Sender: blanchet@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 01 Sep 2001 18:49:36 -0400 To: Pekka Savola , From: Marc Blanchet Subject: Re: Routing Header Considered Harmful In-Reply-To: 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/À 17:15 2001-09-01 +0300, Pekka Savola you wrote/vous écriviez: >Does disabling routing header break anything significant? used by mobileIP for route optimization (important feature for mobileIPv6). draft-ietf-mobileip-ipv6-14.txt: 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. For example, assuming use of a Type 0 Routing header [6], if > If it does, the >security of that must be analyzed as well. 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 Mon Sep 3 00:52:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f837qP40015372 for ; Mon, 3 Sep 2001 00:52:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f837qPAP015371 for ipng-dist; Mon, 3 Sep 2001 00:52:25 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f837qL40015364 for ; Mon, 3 Sep 2001 00:52: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 AAA14669 for ; Mon, 3 Sep 2001 00:52:25 -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 BAA15422 for ; Mon, 3 Sep 2001 01:52:55 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f837q9P04426; Mon, 3 Sep 2001 10:52:09 +0300 Date: Mon, 3 Sep 2001 10:52:09 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Subject: Re: Routing Header Considered Harmful In-Reply-To: <200109021501.f82F1Nl02082@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, 2 Sep 2001, Francis Dupont wrote: > In your previous mail you wrote: > One could argue whether IPv6 header is the right place for routing > decisions, rather than the routing system itself. At least when there > aren't secure guidelines on which routers can safely be used as "beacons". > > => source routing is more efficient and has less security problem than > free tunnelling. I am afraid that to replace source routing by tunnels > won't improve the security... I don't think we should compare source routing to free tunneling. Free tunneling is not enabled by default; it has to be administratively enabled. In IPv6-only networks, free tunneling is not used really. > Routing header won't scale to real policy routing, I think (nice way to > test and debugging of course). > > => I disagree (about the scaling problem, no about the fact source routing > is very nice for testing and/or debugging). I've yet to see an implementation where you could set a system-level flag "packets matching these criteria should have routing header, going through hops1,...,N, added to the packets". As it is now, the application has to set routing header. That is not scalable. > Note: source routing with subnet-router anycasts is the best way to > implement the requirement that an user should be able to choose transit ISPs. > I've read this requirement is a legal one in USA (a rule from > the telephony world). As an aside, I'd like to know if this is really the case. If this was true, it should implicitly indicate that there is some direct billing system (perhaps per-packet, per-byte) in the transit system. I'm not sure if that's what we want.. Moreover I don't see why user should be able to select transit systems unless he's being billed directly by the transit. The user should be able to choose his ISP, and via that, the transits, though. > > PS: is my proposed fix for the future host requirement document enough > > for you? (for other implementors) is it acceptable? is it already what > > you do (or would like to do)? > > Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure > that's what all would like to do. > > => please send bug reports! You want to make them non-compliant with RFC2460? The change makes sense though. > Is it enough in the long term? Probably not. > > => the long term solution is to use an up-to-date firewall with IPv6 support > (unfortunately the only commercial firewall with IPv6 support I know, > which has support for source-routing and home address option too, > is not yet available... grrr!) I'm not sure if it's the packet filter's (ie: it may not need to be a "firewall" as such at all -- e.g. your LAN router) job to know of all the possible wackiness in all the possible extension headers. If this was assumed, I think the behaviour in firewalls would be a toggle to drop all incoming packets with routing header. A simple and elegent approach, but perhaps not one one would like. > Issue with the fix is that you can still do nasties, even though _way_ > less (as router addresses don't usually have many services which have to > be enabled in site ingress packet filters): > > => source routing doesn't fool ingress filtering (but home address > option does). I can't see your issue. (sorry if I used 'ingress filtering' improperly; I meant incoming access list, not necessarily only source-address checks) Sure it does: host1 sends a packet with 'src=host1, dst=rtr3, rthdr=hostX' to site-internal router, with final destination some box inside the foreign site. Now the site's firewall checks that rtr3 is allowed to receive the packet, for any reason (e.g. ICMP echo). Packet goes to site internal router rtr3, where it's bounced off to some site internal box, _to which, if the packet had gone directly_, wouldn't have been allowed in the firewall. A breach. > host1 --- rtr1 --- rtr2 --- rtr3 -- > \ Big internal topology > \ > \-- rtr4 -- > > > Here, you could bounce off with e.g. ICMP echo requests, ICMP PMTU, or > whatever from every site's internal router (even ending to those with e.g. > site-local addresses), > > => packets with scoped source addresses should not go outside their zone. Good point, but the rest stands. > and map the network by ICMP unreachables you get back. > > => this is a firewall problem. And I believe you agree that filter out > ICMPs because they are a potential security problem is not what to do? Sure, we don't want to filter out at least all of them. IMO some (e.g. echo request) is acceptable under some circumstances. But this goes beyond ICMP too; basically it's at least at much as you have to allow access to in your routers from the outside. For the security-conscious, this might only be ICMP. > In the long term, I think, this should be all of the below: > > 0) Rewriting the header based on routing header SHOULD be configurable > (MAY be per-interface). > > => RFC 1122 3.3.5 and RFC 1812 5.3.13.4 I don't think these apply to IPv6.. unless you want them to. :-) > 1) if the behaviour is configurable, on hosts it MUST default to > disallow. > > => this is too strong, what you want is disabling forwarding (my proposal) or > disabling non-local forwarding (RFC 1122) non-local forwarding changes nothing; hosts could still be used as reflectors. > 2) if the behaviour is configurable, on routers it SHOULD default to > disallow. > > => read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow > (with DISCUSSION and EDITORS+COMMENTS) We can improve the security by default from IPv4... Not many are using source-routing with IPv4 anyway, as most network admins disable it. > 3) if the behaviour is not configurable, on all nodes it MUST default to > disallow. > > => the current status is MAY for configurable, MUST be disallowed by default > for hosts and MUST be allowed by default for routers. I don't see how IPv4 Host/Router requirements set status for IPv6, so _by the spec_ the status is more like 'MAY for configurable, MUST be allowed by default on all nodes'. > SHOULD in 2), at least, is debatable. > > => no because the rule I want is MUST NOT (:-). You mean MUST NOT be disabled by default? -- 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 Sep 3 02:13:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f839DR40015541 for ; Mon, 3 Sep 2001 02:13:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f839DRFW015540 for ipng-dist; Mon, 3 Sep 2001 02: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f839DN40015533 for ; Mon, 3 Sep 2001 02:13:23 -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 CAA13528 for ; Mon, 3 Sep 2001 02:13:36 -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 CAA20667 for ; Mon, 3 Sep 2001 02:13:35 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA13872; Mon, 3 Sep 2001 11:13:32 +0200 (MET DST) Date: Mon, 3 Sep 2001 11:13:32 +0200 From: Ignatios Souvatzis To: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" Cc: "'ipng@sunroof.eng.sun.com'" Subject: Re: Layer II for IPv6 vs. IPv4 networks Message-ID: <20010903111332.A13840@theory.cs.uni-bonn.de> Reply-To: ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from swamy_mandavilli@hp.com on Wed, Aug 22, 2001 at 08:12:54AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 22, 2001 at 08:12:54AM -0700, MANDAVILLI,SWAMY J (HP-FtCollins,= ex1) wrote: > Hi! >=20 > Are there any differences between IPv6 networks > and IPv4 networks with respect to Layer II > (i.e., vlans etc.)? not really (other than the protocol type value in the Layer II header). -is --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO5NJuDCn4om+4LhpAQECcggAuExlDgjZo2yymK/9Kv0DgCFu6+sLmlL9 7JZqnbv501oQJw8JHnjpk6iuOcIJrodngnVsR0/6vCu8B2OonucoiCczAcTBatYY ob4uWFxFKwg07CyIkb8tPCv8xqvCBR//7Pp4mOX3ogiTPjsiwcXRbmPWKaWga2E8 gE8u216FeA/dOahhrmZw/IruksnyGi27qAYesNetx9Y6QP33JvbI1tj65aHgLJFL BfCk6r0eumbJZlDkmgfrrZc9v164u53XrlZ/Da3rezyf1SNNBl6XAfZR4Gbbuw3z NeHjRTv6lkdjC6RFpYyR72f24TLZO1+YVZ/Hp1wRQtDiOAfowEca5g== =7tDw -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 03:02:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83A2a40015666 for ; Mon, 3 Sep 2001 03:02:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83A2Z1B015665 for ipng-dist; Mon, 3 Sep 2001 03:02:35 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83A2V40015655 for ; Mon, 3 Sep 2001 03:02:31 -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 DAA25773 for ; Mon, 3 Sep 2001 03:02:42 -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 DAA29364 for ; Mon, 3 Sep 2001 03:02:41 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA14386 for ipng@sunroof.eng.sun.com; Mon, 3 Sep 2001 12:02:35 +0200 (MET DST) Date: Mon, 3 Sep 2001 12:02:35 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful Message-ID: <20010903120235.B13840@theory.cs.uni-bonn.de> References: <200109011628.f81GSdl99377@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="MW5yreqqjyrRcusr" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pekkas@netcore.fi on Sat, Sep 01, 2001 at 07:53:26PM +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --MW5yreqqjyrRcusr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 01, 2001 at 07:53:26PM +0300, Pekka Savola wrote: > On Sat, 1 Sep 2001, Francis Dupont wrote: > > In your previous mail you wrote: > > > > RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers) > > forward source routed packets. > > > > =3D> this is not true, hosts are not supposed to forward source routed > > packets to other nodes. Many implementations have a flag which enforces > > this behavior by default because disabling source route breaks things > > and enabling forwarding breaks security). >=20 > Please read RFC2460 4.4. Nowhere does it say that hosts should not > forward source-routed packets. E.g.: >=20 > If, after processing a Routing header of a received packet, an > intermediate node determines that the packet is to be forwarded onto > a link whose link MTU is less than the size of the packet, the node > must discard the packet and send an ICMP Packet Too Big message to > the packet's Source Address. > [...] >=20 > note 'node' not 'router'; also forward 'forward'. note "intermediate". Mere hosts are by definition never intermediate. -is --MW5yreqqjyrRcusr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO5NVODCn4om+4LhpAQF1wAf/es+Fp4igtKosv3habs/WFwJ02zqj20CE aqdv5oZeTdbOlFsvLRgMA9hVsbKAVLuRql12Shp6M7ZZgXcca5WloIrWWNa/ivLa R3u2KIhwIcrqt7NJkvVLogfm9CGd/oXzHhC/gRthrJM4TASHByx+BEPNge/9988j xKnjLZqi33KiYhTj3uxH/O0L2DW+R02REUJ13M9iyImGU3YZ9YfuxDqoueZoIq24 RIHl8ozksyaQQRC0lxojyGxHld8GLcN5YFF3m29FiduON+r3ZaHO037fSHtcuyEB RNn4fMLJrTdKGtGquLUNt3QUjGbfhLuMZ80rdUF7yjONmwuUnXd7TQ== =ouhl -----END PGP SIGNATURE----- --MW5yreqqjyrRcusr-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 03:14:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83AEQ40015691 for ; Mon, 3 Sep 2001 03:14:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83AEQRR015690 for ipng-dist; Mon, 3 Sep 2001 03:14: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83AEM40015683 for ; Mon, 3 Sep 2001 03:14:22 -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 DAA14589 for ; Mon, 3 Sep 2001 03:14:32 -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 EAA07030 for ; Mon, 3 Sep 2001 04:15:02 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 6EBF74B20; Mon, 3 Sep 2001 19:14:26 +0900 (JST) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com In-reply-to: pekkas's message of Sat, 01 Sep 2001 17:15:19 +0300. 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: Routing Header Considered Harmful From: itojun@iijlab.net Date: Mon, 03 Sep 2001 19:14:26 +0900 Message-ID: <10970.999512066@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >When discussing Linux IPv6 implementation, David Stevens > brought up a problem with routing header w/ >Hosts. > >RFC2460 (The IPv6 Spec) assumes that all _nodes_ (note not routers) >forward source routed packets. > >Routing header works so that the next hop is always written to destination >address field and the rest of the path to routing header fields. I briefly remember that: - I (or jinmei) asked this question to Steve Deering and - he responded that it is intentionally specified as "node". I don't remember the reasons. Steve, are you there? 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 Sep 3 04:06:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83B6440015775 for ; Mon, 3 Sep 2001 04:06:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83B64q8015774 for ipng-dist; Mon, 3 Sep 2001 04:06:04 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83B6140015767 for ; Mon, 3 Sep 2001 04:06:01 -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 EAA02033 for ; Mon, 3 Sep 2001 04:06:12 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12081 for ; Mon, 3 Sep 2001 04:06:10 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f83BAAG20334 for ; Mon, 3 Sep 2001 14:10:10 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Sep 2001 14:06:04 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWCLTB>; Mon, 3 Sep 2001 14:06:04 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719800A@esebe004.NOE.Nokia.com> To: seamus@bit-net.com, brian@hursley.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Another idea for the flow label Date: Mon, 3 Sep 2001 14:05:57 +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 Jim, Could you help my memory on Steve's counter arguments? From the meeting minutes I just read that you "agree with Steve's position". Also, according to the minutes, while the division in two was similar, there is a difference in the intended semantics between your proposal and Brian's ("Router owns it" vs. "Non-unique value"). Anyway, I kept thinking about this over the weekend. I think we just need to agree on what a "flow" is, or what it could be. In intserv we have "micro-flows" (being specified by the 5-tuple). In 2460 App.A we have an "app-to-app" flow, which is agnostic to the transport header stuff, but needs to be given the same forwarding treatment (including routing). (Since the first is a subset of the second, we only need the "app-to-app" flow, as the micro-flow can be achieved by a host convention of mapping 1:1 between a 5-tuple and a flow label.) I think we could have a new kind of flow, a "well-known flow". The prime example of this kind of the flow is the one with flow label '00000'. For these the source only requests the same forwarding treatment, but naturally excluding routing if destination addresses are different. The state for these flows could be either SLA based or signaled. For administrative reasons the flow label name space should be split in two, as Brian proposed, but with the MSBs reversed: MSB='1' for 2460 App.A flow (but without the PRN requirement), MSB='0' for the "well-known flows". As discussed, the "well-known flow label" should be immutable as well as the "app-to-app" flow label. (We do not need another DSCP field.) The "well-known flow label" would be an end-to-end construct, and would be meaningful only in a context of a (transitive) business relationship to either the source or the destination. This means that an ISP would only look at the flow label, if a customer tells it to. The SLA (or signaling or whatever) binding together a (range of) source address(es), a (range of) destination address(es), and a specific "well known flow label", would also tell what to do with the packets of the flow. The property of being "well-known" would help otherwise unrelated end points to agree on what values to use (without signaling), and enable off-line configuration of those diffserv reclassifiers on domain entry. What Brian has proposed is that a portion of the "well-known flows" name space to be allocated to PHB-IDs. Others could have other ideas for well-known flow labels (like Christian's "traffic type"). Inevitably the specification of the well-known flow label hints at the intended semantics, but it should be clear that the semantics is meaningful only if a "paying" customer can be identified (directly or indirectly), and even then the customer tells what to do with the packet (E.g. Could map an AF-PHB-ID flow label to EF DSCP value). In some business arrangements between an end user and an ISP, usage of specific "well-known" flow labels could result in a better service and incur additional charges. Therefore the use of the "well-known" flow labels must be separated from the usage of the well-known ports of the transport layer. Also, it may be that the user wants to pay extra for the delivery of some packets over e.g. HTTP, but NOT for others. As for the HW implementations, it seems that wildcard source address for matching a packet with a "well-known flow label" doesn't make too much sense (*). So, the implication would be that your lookup needs to be agnostic of the flow label format altogether, just treat it as 20 bits of random (but not PRN) data. The data you find should tell what to do with the packet. The SLAs and intserv signaling is used to populate that data. (* In the beginning of the path, you need to know who is sending the packet (to decide whether to do what the flow label asks for). At the end of the path, the customer doesn't want to pay extra for some random hacker sending packets with a "well-known flow label". So, in both cases, the source address needs to be "in range".) >From the IPv6 WG perspective the only difference between the two forms is the missing 'routing' aspect of the forwarding treatment based on the well-known flow label (same label can be used in packets to multiple destinations. The state establishment for the actual use of the flow labels is outside of the IPv6 WG scope (IMO). So, once defined as a concept, the definition of the actual "well-known flow-label" values should not be a critical issue for the IPv6 WG. Naturally any large scale benefits of the concept depend on widely agreed upon definitions, but even single "big customers" could have specific values as part of their SLAs with their ISPs. Jarno > -----Original Message----- > From: ext Jim Bound [mailto:seamus@bit-net.com] > Sent: 31. elokuuta 2001 19:20 > To: Brian E Carpenter > Cc: ipng > Subject: Re: Another idea for the flow label > > > Brian et al, > > A lot of mail but lots of it are repeating. The only way my change in > vote for "c" will work is if we do this below per Brian. But > I presented > this case in front of the IETF WG at Minneapolis and folks > did not want to > go there and Steve presented good counter arguments to doing > it. It is a > compromise to do the below. > > A few statements: > > Immutable field: I agree with Tony 100% if we have a per microflow it > should be immutable for that option and I mean in the strongest sense > that it is read-only. I will not post my reasons again but > they are in > line with Tony and also that I am not comfortable saying > nodes along the > path will return the field to its former value. AT > ALL.......Causing bugs > with per microflows for apps that depend on it is something I > could never > support and to trust the edge and core with that without how its to be > done is a bit of a stretch for me and I think for any IETF > specifications > sound protocol effect on networks. Immutable field is the > quickest way to > standards track I would argue for per micro-flows. In the > future after > some practical experience that could be re-discussed. > > MF Classifiers: We should solve this problem so that all > classification is > done only at the header. The multiple tuple value for classification > beyond the header in Diffserv architecture was a huge mistake > to put in > the model and having boxes look at L4+ values is bordering > absurdity IMO. > > IETF Rants we need to support QOS other standards: This is > simply bogus > logic. As Bob said the place to change our rules is in > POISED not IPng. > If Diffserv made a mistake or neglected to deal with cases > like IPsec that > does not mean IPv6 WG MUST support fixes to make it work. That is the > bogus logic. It assumes a rule for us in IPv6 WG which DOES > NOT EXIST. > Arguing it may be the right thing to do is fair. I don't > agree though. > > Are we getting anywhere? After working on this for many > years I feel NO. > The bottom line is can the IPv6 WG agree to the attached compromise in > some form? That should be the first thing we have to agree > on or Thomas > is correct we need to just leave it alone for awhile till we can get > consensus. We don't have it now IMO. > > Should we use the flow for other than QOS? I think that is a > wise vision. > But then we need some kind of compromise for that too. > > /jim > > > On Tue, 28 Aug 2001, Brian E Carpenter wrote: > > > How would people feel about this encoding for the flow label > > (deemed to be immutable end to end)? > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| Per-microflow unique value | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| Non-unique value | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > I'm not yet 100% convinced that the second case is sufficient for > > diffserv, but at least it would be a more generic approach > > than reserving half the space for diffserv. > > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 08:09:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83F9o40016068 for ; Mon, 3 Sep 2001 08:09:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83F9oim016067 for ipng-dist; Mon, 3 Sep 2001 08:09: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83F9k40016060 for ; Mon, 3 Sep 2001 08:09:46 -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 IAA20123 for ; Mon, 3 Sep 2001 08:09:57 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13308 for ; Mon, 3 Sep 2001 08:09:56 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f83F9hR06118; Mon, 3 Sep 2001 17:09:43 +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 RAA07710; Mon, 3 Sep 2001 17:09:42 +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 f83F9fl06482; Mon, 3 Sep 2001 17:09:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109031509.f83F9fl06482@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Mon, 03 Sep 2001 10:52:09 +0300. Date: Mon, 03 Sep 2001 17:09:41 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Routing header won't scale to real policy routing, I think (nice way to > test and debugging of course). > > => I disagree (about the scaling problem, no about the fact source routing > is very nice for testing and/or debugging). I've yet to see an implementation where you could set a system-level flag "packets matching these criteria should have routing header, going through hops1,...,N, added to the packets". => try any correspondent node for mobile IPv6 (routing optimization is just doing that :-). As it is now, the application has to set routing header. That is not scalable. => I agree but this is easier to add in kernel than IPsec for instance. > Note: source routing with subnet-router anycasts is the best way to > implement the requirement that an user should be able to choose transit ISPs. > I've read this requirement is a legal one in USA (a rule from > the telephony world). As an aside, I'd like to know if this is really the case. => does someone in the list know the answer? If this was true, it should implicitly indicate that there is some direct billing system (perhaps per-packet, per-byte) in the transit system. I'm not sure if that's what we want.. => a billing system is not a necessary condition (but it is a sufficient one) Moreover I don't see why user should be able to select transit systems unless he's being billed directly by the transit. The user should be able to choose his ISP, and via that, the transits, though. => to have the choice of the transit ISP, not only the first one, is nice. I'd like to get this feature in the kernel controlled by a policy, today I have to hack my Cisco config to do the same thing, this is not scalable. > > PS: is my proposed fix for the future host requirement document enough > > for you? (for other implementors) is it acceptable? is it already what > > you do (or would like to do)? > > Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure > that's what all would like to do. > > => please send bug reports! You want to make them non-compliant with RFC2460? => to add a flag which controls the forwarding of source routed packets won't make them non-compliant, just a bit more secure. I am afraid you see requirements in RFC 2460 which are not in it. The change makes sense though. => we agree (:-). I'm not sure if it's the packet filter's (ie: it may not need to be a "firewall" as such at all -- e.g. your LAN router) job to know of all the possible wackiness in all the possible extension headers. => yes, it is the job of a real firewall. If this was assumed, I think the behaviour in firewalls would be a toggle to drop all incoming packets with routing header. A simple and elegent approach, but perhaps not one one would like. => too simple: Mobile IPv6 people won't be happy! > Issue with the fix is that you can still do nasties, even though _way_ > less (as router addresses don't usually have many services which have to > be enabled in site ingress packet filters): > > => source routing doesn't fool ingress filtering (but home address > option does). I can't see your issue. (sorry if I used 'ingress filtering' improperly; I meant incoming access list, not necessarily only source-address checks) => sorry, RFC 2827 gave a very accurate meaning for the "ingress filtering" term. Sure it does: => so your argument is that source routing fools simple incoming traffic filtering. I agree, this is why I used 'firewall' in place of 'packet filters'. > In the long term, I think, this should be all of the below: > > 0) Rewriting the header based on routing header SHOULD be configurable > (MAY be per-interface). > > => RFC 1122 3.3.5 and RFC 1812 5.3.13.4 I don't think these apply to IPv6.. unless you want them to. :-) => they apply until there are the equivalent for IPv6. > => read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow > (with DISCUSSION and EDITORS+COMMENTS) We can improve the security by default from IPv4... => old arguments about IPv4 are still valid for IPv6. I don't see how IPv4 Host/Router requirements set status for IPv6, => IPv6 is not so different. so _by the spec_ the status is more like 'MAY for configurable, MUST be allowed by default on all nodes'. => no, there are not such MAY/MUST in RFC 2460. > SHOULD in 2), at least, is debatable. > > => no because the rule I want is MUST NOT (:-). You mean MUST NOT be disabled by default? => yes. 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 Mon Sep 3 08:53:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83Fr640016131 for ; Mon, 3 Sep 2001 08:53:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83Fr6km016130 for ipng-dist; Mon, 3 Sep 2001 08:53: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83Fr240016123 for ; Mon, 3 Sep 2001 08:53:02 -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 IAA00881 for ; Mon, 3 Sep 2001 08:53:14 -0700 (PDT) Received: from camelia.wanadoo.fr (smtp-rt-10.wanadoo.fr [193.252.19.59]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20373 for ; Mon, 3 Sep 2001 09:53:05 -0600 (MDT) Received: from mahonia.wanadoo.fr (193.252.19.58) by camelia.wanadoo.fr; 3 Sep 2001 17:53:01 +0200 Received: from remi (80.9.120.190) by mahonia.wanadoo.fr; 3 Sep 2001 17:52:06 +0200 Message-ID: <004201c13491$1f15a8e0$be780950@remi> From: "Remi" To: Subject: IPv6 event Date: Mon, 3 Sep 2001 17:57:21 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003F_01C134A1.E1365D60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk C'est un message de format MIME en plusieurs parties. ------=_NextPart_000_003F_01C134A1.E1365D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The programme of the "Deploying IPv6 Networks" conference is now online = at: http://www.upperside.fr/ipv6/deployipv6intro.htm ------=_NextPart_000_003F_01C134A1.E1365D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
 
The programme of the "Deploying IPv6 Networks" = conference is=20 now online at:
http://www.uppe= rside.fr/ipv6/deployipv6intro.htm
------=_NextPart_000_003F_01C134A1.E1365D60-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 12:13:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83JDi40016244 for ; Mon, 3 Sep 2001 12:13:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83JDiX6016243 for ipng-dist; Mon, 3 Sep 2001 12:13:44 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83JDe40016236 for ; Mon, 3 Sep 2001 12:13:40 -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 MAA04832 for ; Mon, 3 Sep 2001 12:13:51 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06276 for ; Mon, 3 Sep 2001 13:14:23 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA18620; Mon, 3 Sep 2001 20:13:47 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA20320; Mon, 3 Sep 2001 20:13:43 +0100 Message-ID: <3B93D5EB.A30F33F5@hursley.ibm.com> Date: Mon, 03 Sep 2001 14:11:39 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Pekka Savola CC: Rajesh Ramankutty , ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-roesler-ipngwg-ipngls-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > On Fri, 31 Aug 2001, Rajesh Ramankutty wrote: > > > Hi, > > > > The idea of carrying MPLS labels in IPv6 packet destination options is > > already patented by us in 3Com. > > Thanks! > > Now we have two main reasons not to standardize this. :-) Well, actually the non-draft says "This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026." However, it is a truly dreadful idea for the same reason that I mentioned for draft-roesler. We have no business contaminating the IP layer with MPLS. 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 Mon Sep 3 13:39:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83KdF40016279 for ; Mon, 3 Sep 2001 13:39:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83KdEET016278 for ipng-dist; Mon, 3 Sep 2001 13:39:14 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83KdB40016271 for ; Mon, 3 Sep 2001 13:39:11 -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 NAA23571 for ; Mon, 3 Sep 2001 13:39:23 -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 OAA27794 for ; Mon, 3 Sep 2001 14:39:55 -0600 (MDT) Received: from CLASSIC.viagenie.qc.ca (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f83KdYQ44848 for ; Mon, 3 Sep 2001 16:39:34 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010903104513.030de150@127.0.0.1> X-Sender: blanchet@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Sep 2001 11:39:58 -0400 To: ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: embedding ipv4 addresses in ipv6 address text representation In-Reply-To: <009CA59D1752DD448E07F8EB2F91175719800A@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We do provide the ability to write IPv4 addresses in IPv6 addresses for ipv4-compatible and ipv4-mapped. It would be very useful and more normalized to be able to use IPv4 addresses in IPv6 addresses for the transition mechanisms that embed IPv4 addresses, ex: 6to4. Any objection? Marc, waiting for fire... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 3 13:39:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83Kdd40016289 for ; Mon, 3 Sep 2001 13:39:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f83KddBj016288 for ipng-dist; Mon, 3 Sep 2001 13:39:39 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f83KdZ40016281 for ; Mon, 3 Sep 2001 13:39:35 -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 NAA14836 for ; Mon, 3 Sep 2001 13:39:47 -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 OAA08341 for ; Mon, 3 Sep 2001 14:39:42 -0600 (MDT) Received: from CLASSIC.viagenie.qc.ca (retro.viagenie.qc.ca [206.123.31.22]) by jazz.viagenie.qc.ca (Viagenie/8.11.0) with ESMTP id f83KdZQ44857; Mon, 3 Sep 2001 16:39:35 -0400 (EDT) X-Accept-Language: fr,en,es Message-Id: <5.1.0.14.1.20010903131727.02c83ed0@127.0.0.1> X-Sender: blanchet@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 03 Sep 2001 13:27:24 -0400 To: haberman@nortelnetworks.com, dthaler@microsoft.com From: Marc Blanchet Subject: draft-ietf-ipngwg-uni-based-mcast-02.txt comments Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, reading the draft-ietf-ipngwg-uni-based-mcast-02.txt, it would be very useful to have one or two address examples to help the reader make sure he understood right. Also think that the prefix length field should be more explained (i.e. the length is encoded in binary: i.e. /48 would have a plen value of 0x30). Also think that it should be clearly stated that all non significant bits in the prefix should be 0. Suggestion: A small example with a site network prefix (3ffe:ffff:1::/48), including a site-local scope and random group id would be useful. I made one in non-compressed format for myself (with a head-based random generator...;-)) to make sure I understood the draft: ff35:0030:3ffe:ffff:0001:0000:6f3b:1148. Tell me if I understood well! Regards, 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 Tue Sep 4 04:19:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84BJK40017207 for ; Tue, 4 Sep 2001 04:19:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84BJKd6017206 for ipng-dist; Tue, 4 Sep 2001 04:19:20 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84BJ740017183; Tue, 4 Sep 2001 04:19:07 -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 EAA27241; Tue, 4 Sep 2001 04:19:18 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23525; Tue, 4 Sep 2001 04:19:16 -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 HAA08268; Tue, 4 Sep 2001 07:17:50 -0400 (EDT) Message-Id: <200109041117.HAA08268@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-engelstad-ngtrans-mobility-requirements-00.txt Date: Tue, 04 Sep 2001 07:17:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Requirements to mobility while transitioning from IPv4 to IPv6 Author(s) : P. Engelstad Filename : draft-engelstad-ngtrans-mobility-requirements-00.txt Pages : 7 Date : 14-Aug-01 This document explores how layer-3 mobility can be provided to mobile nodes that are subjects to and affected by the transition mechanisms specified by the NGTRANS Working Group. It points out that the combination of mobility and transition mechanisms might lead to problems that will require a solution, and suggests requirements that a solution should meet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-mobility-requirements-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-engelstad-ngtrans-mobility-requirements-00.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-engelstad-ngtrans-mobility-requirements-00.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: <20010904071727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-mobility-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-mobility-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904071727.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 Tue Sep 4 04:19:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84BJv40017233 for ; Tue, 4 Sep 2001 04:19:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84BJvcn017232 for ipng-dist; Tue, 4 Sep 2001 04:19: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84BJb40017209; Tue, 4 Sep 2001 04:19:37 -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 EAA18544; Tue, 4 Sep 2001 04:19:48 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16751; Tue, 4 Sep 2001 05:20:20 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08298; Tue, 4 Sep 2001 07:18:21 -0400 (EDT) Message-Id: <200109041118.HAA08298@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-engelstad-ngtrans-6to4-v4v6-mobility-00.txt Date: Tue, 04 Sep 2001 07:18:21 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv4 over 6to4 and 6to4 mobility Author(s) : P. Engelstad Filename : draft-engelstad-ngtrans-6to4-v4v6-mobility-00.txt Pages : 9 Date : 14-Aug-01 This draft outlines how a 6to4-enabled host can be provided with transparent IPv4 and IPv6 connectivity and mobility no matter if the host is located in a 6to4 network or is roaming an IPv4-only network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-engelstad-ngtrans-6to4-v4v6-mobility-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-engelstad-ngtrans-6to4-v4v6-mobility-00.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-engelstad-ngtrans-6to4-v4v6-mobility-00.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: <20010904070810.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-engelstad-ngtrans-6to4-v4v6-mobility-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-engelstad-ngtrans-6to4-v4v6-mobility-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904070810.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 Tue Sep 4 10:12:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84HCU40017801 for ; Tue, 4 Sep 2001 10:12:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84HCTjo017800 for ipng-dist; Tue, 4 Sep 2001 10:12: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84HCQ40017793 for ; Tue, 4 Sep 2001 10:12: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 KAA01186 for ; Tue, 4 Sep 2001 10:12:38 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03177 for ; Tue, 4 Sep 2001 10:12:37 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id NAA03666; Tue, 4 Sep 2001 13:13:42 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id NAA00875; Tue, 4 Sep 2001 13:13:42 -0400 Message-ID: <3B950BC1.14199109@txc.com> Date: Tue, 04 Sep 2001 13:13:38 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng@sunroof.eng.sun.com Subject: Re: Higher level question about flow label References: <200108312047.f7VKlXl94332@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC947996801B238E545465AA9" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msC947996801B238E545465AA9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis, Your idea has value. Unfortunately, it poses the same type of problem for IPv6 fast processing as the 5-tuple classification, which makes it a non-acceptable alternative to the flow label (field in the main header). Regards, Alex Francis Dupont wrote: > > In your previous mail you wrote: > > Unfortunately I think the extension header mechanism is probably > too heavy as Francis says, but I want to think a bit longer about > that (and re-read kre's last message and some of Jarno's messages). > > => this is heavy but we can do more with this than with 20 bits, > in fact we can do more with this than with protocol/ports (*)... > The basic idea is to make (still unknown) avantages greater than > (already known) drawbacks. > > Regards > > Francis.Dupont@enst-bretagne.fr > > (*) I have two different kinds of ideas about this: > - first I don't fully understand what ISPs will do with protocol/ports > because SLAs are not signaling: rules will be very coarse like > "remark TCP port 80 to lower than best effort"... Perhaps protocol/ports > are not designed for classification (:-). Of course, to pack them into > 20 bits (or less!) won't make these field more useful! > - if we use available bits with a better semantics both we need less > (even less than 20 bits because we deal with macro flows in Diffserv > but look at the last point) and we can do more with them, for instance > code a stack of DSCPs (a good solution for the rewrite/restore issue). > - a destination option (in a header just after the IPv6 header or > the hop-by-hop/please-use-the-slow-path header) provides a lot of bits > and is expandable, in fact it can (i.e. should) be expandable on the > fly: a stack of annotations for classification? MTU is not a real issue > because backbones have already larger MTUs than edge networks for > other reasons, the last edge router just needs to cleanup the stack. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------msC947996801B238E545465AA9 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDQxNzEzMzlaMCMGCSqGSIb3DQEJBDEWBBTemq4GB1y3I9S3EM8/ K9z81Vl63zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gHlKIgP63XoP0P7MEgcaE0JXEiLnTOjgbCtTYrxIntnWVQAg14yPGxso4Q/3N25hQpsRBT36 ecYNaTglSxguIaYGdPd4cmhGEMdDtwSsLxP+wnrDz1qZqVA1LalNxH4HWWQiuqRiSEpUxjGN otPmlVfwtN++nhtBmaktiT5PaAAW --------------msC947996801B238E545465AA9-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 11:12:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84ICD40018013 for ; Tue, 4 Sep 2001 11:12:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84ICCjE018012 for ipng-dist; Tue, 4 Sep 2001 11:12: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84IC940018005 for ; Tue, 4 Sep 2001 11:12:09 -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 LAA18476 for ; Tue, 4 Sep 2001 11:12:20 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20029 for ; Tue, 4 Sep 2001 12:12:38 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA33902; Tue, 4 Sep 2001 19:12:01 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA25098; Tue, 4 Sep 2001 19:12:03 +0100 Message-ID: <3B951701.B5887B48@hursley.ibm.com> Date: Tue, 04 Sep 2001 13:01:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Marc Blanchet CC: ipng@sunroof.eng.sun.com Subject: Re: embedding ipv4 addresses in ipv6 address text representation References: <5.1.0.14.1.20010903104513.030de150@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Marc Blanchet wrote: > > We do provide the ability to write IPv4 addresses in IPv6 addresses for > ipv4-compatible and > ipv4-mapped. It would be very useful and more normalized to be able to use > IPv4 addresses in IPv6 > addresses for the transition mechanisms that embed IPv4 addresses, ex: 6to4. > > Any objection? For a 6to4 prefix, I think it would be very confusing to use dotted decimal, since we would see a full address starting in hex, continuing in decimal, and reverting to hex at the end. In other words, 6to4 addresses derived from 9.254.253.252 should be written 2002:09fe:fdfc:... My $0.02 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 Sep 4 11:23:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84INX40018093 for ; Tue, 4 Sep 2001 11:23:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84INXxj018092 for ipng-dist; Tue, 4 Sep 2001 11:23: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84INU40018085 for ; Tue, 4 Sep 2001 11:23: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 LAA27061 for ; Tue, 4 Sep 2001 11:23:40 -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 LAA07449 for ; Tue, 4 Sep 2001 11:23:39 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f84INWG16276; Tue, 4 Sep 2001 21:23:32 +0300 Date: Tue, 4 Sep 2001 21:23:31 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Marc Blanchet , Subject: Re: embedding ipv4 addresses in ipv6 address text representation In-Reply-To: <3B951701.B5887B48@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 4 Sep 2001, Brian E Carpenter wrote: > Marc Blanchet wrote: > > > > We do provide the ability to write IPv4 addresses in IPv6 addresses for > > ipv4-compatible and > > ipv4-mapped. It would be very useful and more normalized to be able to use > > IPv4 addresses in IPv6 > > addresses for the transition mechanisms that embed IPv4 addresses, ex: 6to4. > > > > Any objection? > > For a 6to4 prefix, I think it would be very confusing to use > dotted decimal, since we would see a full address starting > in hex, continuing in decimal, and reverting to hex at the end. > In other words, 6to4 addresses derived from 9.254.253.252 > should be written 2002:09fe:fdfc:... More of an issue of parsing, I think.. Whether it can be done reliably. I usually can't calculate dec -> hex translation of arbitrary IPv4 address in my head :-), and from user's point of view, being able to do like: ping6 2002:113.114.115.117::1 would help some, especially if we try to get away from using compatible addresses; if so, this would be almost a requirement. I don't see source for big confusion as long as you assume that dotted quad always replaces 32 bits of the address e.g. with zero-filling (same if you now e.g. 'ping 10.10'). -- 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 Sep 4 12:07:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84J7v40018217 for ; Tue, 4 Sep 2001 12:07:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84J7vrn018216 for ipng-dist; Tue, 4 Sep 2001 12:07: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84J7r40018209 for ; Tue, 4 Sep 2001 12:07: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 MAA28295 for ; Tue, 4 Sep 2001 12:08:04 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA19622 for ; Tue, 4 Sep 2001 13:08:36 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 Sep 2001 12:07:57 -0700 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, 4 Sep 2001 12:07:57 -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); Tue, 4 Sep 2001 12:07: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); Tue, 4 Sep 2001 12:07:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: embedding ipv4 addresses in ipv6 address text representation Date: Tue, 4 Sep 2001 12:07:28 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E660@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: embedding ipv4 addresses in ipv6 address text representation Thread-Index: AcE1bZWnL8nbVcZbQG2K5n2KawO0wAAByRQg From: "Dave Thaler" To: "Brian E Carpenter" , "Marc Blanchet" Cc: X-OriginalArrivalTime: 04 Sep 2001 19:07:29.0284 (UTC) FILETIME=[D79B4440:01C13574] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f84J7s40018210 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Brian. For ISATAP, dotted-decimal is fine, since it appears at the end just like for v4-compat and v4-mapped. For 6to4, it's too problematic to change it, so I agree it should stay hex. -Dave > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Tuesday, September 04, 2001 11:02 AM > To: Marc Blanchet > Cc: ipng@sunroof.eng.sun.com > Subject: Re: embedding ipv4 addresses in ipv6 address text representation > > Marc Blanchet wrote: > > > > We do provide the ability to write IPv4 addresses in IPv6 addresses for > > ipv4-compatible and > > ipv4-mapped. It would be very useful and more normalized to be able to > use > > IPv4 addresses in IPv6 > > addresses for the transition mechanisms that embed IPv4 addresses, ex: > 6to4. > > > > Any objection? > > For a 6to4 prefix, I think it would be very confusing to use > dotted decimal, since we would see a full address starting > in hex, continuing in decimal, and reverting to hex at the end. > In other words, 6to4 addresses derived from 9.254.253.252 > should be written 2002:09fe:fdfc:... > > My $0.02 > > 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 Tue Sep 4 12:23:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84JNx40018292 for ; Tue, 4 Sep 2001 12:23:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84JNxpR018291 for ipng-dist; Tue, 4 Sep 2001 12:23:59 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84JNt40018284 for ; Tue, 4 Sep 2001 12:23: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 MAA02609 for ; Tue, 4 Sep 2001 12:24:03 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09034 for ; Tue, 4 Sep 2001 12:24:02 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id PAA06182; Tue, 4 Sep 2001 15:25:07 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA07004; Tue, 4 Sep 2001 15:25:06 -0400 Message-ID: <3B952A8E.CD60FCAC@txc.com> Date: Tue, 04 Sep 2001 15:25:02 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas CC: Francis Dupont , alh-ietf@tndh.net, Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: <15245.8982.469052.649969@thomasm-u1.cisco.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <15249.13787.420304.172388@thomasm-u1.cisco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msBACEA9BBF90DC474E0E01E42" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msBACEA9BBF90DC474E0E01E42 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Just as a point of clarification, > [...] Placing some of > those headers into the flow label in a way that > can be analyzed is still subverting the intent > of keeping the transport headers private and > effectively the same as transport friendly ESP > (though, IMO, inferior). > [...] > transport friendly route or the private route. > What that probably means in practice is that > privacy will lose, and that would suck. > [...] > > Mike If we do not loose sight of the fact that, with IP QoS, the network (Internet) infrastructure, that delivers the packets to destination, handles not only forwarding information, but als QoS information, then we would accept that the QoS information is in the same class, relative to privacy, with forwarding information. In light of that, criteria to use tunnel or transport ESP apply based on user needs. Alex --------------msBACEA9BBF90DC474E0E01E42 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDQxOTI1MDRaMCMGCSqGSIb3DQEJBDEWBBSQLwg1NLZ+rxYIuWjn luLhZ5KQ2zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gCFQ3lfJ98AyWI/SHu++hVmM3RH/Rz61V0RWoqJN+nzsHCgFKIN5GuBqIwANf1/L6iTh88LE nbfFhJ3zDJds6hD9n1xFl+ZVROo2o4L8sEshJHuKa8Rc551Y7XYIOybtibhVqP+jtHXK8vuj pBZ4/6WK7v3JvYeYK2+GGFX2vVih --------------msBACEA9BBF90DC474E0E01E42-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 13:09:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84K9k40018447 for ; Tue, 4 Sep 2001 13:09:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84K9kmD018446 for ipng-dist; Tue, 4 Sep 2001 13:09:46 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84K9h40018439 for ; Tue, 4 Sep 2001 13:09:43 -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 NAA29067 for ; Tue, 4 Sep 2001 13:09:51 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29209 for ; Tue, 4 Sep 2001 13:09:51 -0700 (PDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA23705 for ; Tue, 4 Sep 2001 13:09:50 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA06524 for ; Tue, 4 Sep 2001 13:09:50 -0700 (MST)] Received: from email.mot.com (d50-38b0.cig.mot.com [160.47.56.176]) by il27exb01.cig.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id SCC2K66J; Tue, 4 Sep 2001 15:09:50 -0500 Message-ID: <3B953521.44C9BDB9@email.mot.com> Date: Tue, 04 Sep 2001 15:10:09 -0500 From: Kevin Wang Reply-To: kwang1@email.mot.com Organization: Motorola, Inc X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Question about IPv6 Anycast address Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, According to ADDR ARCH, the anycast address has two restrictions: *Anycast address MUST NOT be used as source address; *Anycast address MUST NOT be assigned to an IPv6 host. - this seems conflicts with the anycast definition. Anycast address is an identifier for a set of interfaces(typically belonging to different nodes). My understanding of 'node', according to IPv6 SPEC, includes hosts and routers. Any pointer for me to better understand this would be appreciative. Kevin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 13:20:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KKm40018485 for ; Tue, 4 Sep 2001 13:20:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84KKlx0018484 for ipng-dist; Tue, 4 Sep 2001 13:20: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KKi40018477 for ; Tue, 4 Sep 2001 13:20:44 -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 NAA01758 for ; Tue, 4 Sep 2001 13:20:50 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10362 for ; Tue, 4 Sep 2001 13:20:49 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA32048; Tue, 4 Sep 2001 21:20:19 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA52718; Tue, 4 Sep 2001 21:20:19 +0100 Message-ID: <3B9533A8.14822E1C@hursley.ibm.com> Date: Tue, 04 Sep 2001 15:03:52 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: aconta@txc.com Subject: A good point References: <133.e41129.28c0251d@aol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex made a very valid point the other day: > It would look like a > silly, technical weakness, to have a field as read-only, > but with no mechanism for the final recipient to detect whether > it was changed or not. In other words, even if we declare that the flow label MUST NOT be changed en route, since it is not authenticated by IPSEC there is no way to tell if somebody does in fact change it. So it is not a safe e2e field, even if we define it as an e2e field. 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 Sep 4 13:25:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KP240018502 for ; Tue, 4 Sep 2001 13:25:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84KP1f5018501 for ipng-dist; Tue, 4 Sep 2001 13: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KOw40018494 for ; Tue, 4 Sep 2001 13:24:58 -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 NAA28227 for ; Tue, 4 Sep 2001 13:25:09 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15505 for ; Tue, 4 Sep 2001 14:25:04 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA26310; Tue, 4 Sep 2001 21:25:05 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA46112; Tue, 4 Sep 2001 21:25:04 +0100 Message-ID: <3B9534BC.2B45FF52@hursley.ibm.com> Date: Tue, 04 Sep 2001 15:08:28 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: Robert Elz , ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) References: <200109011743.f81HhRl99596@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > > In your previous mail you wrote: > > | It's the former; if an ISP chooses to disbelieve the upstream ISP, > | and re-classify the traffic, the semantics of the transport > | header are exactly the information of interest. > > No they're not. There is nothing at all in any transport header of > relevance that contains anything in any way related to QoS. > > => I agree, the whole stuff about MF re-classification on > the 5/6 tuple seems silly to me. People do much worse things already, by looking even deeper into the packet. In practice, I agree that port numbers aren't too much use, and probably very often only the addresses will be used. The whole idea Alex and I had was to give IPv6 an advantage by using the flow label to support more effective MF classification. 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 Sep 4 13:33:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KXJ40018522 for ; Tue, 4 Sep 2001 13:33:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84KXJ0E018521 for ipng-dist; Tue, 4 Sep 2001 13:33: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KXF40018514 for ; Tue, 4 Sep 2001 13:33: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 NAA00468 for ; Tue, 4 Sep 2001 13:33:22 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16507 for ; Tue, 4 Sep 2001 13:33:21 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA07870; Tue, 4 Sep 2001 16:34:27 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA10518; Tue, 4 Sep 2001 16:34:27 -0400 Message-ID: <3B953AC9.D2113B27@txc.com> Date: Tue, 04 Sep 2001 16:34:17 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng Subject: Re: a), b), c), d), or e) References: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms22EFC0350C68D1B69BE95D5D" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms22EFC0350C68D1B69BE95D5D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > Alex, perhaps I was unfair about the c) option. You were Francis. > I understood that you'd like to replace the MF classifier on > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > the 5F classifier by a simpler MF classifier with the flow label > in place of protocol and ports. This cancels the efficiency issue > of the extension header chain of IPv6. > > My first concern is the 5F reclassification is a bad idea because > an ACL-like classifier will never give what I want as an user. > This is too rigid, not real-time, ... > It may not give you what you want as a user, but it would give me what "I" (read my customers) want as user(s). Remember, having a Intserv, and Diffserv use of the flow label gives the user the option, and that is a good thing. > The second concern is with ESP: the 5F classifier wants to look at > bits I want to hide. No conciliation is possible, IPsec people > (like Michael) will *never* accept to reveal transport layer or > payload details for a 5F classifier. [...] > > Francis Let's put religion aside. Conceptually, with IP QoS, infrastructure devices delivering packets to destination, are processing forwarding and QoS information. As traffic between two end-nodes may have distinct QoS requirements, it is obvious that the information to be given to an infrastructure device must provide the differentiation of the traffic between the two end-nodes. That information, by definition, is in some relationship with the multiplexing of the communication between the two end-nodes, which is being realized through the transport (host-to-host) header information. At an extreme, that information is the transport protocol and source and destination ports, themselves. Since, with IP QoS, the QoS information is in the same class, relative to privacy, with the forwarding information, if one needs to apply full privacy to QoS information, it will apply the same criteria as for forwarding information: use tunnel ESP. Regards, Alex --------------ms22EFC0350C68D1B69BE95D5D Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDQyMDM0MjRaMCMGCSqGSIb3DQEJBDEWBBQvbfnSezKRl8iID3oD 18NEAMqDjjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gI2P5PfQHaT8yEF9tpZYLPl/HtPVE9UBTFVeGT39UOAVgwiI7Brf8js8z9ptxq2g0sZORuW2 GNDgMKu61l+Oz1ViZhIOQYcXaojXd7QOIhD2eTmw9/wwYUmfusX5FDsEoqyZlnaSbQgpR2MS JzAbGZaQ9uk3IS2IED+kO3/pI+QM --------------ms22EFC0350C68D1B69BE95D5D-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 13:33:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KXo40018532 for ; Tue, 4 Sep 2001 13:33:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84KXoFb018531 for ipng-dist; Tue, 4 Sep 2001 13:33: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KXj40018524 for ; Tue, 4 Sep 2001 13:33:45 -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 NAA23271 for ; Tue, 4 Sep 2001 13:33:57 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22785 for ; Tue, 4 Sep 2001 14:33:51 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA33862; Tue, 4 Sep 2001 21:33:53 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA25308; Tue, 4 Sep 2001 21:33:52 +0100 Message-ID: <3B9536B2.68A521ED@hursley.ibm.com> Date: Tue, 04 Sep 2001 15:16:50 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: seamus@bit-net.com, ipng@sunroof.eng.sun.com Subject: Re: Another idea for the flow label References: <009CA59D1752DD448E07F8EB2F91175719800A@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jarno, Exactly. Treating the (IANA-registered) PHB ID values as part of a "well-known flow label" space is a good idea. We would need to agree on the flow-label semantics being a) end to end b) not authenticated (hence cannot prove the end-to-end property) c) split into "well-known" and "locally assigned" halves c) is a change from RFC 2460. Brian jarno.rajahalme@nokia.com wrote: > > Jim, > > Could you help my memory on Steve's counter arguments? From the meeting > minutes I just read that you "agree with Steve's position". Also, according > to the minutes, while the division in two was similar, there is a difference > in the intended semantics between your proposal and Brian's ("Router owns > it" vs. "Non-unique value"). > > Anyway, I kept thinking about this over the weekend. I think we just need to > agree on what a "flow" is, or what it could be. In intserv we have > "micro-flows" (being specified by the 5-tuple). In 2460 App.A we have an > "app-to-app" flow, which is agnostic to the transport header stuff, but > needs to be given the same forwarding treatment (including routing). > > (Since the first is a subset of the second, we only need the "app-to-app" > flow, as the micro-flow can be achieved by a host convention of mapping 1:1 > between a 5-tuple and a flow label.) > > I think we could have a new kind of flow, a "well-known flow". The prime > example of this kind of the flow is the one with flow label '00000'. For > these the source only requests the same forwarding treatment, but naturally > excluding routing if destination addresses are different. The state for > these flows could be either SLA based or signaled. > > For administrative reasons the flow label name space should be split in two, > as Brian proposed, but with the MSBs reversed: MSB='1' for 2460 App.A flow > (but without the PRN requirement), MSB='0' for the "well-known flows". > > As discussed, the "well-known flow label" should be immutable as well as the > "app-to-app" flow label. (We do not need another DSCP field.) > > The "well-known flow label" would be an end-to-end construct, and would be > meaningful only in a context of a (transitive) business relationship to > either the source or the destination. This means that an ISP would only look > at the flow label, if a customer tells it to. The SLA (or signaling or > whatever) binding together a (range of) source address(es), a (range of) > destination address(es), and a specific "well known flow label", would also > tell what to do with the packets of the flow. > > The property of being "well-known" would help otherwise unrelated end points > to agree on what values to use (without signaling), and enable off-line > configuration of those diffserv reclassifiers on domain entry. > > What Brian has proposed is that a portion of the "well-known flows" name > space to be allocated to PHB-IDs. Others could have other ideas for > well-known flow labels (like Christian's "traffic type"). Inevitably the > specification of the well-known flow label hints at the intended semantics, > but it should be clear that the semantics is meaningful only if a "paying" > customer can be identified (directly or indirectly), and even then the > customer tells what to do with the packet (E.g. Could map an AF-PHB-ID flow > label to EF DSCP value). > > In some business arrangements between an end user and an ISP, usage of > specific "well-known" flow labels could result in a better service and incur > additional charges. Therefore the use of the "well-known" flow labels must > be separated from the usage of the well-known ports of the transport layer. > Also, it may be that the user wants to pay extra for the delivery of some > packets over e.g. HTTP, but NOT for others. > > As for the HW implementations, it seems that wildcard source address for > matching a packet with a "well-known flow label" doesn't make too much sense > (*). So, the implication would be that your lookup needs to be agnostic of > the flow label format altogether, just treat it as 20 bits of random (but > not PRN) data. The data you find should tell what to do with the packet. The > SLAs and intserv signaling is used to populate that data. > > (* In the beginning of the path, you need to know who is sending the packet > (to decide whether to do what the flow label asks for). At the end of the > path, the customer doesn't want to pay extra for some random hacker sending > packets with a "well-known flow label". So, in both cases, the source > address needs to be "in range".) > > >From the IPv6 WG perspective the only difference between the two forms is > the missing 'routing' aspect of the forwarding treatment based on the > well-known flow label (same label can be used in packets to multiple > destinations. The state establishment for the actual use of the flow labels > is outside of the IPv6 WG scope (IMO). > > So, once defined as a concept, the definition of the actual "well-known > flow-label" values should not be a critical issue for the IPv6 WG. Naturally > any large scale benefits of the concept depend on widely agreed upon > definitions, but even single "big customers" could have specific values as > part of their SLAs with their ISPs. > > Jarno > > > -----Original Message----- > > From: ext Jim Bound [mailto:seamus@bit-net.com] > > Sent: 31. elokuuta 2001 19:20 > > To: Brian E Carpenter > > Cc: ipng > > Subject: Re: Another idea for the flow label > > > > > > Brian et al, > > > > A lot of mail but lots of it are repeating. The only way my change in > > vote for "c" will work is if we do this below per Brian. But > > I presented > > this case in front of the IETF WG at Minneapolis and folks > > did not want to > > go there and Steve presented good counter arguments to doing > > it. It is a > > compromise to do the below. > > > > A few statements: > > > > Immutable field: I agree with Tony 100% if we have a per microflow it > > should be immutable for that option and I mean in the strongest sense > > that it is read-only. I will not post my reasons again but > > they are in > > line with Tony and also that I am not comfortable saying > > nodes along the > > path will return the field to its former value. AT > > ALL.......Causing bugs > > with per microflows for apps that depend on it is something I > > could never > > support and to trust the edge and core with that without how its to be > > done is a bit of a stretch for me and I think for any IETF > > specifications > > sound protocol effect on networks. Immutable field is the > > quickest way to > > standards track I would argue for per micro-flows. In the > > future after > > some practical experience that could be re-discussed. > > > > MF Classifiers: We should solve this problem so that all > > classification is > > done only at the header. The multiple tuple value for classification > > beyond the header in Diffserv architecture was a huge mistake > > to put in > > the model and having boxes look at L4+ values is bordering > > absurdity IMO. > > > > IETF Rants we need to support QOS other standards: This is > > simply bogus > > logic. As Bob said the place to change our rules is in > > POISED not IPng. > > If Diffserv made a mistake or neglected to deal with cases > > like IPsec that > > does not mean IPv6 WG MUST support fixes to make it work. That is the > > bogus logic. It assumes a rule for us in IPv6 WG which DOES > > NOT EXIST. > > Arguing it may be the right thing to do is fair. I don't > > agree though. > > > > Are we getting anywhere? After working on this for many > > years I feel NO. > > The bottom line is can the IPv6 WG agree to the attached compromise in > > some form? That should be the first thing we have to agree > > on or Thomas > > is correct we need to just leave it alone for awhile till we can get > > consensus. We don't have it now IMO. > > > > Should we use the flow for other than QOS? I think that is a > > wise vision. > > But then we need some kind of compromise for that too. > > > > /jim > > > > > > On Tue, 28 Aug 2001, Brian E Carpenter wrote: > > > > > How would people feel about this encoding for the flow label > > > (deemed to be immutable end to end)? > > > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |0| Per-microflow unique value | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > 0 1 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |1| Non-unique value | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > I'm not yet 100% convinced that the second case is sufficient for > > > diffserv, but at least it would be a more generic approach > > > than reserving half the space for diffserv. > > > > > > 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 > > -------------------------------------------------------------------- > > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 13:39:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84Kdb40018558 for ; Tue, 4 Sep 2001 13:39:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84Kdb8L018557 for ipng-dist; Tue, 4 Sep 2001 13:39: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84KdX40018550 for ; Tue, 4 Sep 2001 13:39:33 -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 NAA25670 for ; Tue, 4 Sep 2001 13:39:45 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20371 for ; Tue, 4 Sep 2001 13:39:43 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA16944; Tue, 4 Sep 2001 21:39:39 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA36776; Tue, 4 Sep 2001 21:39:39 +0100 Message-ID: <3B953802.CAE32063@hursley.ibm.com> Date: Tue, 04 Sep 2001 15:22:26 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: Francis Dupont , Alex Conta , alh-ietf@tndh.net, ipng Subject: Re: a), b), c), d), or e) References: <15245.8982.469052.649969@thomasm-u1.cisco.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <15249.13787.420304.172388@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is no proposal to reveal port/protocol numbers in the flow label field, for the simple reason that it's impossible; there is no reversible hash of all those bits into 19. So the idea fails even without the security argument (which is a strong one too). As for whether people believe in 5-tuple classification (for non-encrypted traffic), it surely isn't an issue for this WG. What Alex and I came here to discuss was doing better than that with IPv6. Brian Michael Thomas wrote: > > Just as a point of clarification, I'm not > categorically against reclassification (though > I'll admit to being wary). What I don't like is > the idea that ESP protection of transport headers > and some diffserv scenarios desire to have them in > the clear are mutually exclusive. Placing some of > those headers into the flow label in a way that > can be analyzed is still subverting the intent > of keeping the transport headers private and > effectively the same as transport friendly ESP > (though, IMO, inferior). > > I believe that the way things are being formulated > here is mutually exclusive. The reason is that the > host who ESP-encapsulates the datagram has no clue > without signaling whether it should go the > transport friendly route or the private route. > What that probably means in practice is that > privacy will lose, and that would suck. > > Like Francis, I think there is something > fundamentally broken here. I suspect that it is > the base assumption that middle boxen must always > have access to the transport headers. This is a > fundamental shift in the IP architecture, though > I'll admit that it's pretty much as common as dirt > with firewall filtering, NAT's, etc. If we really > want to go here, we should just embrace that > principle and fix the offending protocols. I don't > think I agree with such an architectural change, > but these half-baked attempts at having it both > ways are the worst of both worlds. > > Mike > > Francis Dupont writes: > > Alex, perhaps I was unfair about the c) option. > > I understood that you'd like to replace the MF classifier on > > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > > the 5F classifier by a simpler MF classifier with the flow label > > in place of protocol and ports. This cancels the efficiency issue > > of the extension header chain of IPv6. > > > > My first concern is the 5F reclassification is a bad idea because > > an ACL-like classifier will never give what I want as an user. > > This is too rigid, not real-time, ... > > > > The second concern is with ESP: the 5F classifier wants to look at > > bits I want to hide. No conciliation is possible, IPsec people > > (like Michael) will *never* accept to reveal transport layer or > > payload details for a 5F classifier. > > > > This point raises a real question about the c) option: what will > > be the content of a flow label with a diffserv semantic? There are > > two kinds of proposals: > > - to pack some bits from protocol/ports into the flow label > > (A.1 or A.2 appendix of your I-D). This will make mapping > > of a 5F classifier to a flow label based one easy but > > the two previous concerns apply. I vote no for this > > interpretation of c). > > - to use an opaque value (a PHB ID as in 7.1.1 of your I-D > > is an obvious candidate) but this doesn't work if a ISP > > doesn't trust you: > > - there is no easy map from a 5F classifier > > - or the PHB is standard and doesn't provide more information > > than the DSCP, or it is not and only some ISPs can interpret it. > > This kind of flow label is an extension of the DS field, it doesn't > > match the requirements for the (broken) MF reclassification and > > is too short for advanced features (for instance a ISP should not > > rewrite it because it is hard to restore it). > > > > I don't vote for or against the second interpretation of c) because > > something is clearly broken somewhere. Tony claims that Diffserv is > > broken and I believe he is right: at least the MF classifier stuff > > has to be more understable... This is a ISP requirement, can ISP people > > explain what they need? > > > > 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 Sep 4 13:49:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84Kn140018577 for ; Tue, 4 Sep 2001 13:49:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84Kn0VF018576 for ipng-dist; Tue, 4 Sep 2001 13:49: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84Kmu40018569 for ; Tue, 4 Sep 2001 13:48: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 NAA12186 for ; Tue, 4 Sep 2001 13:49:08 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA10242 for ; Tue, 4 Sep 2001 14:49:40 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA26178; Tue, 4 Sep 2001 21:49:03 +0100 Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA52648; Tue, 4 Sep 2001 21:49:02 +0100 Message-ID: <3B953A15.80C805A@hursley.ibm.com> Date: Tue, 04 Sep 2001 15:31:17 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: mat@cisco.com, alh-ietf@tndh.net, kgk@igs.net, huitema@windows.microsoft.com, hinden@iprg.nokia.com, aconta@txc.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757198005@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jarno.rajahalme@nokia.com wrote: > > Mike, > > I believe you misunderstood what I meant. To rephrase: The currently defined > RFC 2460 App.A semantics allows the IPv6 flow label field to be used for > intserv MF-classification, instead of any of the transport headers. In this > case the multi-field (MF) classifier would look only at the IP addresses and > the flow label. Intserv does not need to care about any of the headers above > the IP header, if the flow label is used and signaled end-to-end. With the > current flow label definition there are no additional privacy implications > raised by the use of the flow label in intserv signaling and classification. Indeed. IntServ makes elegant use of the flow label. > Brian has repeatedly mentioned that intserv would have a problem with ESP. > With reference to RFC 2207 this is clearly not true (uses SPI instead of the > ports). Thanks. I was thinking of classical IntServ. Do people believe that 2207 is widely implemented? > Additionally, using the IPv6 Flow Label to label the flows for > intserv allows the intserv signaling implementation to be independent of the > IPsec policy in place (e.g. signaling would be the same regardless the IPsec > policy, don't need to refresh the intserv state when re-keying, etc.). Assuming the source doesn't decide to refresh the flow label at the same time as re-keying. But since it is soft state, this wouldn't matter too much. Brian > > Jarno > > Michael Thomas wrote: > > > > jarno.rajahalme@nokia.com writes: > > > Just some comments for clarifying some stuff that keeps coming up > > > repeatedly: > > > > > > Brian E Carpenter wrote: > > > > > > > > This is a very unfair comment. Diffserv is just fine in the > > > > case of unencrypted traffic. It has a problem (and so does > > > > intserv I suspect) with tunnel or transport mode ESP. > > > > > > > > > > IPv4 intserv shares the same difficulty of doing > > MF-classification with ESP. > > > However, in IPv6 the flow label can be used in > > MF-classification for intserv > > > semantics, even when ESP is used. > > > > This is incorrect. RFC 2207 defines a way to classify > > ESP traffic for intserv *and* it doesn't compromise > > privacy. What's being floated here for diffserv requires > > that I compromise privacy in order to work, which I > > think is bogus. > > > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 16:04:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84N4b40019053 for ; Tue, 4 Sep 2001 16:04:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f84N4brB019052 for ipng-dist; Tue, 4 Sep 2001 16:04:37 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f84N4X40019045 for ; Tue, 4 Sep 2001 16:04:33 -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 QAA21833 for ; Tue, 4 Sep 2001 16:04:45 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16933 for ; Tue, 4 Sep 2001 16:04:44 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id TAA10750; Tue, 4 Sep 2001 19:05:49 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA16863; Tue, 4 Sep 2001 19:05:48 -0400 Message-ID: <3B955E48.998619AC@txc.com> Date: Tue, 04 Sep 2001 19:05:44 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jarno.rajahalme@nokia.com CC: mat@cisco.com, brian@hursley.ibm.com, ipng@sunroof.eng.sun.com Subject: Re: a), b), c), d), or e) References: <009CA59D1752DD448E07F8EB2F911757198005@esebe004.NOE.Nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDE785EB1D4376D808FF50D8E" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDE785EB1D4376D808FF50D8E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian was correct, in what he said, and what he meant to say. He compared apples with apples, and therefore referred to non-RFC 2207 Intserv (non-SPI based classifiers). Mike has a problem with the ESP transport header privacy implications of the Diffserv Flow label approach. But, RFC 2207, defines IPv4, and IPv6 Filter Specs containing the Generalized Port Identifier - GPI - and does not define anything for the IPv6 flow label. It rather refers to the IPv6 flow label only to say that "it can be useful, but it is left for a future definition". We - Brian, I, and others - said this before, in a different context, and will say it again: the privacy implications of the Diffserv flow label are not different than those of the Intserv flow label approach -- please see Footnote 1. Furthermore, it seems that the data plane RFC 2207 based classifier cannot differentiate same protocol ID traffic between two end-nodes -- please see Footnote 2. That is relevant only to the point made by Mike earlier that RFC 2207 solves all Intserv transport ESP related problems. Regards, Alex Footnote 1. ------------ The Intserv filter specification based on a flow label, is an alternative to the filter specification based on source port. So, the flow label can be seen as a replacement or alternative of the source port, in the filter specification. Or, the Intserv flow label has a relationship, for the duration of a flow state, with the port information. That relationship is not different than the relastionship between a Diffserv flow label value, and the source port. Therefore, a Intserv use of flow label, versus a Diffserv use of flow label, vis-a-vis compromising privacy of transport mode ESP, is similar. Footnote 2. ----------- According to RFC 2207, a Intserv RFC 2207 based RSVP session is identified by the 3-tuple: DstAddr, Protocol ID, vDstPort (Session Spec) while a sender (Sender Template) is defined by the 2-tuple SrcAddr, GPI=SPI (Filter Spec)(Sender Template) Furthermore a RCF 2207 based classifier is using a 4-tuple: DstAddr, Protocol ID, SrcAddr, GPI (page 7) where the Protocol ID, and GPI=SPI are fetched from the AH, or ESP headers. The control plane - admission control - (in FF Style) seems to be using the Session spec, and Filter SPec, in making resource reservations. But the the data plane (traffic) classifier does not hold the 'vdstprt', and therefore it cannot make a differentiation between distinct flows with the same protocol ID between two end-nodes (same SPI, SRC, DST addresses). End Footnotes ------------ jarno.rajahalme@nokia.com wrote: > > Mike, > > I believe you misunderstood what I meant. To rephrase: The currently defined > RFC 2460 App.A semantics allows the IPv6 flow label field to be used for > intserv MF-classification, instead of any of the transport headers. In this > case the multi-field (MF) classifier would look only at the IP addresses and > the flow label. Intserv does not need to care about any of the headers above > the IP header, if the flow label is used and signaled end-to-end. With the > current flow label definition there are no additional privacy implications > raised by the use of the flow label in intserv signaling and classification. > > Brian has repeatedly mentioned that intserv would have a problem with ESP. > With reference to RFC 2207 this is clearly not true (uses SPI instead of the > ports). Additionally, using the IPv6 Flow Label to label the flows for > intserv allows the intserv signaling implementation to be independent of the > IPsec policy in place (e.g. signaling would be the same regardless the IPsec > policy, don't need to refresh the intserv state when re-keying, etc.). > > Jarno > > Michael Thomas wrote: > > > > jarno.rajahalme@nokia.com writes: > > > Just some comments for clarifying some stuff that keeps coming up > > > repeatedly: > > > > > > Brian E Carpenter wrote: > > > > > > > > This is a very unfair comment. Diffserv is just fine in the > > > > case of unencrypted traffic. It has a problem (and so does > > > > intserv I suspect) with tunnel or transport mode ESP. > > > > > > > > > > IPv4 intserv shares the same difficulty of doing > > MF-classification with ESP. > > > However, in IPv6 the flow label can be used in > > MF-classification for intserv > > > semantics, even when ESP is used. > > > > This is incorrect. RFC 2207 defines a way to classify > > ESP traffic for intserv *and* it doesn't compromise > > privacy. What's being floated here for diffserv requires > > that I compromise privacy in order to work, which I > > think is bogus. > > > > Mike > > --------------msDE785EB1D4376D808FF50D8E Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDQyMzA1NDZaMCMGCSqGSIb3DQEJBDEWBBTzotuEQXLEGGf/Wef+ 4Xur+3xXqzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gB3fmjBZJSeRaOdYWcqKksE6Q+5R0fMAxMjptznKruITo7tt/ONX8P2eBs+v4p/3VB3+zY3X rDBIl8sWHJapVHuQvJyhx0myTHEQowkU42q8z63fl1JJKh+6ZHnn5pGHEde9oqGbdggOpezY aE2CwHsDHd9JDVbz8sQ5KEpapB5A --------------msDE785EB1D4376D808FF50D8E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 4 17:52:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f850qc40019177 for ; Tue, 4 Sep 2001 17:52:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f850qc4m019175 for ipng-dist; Tue, 4 Sep 2001 17:52: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f850qX40019168 for ; Tue, 4 Sep 2001 17:52: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 RAA13119 for ; Tue, 4 Sep 2001 17:52:45 -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 RAA26882 for ; Tue, 4 Sep 2001 17:52:44 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 99B814B20; Wed, 5 Sep 2001 09:52:39 +0900 (JST) To: kwang1@email.mot.com Cc: ipng@sunroof.eng.sun.com In-reply-to: kwang1's message of Tue, 04 Sep 2001 15:10:09 EST. <3B953521.44C9BDB9@email.mot.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: Question about IPv6 Anycast address From: itojun@iijlab.net Date: Wed, 05 Sep 2001 09:52:39 +0900 Message-ID: <29189.999651159@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Hi All, >According to ADDR ARCH, the anycast address has two restrictions: >*Anycast address MUST NOT be used as source address; >*Anycast address MUST NOT be assigned to an IPv6 host. - this seems >conflicts with the anycast definition. I don't think they conflict. you may want to check draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt. 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 Sep 5 00:02:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f8572T40019540 for ; Wed, 5 Sep 2001 00:02:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f8572Tnf019539 for ipng-dist; Wed, 5 Sep 2001 00:02:29 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f8572P40019532 for ; Wed, 5 Sep 2001 00:02:25 -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 AAA24996 for ; Wed, 5 Sep 2001 00:02:37 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA12123 for ; Wed, 5 Sep 2001 01:03:10 -0600 (MDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f85731302079 for ; Wed, 5 Sep 2001 10:03:02 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 5 Sep 2001 10:02:29 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSW1F9V>; Wed, 5 Sep 2001 10:02:29 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719800D@esebe004.NOE.Nokia.com> To: jschnizl@cisco.com Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, ipng@sunroof.eng.sun.com Subject: IPv6 flow label support in the QoSFilterRule in Diameter (RE: [AA A-WG]: Issue 87: Move filter-rule AVP to base) Date: Wed, 5 Sep 2001 10:02:24 +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 John, I'll come back with this when IPv6 WG consensus exists. I think we're pretty close now. Is there a hard deadline for any new issues for Diameter? Jarno jschnizl@cisco.com wrote: > > Yes, it would be inappropriate. The meaning of flow labels was clearly > not defined in Minneapolis (IETF 50). The draft minutes from London > http://playground.sun.com/pub/ipng/html/minutes/ipng-minutes-a > ug2001.txt > indicated some controversy remains, with a call for > "Further discussion on mailing list." > > John > > At 09:04 AM 9/4/2001, jarno.rajahalme@nokia.com wrote: > >Pat, > > > >Would it be inappropriate at this time to ask the QoSFilterRule to be > >extended to include an optional IPv6 flow label value (20 bits) to be > >matched by the filter? > > > > Jarno > > > >> -----Original Message----- > >> From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > >>... > >> QoSFilterRule > >> The QosFilterRule format is derived from the > OctetString AVP > >> Base Format. It uses the UTF-8 encoding and has the same > >> requirements as the UTF8String. Packets may be marked or > >> metered based on the following information that > is associated > >> with it: > >> > >> Direction (in or out) > >> Source and destination IP address (possibly masked) > >> Protocol > >> Source and destination port (lists or ranges) > >> DSCP values (no mask or range) > >> > >> Rules for the appropriate direction are evaluated > in order, > >> with the first matched rule terminating the > evaluation. Each > >> packet is evaluated once. If no rule matches, the > packet is > >> treated as best effort. > >> > >> QoSFilterRule filters MUST follow the format: > >> > >> action dir proto from src to dst [options] > >> > >> tag - Mark packet with a specific > >> DSCP [49]. > >> The DSCP option MUST be included. > >> meter - Meter traffic. The > metering options > >> MUST be included. > >> > >> dir "in" is from the terminal, "out" is to the > >> terminal. > >> > >> proto An IP protocol specified by > number. The "ip" > >> keyword means any protocol will match. > >> > >> src and dst
[ports] > >> > >> The
may be specified as: > >> ipno An IPv4 or IPv6 number > in dotted- > >> quad or canonical IPv6 > form. Only > >> this exact IP number > will match > >> the rule. > >> ipno/bits An IP number as above > with a mask > >> width of the form > 1.2.3.4/24. In > >> this case all IP numbers from > >> 1.2.3.0 to 1.2.3.255 > will match. > >> The bit width MUST be > valid for the > >> IP version and the IP > number MUST > >> NOT have bits set > beyond the mask. > >> > >> The sense of the match can be inverted by > >> preceding an address with the not > modifier, > >> causing all other addresses to be matched > >> instead. This does not affect > the selection > >> of port numbers. > >> > >> The keyword "any" is 0.0.0.0/0 > or the IPv6 > >> equivalent. The keyword > "assigned" is the > >> address or set of addresses assigned > >> > >> to the terminal. The first > rule SHOULD > >> > >> be "deny in ip !assigned". > >> > >> With the TCP, UDP and SCTP protocols, > >> > >> optional ports may be specified as: > >> > >> {port|port-port}[,port[,...]] > >> > >> The `-' notation specifies a > range of ports > >> (including boundaries). > >> > >> options: > >> > >> DSCP > >> color values as defined in [49]. > Exact matching > >> of DSCP values is required (no > masks or ranges). > >> the "deny" can replace the color_under or > >> color_over values in the meter > action for rate- > >> dependent packet drop. > >> > >> metering > >> The metering option provides > Assured Forwarding, > >> as defined in [50], and MUST be > present if the > >> action is set to meter. The rate > option is the > >> throughput, in bits per second, > which is used > >> by the access device to mark > packets. Traffic > >> above the rate is marked with the > color_over > >> codepoint, > >> while traffic under the rate is > marked with the > >> color_under codepoint. The color_under and > >> color_over options contain the drop > preferences, > >> and MUST conform to the recommended > codepoint > >> keywords described in [50] (e.g. AF13). > >> > >> The metering option also supports the strict > >> limit on traffic required by Expedited > >> Forwarding, as defined in [51]. The > color_over > >> option may contain the keyword > "drop" to prevent > >> forwarding of traffic that exceeds the rate > >> parameter. > >> > >> The rule syntax is a modified subset of ipfw(8) > from FreeBSD, > >> and the ipfw.c code may provide a useful base for > >> implementations. > >> > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 01:17:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f858HS40019612 for ; Wed, 5 Sep 2001 01:17:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f858HSN2019611 for ipng-dist; Wed, 5 Sep 2001 01:17: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f858HO40019604 for ; Wed, 5 Sep 2001 01:17:24 -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 BAA12244 for ; Wed, 5 Sep 2001 01:17:36 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08647 for ; Wed, 5 Sep 2001 01:17:35 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f858H8s07385; Wed, 5 Sep 2001 10:17:08 +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 KAA29392; Wed, 5 Sep 2001 10:17:07 +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 f858H6l13939; Wed, 5 Sep 2001 10:17:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109050817.f858H6l13939@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Robert Elz , ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) In-reply-to: Your message of Tue, 04 Sep 2001 15:08:28 CDT. <3B9534BC.2B45FF52@hursley.ibm.com> Date: Wed, 05 Sep 2001 10:17:06 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I agree, the whole stuff about MF re-classification on > the 5/6 tuple seems silly to me. People do much worse things already, by looking even deeper into the packet. => I know... I'd like to see how this will work at 10Gbits/s. On the principle I don't want to have ISPs that I don't trust to look at the transport header or the payload of my packet. Of course, if the answer is to use ESP we have only shown the silliness of the whole thing! In practice, I agree that port numbers aren't too much use, and probably very often only the addresses will be used. The whole idea Alex and I had was to give IPv6 an advantage by using the flow label to support more effective MF classification. => this is what I have understood so even you proposed a PHB ID in fact alternatives in appendix A are still options... My concern is that if the MF re-classification on the 5/6 tuple or worse is given up then your idea will be given up too: should we discuss about the provision of effective MF classification or discuss about the MF classification itself? Regards Francis.Dupont@enst-bretagne.fr PS: this is an architecture issue, I don't know how to solve it (ask the IAB to move diffserv to historic?) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 02:05:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f8595L40019660 for ; Wed, 5 Sep 2001 02:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f8595LHM019659 for ipng-dist; Wed, 5 Sep 2001 02:05: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f8595H40019652 for ; Wed, 5 Sep 2001 02:05:17 -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 CAA15933 for ; Wed, 5 Sep 2001 02:05:30 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28270 for ; Wed, 5 Sep 2001 03:05:58 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f8594ss15925; Wed, 5 Sep 2001 11:04:54 +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 LAA00425; Wed, 5 Sep 2001 11:04:53 +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 f8594ql14067; Wed, 5 Sep 2001 11:04:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109050904.f8594ql14067@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alex Conta cc: ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Tue, 04 Sep 2001 16:34:17 EDT. <3B953AC9.D2113B27@txc.com> Date: Wed, 05 Sep 2001 11:04:52 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Alex, perhaps I was unfair about the c) option. You were Francis. => I agree, c) is not a bad idea, the problem is with diffserv itself (the MF re-classification on the 5/6 tuple or worse which: - has bad privacy/security implications - is hard to do at very high speed, even with IPv4 - makes IPv6 slower than IPv4 because of the extension header chain (problem you try to fix)) > I understood that you'd like to replace the MF classifier on > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > the 5F classifier by a simpler MF classifier with the flow label > in place of protocol and ports. This cancels the efficiency issue > of the extension header chain of IPv6. > > My first concern is the 5F reclassification is a bad idea because > an ACL-like classifier will never give what I want as an user. > This is too rigid, not real-time, ... It may not give you what you want as a user, but it would give me what "I" (read my customers) want as user(s). => I am not convinced because I have no control on random intermediate ISPs. Perhaps we are using the term user for different things, my user is an end-user, your user is a ISP? Remember, having a Intserv, and Diffserv use of the flow label gives the user the option, and that is a good thing. => because of its scalability problem, Intserv is usable only locally, for instance on the first or last wireless segment between me and my correspondent. But diffserv seems to have the same restriction, ISPs that we are in business are first or last ISPs. Core transit ISPs are pseudo-randomly (for us) chosen and if they re-classify my packets I'd like to know what silly rules on the 5/6 tuple they use... The only reasonable option is to see what are source and destination ISPs (using BGP table for instance) and to remark packets according to them. > The second concern is with ESP: the 5F classifier wants to look at > bits I want to hide. No conciliation is possible, IPsec people > (like Michael) will *never* accept to reveal transport layer or > payload details for a 5F classifier. [...] Let's put religion aside. => security/privacy is a religion we can't fight (:-). I definitely don't want to have to choose between QoS and security/privacy. Conceptually, with IP QoS, infrastructure devices delivering packets to destination, are processing forwarding and QoS information. As traffic between two end-nodes may have distinct QoS requirements, it is obvious that the information to be given to an infrastructure device must provide the differentiation of the traffic between the two end-nodes. That information, by definition, is in some relationship with the multiplexing of the communication between the two end-nodes, which is being realized through the transport (host-to-host) header information. At an extreme, that information is the transport protocol and source and destination ports, themselves. Since, with IP QoS, the QoS information is in the same class, relative to privacy, with the forwarding information, if one needs to apply full privacy to QoS information, it will apply the same criteria as for forwarding information: use tunnel ESP. => I disagree: your proposal is to drop diffserv QoS if I'd like to get security/privacy. I can't accept this. As intserv has not this issue, the problem seems to be in the QoS information, and how it can be used by ISPs. I have contracts with my first ISPs (and my correspondent with last ISPs) so I can mark my packets with the desired QoS, ISPs will apply the QoS (keep my packets, drop others :-) and send the bill to me. This model doesn't work for core transit ISPs: in general I can't choose them, in fact I don't know what they are. I have no trust in them, I don't pay their bill, etc. And of course they have no trust in me, nor in the bits I've put in the DS field of my packets. So any QoS information I have put in my packets has no meaning... In conclusion I have no relationship with core transit ISPs, they can re-classify by packets on the 5/6 tuple or worse, this is only a crazy way to slow down the core routers. I rely on the first/last ISPs to have business relationships with core transit ISPs in order to get a reasonable service, and core transit ISPs should use MF re-classifier only on the 2/3 tuple (addresses/DS field). BTW IPv6 gets an advantage over IPv4 because of its addressing (better aggregation: simpler prefix matching on source and destination addresses). So I propose to refocus the discussion on the real issue: what will be in practice MF re-classifiers and what constraints will this imply? 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 Sep 5 02:22:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f859Mc40019685 for ; Wed, 5 Sep 2001 02:22:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f859McLU019684 for ipng-dist; Wed, 5 Sep 2001 02:22: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f859MY40019677 for ; Wed, 5 Sep 2001 02:22: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 CAA07983 for ; Wed, 5 Sep 2001 02:22:47 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02259 for ; Wed, 5 Sep 2001 02:22:46 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f859M3s18499; Wed, 5 Sep 2001 11:22: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 LAA00773; Wed, 5 Sep 2001 11:22: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 f859M0l14200; Wed, 5 Sep 2001 11:22:00 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109050922.f859M0l14200@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Michael Thomas , Alex Conta , alh-ietf@tndh.net, ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Tue, 04 Sep 2001 15:22:26 CDT. <3B953802.CAE32063@hursley.ibm.com> Date: Wed, 05 Sep 2001 11:22:00 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There is no proposal to reveal port/protocol numbers in the flow label field, for the simple reason that it's impossible; there is no reversible hash of all those bits into 19. So the idea fails even without the security argument (which is a strong one too). => so you give up the appendix A of draft-conta-ipv6-flow-label-02.txt? The diffserv flow label in proposition c) will be an extension of the DS field with same kind of properties? As for whether people believe in 5-tuple classification (for non-encrypted traffic), it surely isn't an issue for this WG. => I'd like to get the head of the 5-tuple classification in the core (:-)! What Alex and I came here to discuss was doing better than that with IPv6. => I understand but I shan't support the c) option until the 5-tuple re-classifier monster is killed. 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 Sep 5 02:30:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f859UL40019719 for ; Wed, 5 Sep 2001 02:30:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f859ULUW019718 for ipng-dist; Wed, 5 Sep 2001 02:30: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f859UH40019711 for ; Wed, 5 Sep 2001 02:30: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 CAA08677 for ; Wed, 5 Sep 2001 02:30:30 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08255 for ; Wed, 5 Sep 2001 03:30:59 -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 f859RV401452; Wed, 5 Sep 2001 16:27:37 +0700 (ICT) From: Robert Elz To: Alex Conta cc: Francis Dupont , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B953AC9.D2113B27@txc.com> References: <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Sep 2001 16:27:31 +0700 Message-ID: <1450.999682051@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 04 Sep 2001 16:34:17 -0400 From: Alex Conta Message-ID: <3B953AC9.D2113B27@txc.com> | Remember, having a Intserv, and Diffserv use of the flow label gives | the user the option, and that is a good thing. Actually, no it isn't, the way it is being proposed anyway, it is a horrible thing indeed. It is certainly a good thing to allow people to decide whether they want to use intserv, or diffserv - but we also have to recognise that they're not likely to have a free choice in large numbers of cases. That is, whether the end user uses intserv, or diffserv, will depend upon what is supported between the source and destination of the packets, not on which protocol the user happens to thing is best (or most suitable for the particular traffic). As described so far, that isn't a problem, as long as the user gets the choice to use the protocol that will actually work, that's what is important, right? The problem comes because there's no guarantee which of intserv or diffserv will be applicable to any particular network. It is entirely possible that both will occur between the two end points of any connection. What's more, aside from being extra work for the user (the user's system) that shouldn't matter - the user should be able to send packets with diffserv classifiers in it, after having requested an intserv path from the intermediate systems that support it. That's why taking the flow label, and saying "this packet is for intserv" or "this packet is for diffserv" is wrong - because the packet might need to be for both. Now, I understand that solving the "how do I work with both intserv and diffserv" problem is out of scope for basically everyone at the minute, and when that is suggested, everyone just says "we're not doing that". And that's fine - but we cannot have a solution to anything which by its very nature means that a solution to that problem can never be obtained, because users are forced to choose (per packet) whether intserv or diffserv is to be applied to that packet - with no way at all to say "both". Having a bit in the flow label that says "this is diffserv" or "this is not diffserv" or "this is a microflow identifier (prng)" or "this is a static classifier" (which amounts to the same thing) if forcing that choice, and leaving no room at all for "both". Everyone has to be able to work with one format of flow label, otherwise we're forcing choices that mean too many possibilities are excluded. 10 years from now we might know enough about how this is actually used to do that, now we simply don't. Nothing more than guessing. | As traffic between two end-nodes may have distinct QoS requirements, it | is obvious that the information to be given to an infrastructure device | must provide the differentiation of the traffic between the two | end-nodes. Yes, this is obvious. | At an extreme, that information is the | transport protocol and source and destination ports, themselves. That's totally the wrong information, but it doesn't really matter, it won't be available anyway - and what matters here anyway is not what the actual information is, but that there needs to be some information. There was very little direct reaction to my previous message (Brian's need to think about it more was about it), but there seems to be some suggestion that an extra header would be too heavyweight, and so be too slow to handle. I can't see how that can possibly be (given what you're willing to allow now anyway) ... just imagine that the IPv6 header was 48 bytes long instead of 40. And instead of one bit to say diffserv or not, that you seem willing to test, there are 8 bits that need to be set to a particular value (sure that's more gates to do the test, but testing 8 bits for a particular value is one of the simpler pieces of logic to design..., and is no slower than testing 1). As long as those bits say that the diffserv QoS info is there, then it would be at a fixed position relative to the start of the packet. Just somewhere between byte 40 and 48 instead of somewhere between byte 0 and 4. Big deal. To compensate for the extra delay while the extra bits arrive, you get more information to use. What's so heavyweight about that? I wasn't proposing anything that would require chasing header chains to find the data, and extracting it from some arbitrary position (though diffserv seems able to do the rough equivalent of that for IPv4 - note that the transport header might be buried within several layers of IP in IP headers). Just at the minute it seems to be (as an outsider) as if people on both sides of this debate have become entrenched in their position, and rather that looking for a solution that can work, are instead simply set on making the solution that they originally conceived into the winner. Please, everyone, back to the drawing board, come up with some solution that is feasible, and can actually work. 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 Sep 5 03:46:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Ake40019851 for ; Wed, 5 Sep 2001 03:46:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85AkeCg019850 for ipng-dist; Wed, 5 Sep 2001 03: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Aka40019843 for ; Wed, 5 Sep 2001 03:46:36 -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 DAA16304 for ; Wed, 5 Sep 2001 03:46:46 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04019 for ; Wed, 5 Sep 2001 03:46:45 -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 GAA22764; Wed, 5 Sep 2001 06:45:19 -0400 (EDT) Message-Id: <200109051045.GAA22764@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, multi6@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ramki-multi6-nlmp-00.txt Date: Wed, 05 Sep 2001 06:45:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A proposal for scalable network-level multihoming Author(s) : R. Gummadi Filename : draft-ramki-multi6-nlmp-00.txt Pages : Date : 04-Sep-01 This document proposes two extensions to BGP4+ to provide scalable multihoming in IPv6. The first is a new well-known and mandatory 'TunneL (TL)' BGP path attribute that allows a multihomed enterprise to maintain global connectivity in the presence of network outages within a direct provider Autonomous System (AS) without adding any global forwarding overhead. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ramki-multi6-nlmp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ramki-multi6-nlmp-00.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-ramki-multi6-nlmp-00.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: <20010904141225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ramki-multi6-nlmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ramki-multi6-nlmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010904141225.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 Wed Sep 5 03:47:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Ala40019871 for ; Wed, 5 Sep 2001 03:47:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85Ala2m019870 for ipng-dist; Wed, 5 Sep 2001 03:47: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85AlV40019863 for ; Wed, 5 Sep 2001 03:47:31 -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 DAA03612 for ; Wed, 5 Sep 2001 03:47:41 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09438 for ; Wed, 5 Sep 2001 03:47:40 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f85Akes00686; Wed, 5 Sep 2001 12:46: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 MAA02115; Wed, 5 Sep 2001 12:46:38 +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 f85Akcl14893; Wed, 5 Sep 2001 12:46:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109051046.f85Akcl14893@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert Elz cc: Alex Conta , ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Wed, 05 Sep 2001 16:27:31 +0700. <1450.999682051@brandenburg.cs.mu.OZ.AU> Date: Wed, 05 Sep 2001 12:46:38 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: There was very little direct reaction to my previous message (Brian's need to think about it more was about it), but there seems to be some suggestion that an extra header would be too heavyweight, and so be too slow to handle. => in fact I'd like this idea, this is a good solution but I am afraid that this is a good solution of a wrong problem... 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 Sep 5 04:48:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Bmk40019931 for ; Wed, 5 Sep 2001 04:48:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85BmkVj019930 for ipng-dist; Wed, 5 Sep 2001 04:48: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Bmg40019923 for ; Wed, 5 Sep 2001 04:48: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 EAA01926 for ; Wed, 5 Sep 2001 04:48:53 -0700 (PDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28062 for ; Wed, 5 Sep 2001 05:49:26 -0600 (MDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.2/8.9.3) with ESMTP id f85BkpK03884; Wed, 5 Sep 2001 07:46:51 -0400 Message-Id: <200109051146.f85BkpK03884@cichlid.adsl.duke.edu> To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com, aconta@txc.com Subject: Re: A good point In-Reply-To: Message from "Tue, 04 Sep 2001 15:03:52 CDT." <3B9533A8.14822E1C@hursley.ibm.com> Date: Wed, 05 Sep 2001 07:46:51 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alex made a very valid point the other day: > > It would look like a > > silly, technical weakness, to have a field as read-only, > > but with no mechanism for the final recipient to detect whether > > it was changed or not. > In other words, even if we declare that the flow label MUST NOT > be changed en route, since it is not authenticated by IPSEC > there is no way to tell if somebody does in fact change it. > So it is not a safe e2e field, even if we define it as an e2e field. In the cases discussed so far (i.e., QOS), I doubt that the final recipient will care what the value of the Flow Label is. So being able to verify its end-to-endness may not really be an issue. I.e., if the packet got there, the destination is presumably happy. Routers, on the other hand, will presumably look at the Flow Label as part of packet classification. Will it also need to somehow verify that the Flow Label is legitimate? That would need seem to need cryptography, which raises the question of how the routers along the path learn the necessary keys. One could imagine inventing a way for routers to obtain the keys and do the verification, but that seems like a high-cost operation. And what is the exact benefit? Would routers need to do this? For every packet? I suspect they would not, even if it were possible. If we look at the Flow Label as a purely unused field and we later decide that it needs to be end-to-end unique, it is unclear that IPsec needs to cover it. Depends entirely on the semantics of the field. In any case, if an intermediate router modfies it, and that causes the recipient to do the wrong thing when the (modified) packet arrives, isn't that analogous to a router modifying (say) the IP version field? If routers just modify any field in the IP header without regards to what impact that has, we're in big trouble already. 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 Wed Sep 5 06:57:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Dv940019983 for ; Wed, 5 Sep 2001 06:57:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85Dv87L019982 for ipng-dist; Wed, 5 Sep 2001 06:57:08 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Dv540019975 for ; Wed, 5 Sep 2001 06:57: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 GAA14201 for ; Wed, 5 Sep 2001 06:57:16 -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 HAA12384 for ; Wed, 5 Sep 2001 07:57:11 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f85Dv2j23243; Wed, 5 Sep 2001 16:57:04 +0300 Date: Wed, 5 Sep 2001 16:57:02 +0300 (EEST) From: Pekka Savola To: cc: , Subject: Re: Question about IPv6 Anycast address In-Reply-To: <29189.999651159@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, 5 Sep 2001 itojun@iijlab.net wrote: > >Hi All, > >According to ADDR ARCH, the anycast address has two restrictions: > >*Anycast address MUST NOT be used as source address; > >*Anycast address MUST NOT be assigned to an IPv6 host. - this seems > >conflicts with the anycast definition. > > I don't think they conflict. you may want to check > draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt. The analysis draft just clarifies what was meant. Being pedantic, the RFC2373 text should talk about routers, not nodes. Or better yet, the restriction should be removed as being a purely operational difficulty that can be worked around. I'd hope this would be done before new addr arch draft goes out of the door (commented on it already) and addrarch will be frozen again for a a couple of years. -- 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 Sep 5 07:08:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85E8740020029 for ; Wed, 5 Sep 2001 07:08:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85E87QN020028 for ipng-dist; Wed, 5 Sep 2001 07:08: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85E8340020018 for ; Wed, 5 Sep 2001 07:08: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 HAA21171 for ; Wed, 5 Sep 2001 07:08: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 IAA29168 for ; Wed, 5 Sep 2001 08:08:47 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f85E81523324; Wed, 5 Sep 2001 17:08:01 +0300 Date: Wed, 5 Sep 2001 17:08:00 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Subject: Re: Routing Header Considered Harmful In-Reply-To: <200109031509.f83F9fl06482@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 Mon, 3 Sep 2001, Francis Dupont wrote: > => to have the choice of the transit ISP, not only the first one, is nice. > I'd like to get this feature in the kernel controlled by a policy, today > I have to hack my Cisco config to do the same thing, this is not scalable. You could negotiate with your upstream to have routing header forwarding enabled; I'd bet 99.99% of users don't care about this feature, and 99% of ISP's neither. > > > > Linux and AFAICS, KAME at least let hosts act as "reflectors". I'm sure > > that's what all would like to do. > > > > => please send bug reports! > > You want to make them non-compliant with RFC2460? > > => to add a flag which controls the forwarding of source routed packets > won't make them non-compliant, just a bit more secure. I am afraid you > see requirements in RFC 2460 which are not in it. A flag will not, but how the flag would be set for hosts by default would :-) > I'm not sure if it's the packet filter's (ie: it may not need to be a > "firewall" as such at all -- e.g. your LAN router) job to know of all the > possible wackiness in all the possible extension headers. > > => yes, it is the job of a real firewall. Could you elaborate on what you would consider to be a good sanity check of routing headers in a real firewall? Defining this might not be simple, and thus unlikely to happen at all. > If this was assumed, I think the behaviour in firewalls would be a toggle > to drop all incoming packets with routing header. A simple and elegent > approach, but perhaps not one one would like. > > => too simple: Mobile IPv6 people won't be happy! If solutions aren't simple enough, people are tempted to _just do it anyway_. "Mobile IPv6? We don't need no MIPv6!". > > Issue with the fix is that you can still do nasties, even though _way_ > > less (as router addresses don't usually have many services which have to > > be enabled in site ingress packet filters): > > > > => source routing doesn't fool ingress filtering (but home address > > option does). I can't see your issue. > > (sorry if I used 'ingress filtering' improperly; I meant incoming access > list, not necessarily only source-address checks) > > => sorry, RFC 2827 gave a very accurate meaning for the "ingress filtering" > term. Confused it with terms like 'site ingress', 'site egress' etc. I suppose. > > => RFC 1122 3.3.5 and RFC 1812 5.3.13.4 > > I don't think these apply to IPv6.. unless you want them to. :-) > > => they apply until there are the equivalent for IPv6. Unfortunately, there is no such thing as "Source Route Option" for IPv6. :-) > > => read RFC 1812 5.3.13.4 which has an explicit MUST NOT disallow > > (with DISCUSSION and EDITORS+COMMENTS) > > We can improve the security by default from IPv4... > > => old arguments about IPv4 are still valid for IPv6. And I thought IPv6 was also supposed to be more secure than IPv4. .. Unless you have a good suggestion on how to perform routing header sanity checks in a real firewall, I think we should close this thread. -- 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 Sep 5 07:42:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Eg640020094 for ; Wed, 5 Sep 2001 07:42:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85Eg6pq020093 for ipng-dist; Wed, 5 Sep 2001 07:42:06 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Eg240020086 for ; Wed, 5 Sep 2001 07:42:02 -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 HAA19828 for ; Wed, 5 Sep 2001 07:42:12 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16439 for ; Wed, 5 Sep 2001 08:42:44 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA34882; Wed, 5 Sep 2001 15:42:04 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA37304; Wed, 5 Sep 2001 15:42:03 +0100 Message-ID: <3B963A91.801940F6@hursley.ibm.com> Date: Wed, 05 Sep 2001 09:45:37 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: Robert Elz , ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) References: <200109050817.f858H6l13939@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: ... > (ask the IAB to move diffserv to historic?) I don't think so :-) Actually the diffserv architecture does not formally require MF classifiers and does not formally require them to be port/protocol based, although the 5tuple classifier is cited. If somebody comes up with a better solution it can be plugged right in. 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 Sep 5 07:47:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85ElP40020111 for ; Wed, 5 Sep 2001 07:47:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85ElPN3020110 for ipng-dist; Wed, 5 Sep 2001 07:47:25 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85ElI40020103 for ; Wed, 5 Sep 2001 07:47:18 -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 HAA23118 for ; Wed, 5 Sep 2001 07:47:20 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06485 for ; Wed, 5 Sep 2001 07:47:18 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA14038; Wed, 5 Sep 2001 15:47:15 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id PAA26660; Wed, 5 Sep 2001 15:47:14 +0100 Message-ID: <3B963BC3.1AAC9EE0@hursley.ibm.com> Date: Wed, 05 Sep 2001 09:50:43 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Francis Dupont CC: Michael Thomas , Alex Conta , alh-ietf@tndh.net, ipng Subject: Re: a), b), c), d), or e) References: <200109050922.f859M0l14200@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > > In your previous mail you wrote: > > There is no proposal to reveal port/protocol numbers > in the flow label field, for the simple reason that it's impossible; > there is no reversible hash of all those bits into 19. So the > idea fails even without the security argument (which is a > strong one too). > > => so you give up the appendix A of draft-conta-ipv6-flow-label-02.txt? > The diffserv flow label in proposition c) will be an extension of > the DS field with same kind of properties? Sure, it was included as FYI. > > As for whether people believe in 5-tuple classification (for > non-encrypted traffic), it surely isn't an issue for this WG. > > => I'd like to get the head of the 5-tuple classification in the core (:-)! > > What Alex and I came here to discuss was doing better than > that with IPv6. > > => I understand but I shan't support the c) option until the 5-tuple > re-classifier monster is killed. That is not the business of this WG and irrelevant to the issue of using the flow label. It's also running code and I think out of the hands of the IETF and in the hands of the market to decide. 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 Sep 5 08:00:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85F0F40020156 for ; Wed, 5 Sep 2001 08:00:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85F0FI9020155 for ipng-dist; Wed, 5 Sep 2001 08:00: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85F0B40020148 for ; Wed, 5 Sep 2001 08:00: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 IAA22726 for ; Wed, 5 Sep 2001 08:00:22 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02485 for ; Wed, 5 Sep 2001 09:00:16 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA24624; Wed, 5 Sep 2001 16:00:09 +0100 Received: from hursley.ibm.com ([9.29.3.174]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA36734; Wed, 5 Sep 2001 16:00:09 +0100 Message-ID: <3B963EBC.79D4AE00@hursley.ibm.com> Date: Wed, 05 Sep 2001 10:03:24 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Alex Conta , Francis Dupont , ipng Subject: Re: a), b), c), d), or e) References: <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: ... > The problem comes because there's no guarantee which of intserv or > diffserv will be applicable to any particular network. It is entirely > possible that both will occur between the two end points of any > connection. There are a couple of models for doing that in the ISSLL WG. Maybe they should be having this argument. From a quick glance, none of those documents refer to the flow label. > What's more, aside from being extra work for the user > (the user's system) that shouldn't matter - the user should be able > to send packets with diffserv classifiers in it, after having requested > an intserv path from the intermediate systems that support it. > > That's why taking the flow label, and saying "this packet is for intserv" > or "this packet is for diffserv" is wrong - because the packet might need > to be for both. That's why the "well known value/locally unique value" dichotomy seems more hopeful. ... > Just at the minute it seems to be (as an outsider) as if people on both > sides of this debate have become entrenched in their position, and rather > that looking for a solution that can work, are instead simply set on > making the solution that they originally conceived into the winner. Not particularly. But I think we do need to find solutions that minimise change. As has been said, people are pouring silicon. 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 Sep 5 08:25:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85FPn40020219 for ; Wed, 5 Sep 2001 08:25:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85FPnUK020218 for ipng-dist; Wed, 5 Sep 2001 08: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85FPj40020211 for ; Wed, 5 Sep 2001 08:25:45 -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 IAA28608 for ; Wed, 5 Sep 2001 08:25:56 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08783 for ; Wed, 5 Sep 2001 08:25:53 -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 f85FMu407082; Wed, 5 Sep 2001 22:22:56 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: Alex Conta , Francis Dupont , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B963EBC.79D4AE00@hursley.ibm.com> References: <3B963EBC.79D4AE00@hursley.ibm.com> <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 05 Sep 2001 22:22:56 +0700 Message-ID: <7080.999703376@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 05 Sep 2001 10:03:24 -0500 From: Brian E Carpenter Message-ID: <3B963EBC.79D4AE00@hursley.ibm.com> | That's why the "well known value/locally unique value" dichotomy seems | more hopeful. But that means that a packet is one or the other, and hence inserv (which needs a micro-flow ID, not a fixed classifier) or diffserv (which needs a classifier, but no micro-flow ID), but never both. How can that possibly allow a packet to flow through a local intserv domain in my (end-user's net) and then through diffserv in the outside ISPs, and then back into intserv processing again when it reaches the destination net. I don't know how to do that now, but I know I don't want to make it impossible. And given that we have ESP, that only the source/dest nodes can decode, all we have left for anyone to look at is what we put in the IPv6 header, and other headers before ESP. At the minute the only proposal I have seen is the flow label usage. And that seems to be being designed to preclude using more than one QoS paradigm (for one particular packet). | Not particularly. But I think we do need to find solutions that minimise | change. As has been said, people are pouring silicon. Minimise change because people are making hardware today must mean leaving the flow label the way it is in 2460 (or making that text be normative instead of an appendix). Anything else is change. If we can have change one way, and that is acceptable, slightly different change must be acceptable too,. 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 Sep 5 08:28:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85FSi40020236 for ; Wed, 5 Sep 2001 08:28:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85FSi2B020235 for ipng-dist; Wed, 5 Sep 2001 08:28: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85FSd40020228 for ; Wed, 5 Sep 2001 08:28:39 -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 IAA27356 for ; Wed, 5 Sep 2001 08:28:50 -0700 (PDT) Received: from internaut.com ([64.38.134.99]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10580 for ; Wed, 5 Sep 2001 08:28:49 -0700 (PDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA46456; Wed, 5 Sep 2001 08:19:58 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 5 Sep 2001 08:19:58 -0700 (PDT) From: Bernard Aboba To: jarno.rajahalme@nokia.com cc: jschnizl@cisco.com, pcalhoun@diameter.org, aaa-wg@merit.edu, ipng@sunroof.eng.sun.com Subject: Re: [AAA-WG]: IPv6 flow label support in the QoSFilterRule in Diameter (RE: [AA A-WG]: Issue 87: Move filter-rule AVP to base) In-Reply-To: <009CA59D1752DD448E07F8EB2F91175719800D@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there a hard deadline for any new issues for Diameter? We've just finished a WG last call, so the deadline is yesterday ;) So if there are issues with the specs, please get them in now. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 08:51:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Fp740020280 for ; Wed, 5 Sep 2001 08:51:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85Fp7jV020279 for ipng-dist; Wed, 5 Sep 2001 08:51: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Fp340020272 for ; Wed, 5 Sep 2001 08:51:03 -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 IAA07272 for ; Wed, 5 Sep 2001 08:51:14 -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 IAA24355 for ; Wed, 5 Sep 2001 08:51:13 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f85ForQ24004; Wed, 5 Sep 2001 18:50:53 +0300 Date: Wed, 5 Sep 2001 18:50:52 +0300 (EEST) From: Pekka Savola To: Emmanuel Varagnat cc: Srinivasa Rao Nalluri , IPng Subject: Re: a doubt on MTU discovery in IPv6 In-Reply-To: <3B963C50.4364FF35@crm.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 5 Sep 2001, Emmanuel Varagnat wrote: > Pekka Savola wrote: > > > > Your confusion may be based on the difference that in IPv4, routers also > > may fragment packets. IPv6 fragmentation is end-to-end, and you either > > use minimum MTU 1280, or implement Path MTU Discovery (above). > > This makes me think about something strange in Path MTU Discovery. > > A note in the section 4 of Path MTU Discovery for IPv6 (RFC1981) say: > "A node may receive a Packet Too Big message reporting a > next-hop MTU that is less than the IPv6 minimum link MTU. In that > case, the node is not required to reduce the size of subsequent > packets sent on the path to less than the IPv6 minimun link MTU, > but rather must include a Fragment header in those packets [IPv6- > SPEC]." > > Does this can cause problems with the IPv6 standard that specify that > under 1280 octets, the layer below IPv6 must deal with the > fragmentation ? Yes, or use Fragmentation Header for every too big packet. (as far as I can see :-) -- 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 Sep 5 09:00:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85G0I40020297 for ; Wed, 5 Sep 2001 09:00:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85G0IJY020296 for ipng-dist; Wed, 5 Sep 2001 09:00: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85G0E40020289 for ; Wed, 5 Sep 2001 09:00: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 JAA07662 for ; Wed, 5 Sep 2001 09:00:25 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02938 for ; Wed, 5 Sep 2001 10:00:57 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f85G0Cs09687; Wed, 5 Sep 2001 18:00:12 +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 SAA06579; Wed, 5 Sep 2001 18:00:11 +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 f85G0Al16264; Wed, 5 Sep 2001 18:00:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109051600.f85G0Al16264@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Wed, 05 Sep 2001 17:08:00 +0300. Date: Wed, 05 Sep 2001 18:00:10 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => to have the choice of the transit ISP, not only the first one, is nice. > I'd like to get this feature in the kernel controlled by a policy, today > I have to hack my Cisco config to do the same thing, this is not scalable. You could negotiate with your upstream to have routing header forwarding enabled. => I should not... Source routing is supposed to be enabled by default on routers, including my upstream ISP routers. The current situation for IPv4 is from laziness and FUD, I expect to get something better for IPv6. > => to add a flag which controls the forwarding of source routed packets > won't make them non-compliant, just a bit more secure. I am afraid you > see requirements in RFC 2460 which are not in it. A flag will not, but how the flag would be set for hosts by default would :-) => where in RFC 2460 you have read that. I am still looking for this kind of statements and I can't find it. > => yes, it is the job of a real firewall. Could you elaborate on what you would consider to be a good sanity check of routing headers in a real firewall? => see after. "Mobile IPv6? We don't need no MIPv6!" => I can't parse this. .. Unless you have a good suggestion on how to perform routing header sanity checks in a real firewall, I think we should close this thread. => first you have three possible position for a firewall: - filtering outbound traffic from your site - filtering inbound traffic to your site - inside the backbone For many reasons (speed, lack of good policy, ...), no firewall should be in the last position. About outbound traffic, I can't see a good reason to check source routes, so the issue is with inbound traffic. First you can reject source routed packets with a type != 0, and accept all with segment left == 0. Other source routed packets enter in one of three cases: - will bounce inside the site: apply a local policy (default is to reject packets but if you ask a peer to source route via a specified router (*) you may accept only packets via this router for instance). - will bounce outside the site: reject them if they are not special cases (testing tools for instance). Rate limit them! - for mobile node: apply a local policy, for instance detect mobile nodes (home address option, binding updates (signaling), explicit negociation via AAA (my favorite because it works for home address options too)) and recognize this case. This scheme has already been implemented so I can find more details... (*) this can happen with site multihoming: an upstream ISP is no more available, you ask correspondents to add a source route via a router using an address in an other ISP prefix. 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 Sep 5 10:33:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85HXT40021105 for ; Wed, 5 Sep 2001 10:33:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85HXT81021104 for ipng-dist; Wed, 5 Sep 2001 10:33:29 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85HXP40021097 for ; Wed, 5 Sep 2001 10:33:25 -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 KAA06612 for ; Wed, 5 Sep 2001 10:33:37 -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 LAA29392 for ; Wed, 5 Sep 2001 11:34:09 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f85HXOs24591; Wed, 5 Sep 2001 20:33:25 +0300 Date: Wed, 5 Sep 2001 20:33:24 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Subject: Re: Routing Header Considered Harmful In-Reply-To: <200109051600.f85G0Al16264@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 Wed, 5 Sep 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > => to have the choice of the transit ISP, not only the first one, is nice. > > I'd like to get this feature in the kernel controlled by a policy, today > > I have to hack my Cisco config to do the same thing, this is not scalable. > > You could negotiate with your upstream to have routing header forwarding > enabled. > > => I should not... Source routing is supposed to be enabled by default on > routers, including my upstream ISP routers. The current situation for > IPv4 is from laziness and FUD, I expect to get something better for IPv6. As far as I see, the issues are basically the same. No one has bothered to implement the firewall checks for verifying "legal" source-routes from Source Route options either. > > => to add a flag which controls the forwarding of source routed packets > > won't make them non-compliant, just a bit more secure. I am afraid you > > see requirements in RFC 2460 which are not in it. > > A flag will not, but how the flag would be set for hosts by default would > :-) > > => where in RFC 2460 you have read that. I am still looking for this kind > of statements and I can't find it. the spec talks about node. Hosts and routers are both nodes. > "Mobile IPv6? We don't need no MIPv6!" > > => I can't parse this. Cutting out the redneck: "Mobile IPv6? We don't need MIPv6!" Also see below. > .. Unless you have a good suggestion on how to perform routing header > sanity checks in a real firewall, I think we should close this thread. > > => first you have three possible position for a firewall: > - filtering outbound traffic from your site > - filtering inbound traffic to your site > - inside the backbone > For many reasons (speed, lack of good policy, ...), no firewall should be > in the last position. About outbound traffic, I can't see a good reason to > check source routes, so the issue is with inbound traffic. Please also see above; why nobody bothered to do any checking for IPv4 source routes? I don't see people would be significantly more enthusiastic about that with IPv6, _unless_ there are some new killer applications using it _securely_. > First you can reject source routed packets with a type != 0, and > accept all with segment left == 0. Other source routed packets enter > in one of three cases: > - will bounce inside the site: apply a local policy (default is to reject > packets but if you ask a peer to source route via a specified router (*) > you may accept only packets via this router for instance). > - will bounce outside the site: reject them if they are not special cases > (testing tools for instance). Rate limit them! Basically these cover all significant applications (except MIPv6) where the packet would still be source-routed anywhere, yes? (If not, please elaborate on how multihoming relations could be made abstract enough for a firewall). (one exception: if there is AH, return route will be source routed; this will be ok, as the reflected path will be outside your own jurisdiction anyway, and authenticated). > - for mobile node: apply a local policy, for instance detect mobile nodes > (home address option, binding updates (signaling), explicit negociation > via AAA (my favorite because it works for home address options too)) > and recognize this case. This scheme has already been implemented > so I can find more details... Only problem with this is that I fail to see how you _really_ could identify mobile nodes? Requiring state in the firewall for this is probably unacceptable. In general, short of the MN problem above these sound rather good. Only, I would want to have something like this implemented in every router (which would make the behaviour rather close to "disable by default", except by mobile ipv6, if the problems can be identified). -- 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 Sep 5 12:39:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85JdU40021600 for ; Wed, 5 Sep 2001 12:39:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85JdUnr021599 for ipng-dist; Wed, 5 Sep 2001 12:39: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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Jd840021592 for ; Wed, 5 Sep 2001 12:39:08 -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 MAA14150 for ; Wed, 5 Sep 2001 12:38:34 -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 MAA06008 for ; Wed, 5 Sep 2001 12:38:33 -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 f85JYuD27512; Wed, 5 Sep 2001 12:35:56 -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 ABI03586; Wed, 5 Sep 2001 12:36:51 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA24335; Wed, 5 Sep 2001 12:36:51 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15254.32467.341293.958960@thomasm-u1.cisco.com> Date: Wed, 5 Sep 2001 12:36:51 -0700 (PDT) To: Alex Conta Cc: Francis Dupont , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B953AC9.D2113B27@txc.com> References: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <3B953AC9.D2113B27@txc.com> 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 With Intserv-like networks, you don't ever need to reveal any L4+ headers. This is also true with diffserv networks if you don't require (re)classification, which is a perfectly reasonable way to design a diffserv network. This entire controversy surrounds whether diffserv networks which have interior routers do the classification is legitimate. Considering that it breaks a perfectly reasonable user desire -- privacy -- I'd say that's a pretty good reason to question the base premise. Mike Alex Conta writes: > > > Francis Dupont wrote: > > > > Alex, perhaps I was unfair about the c) option. > > You were Francis. > > > I understood that you'd like to replace the MF classifier on > > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > > the 5F classifier by a simpler MF classifier with the flow label > > in place of protocol and ports. This cancels the efficiency issue > > of the extension header chain of IPv6. > > > > My first concern is the 5F reclassification is a bad idea because > > an ACL-like classifier will never give what I want as an user. > > This is too rigid, not real-time, ... > > > > It may not give you what you want as a user, but it would give me > what "I" (read my customers) want as user(s). > > Remember, having a Intserv, and Diffserv use of the flow label gives > the user the option, and that is a good thing. > > > The second concern is with ESP: the 5F classifier wants to look at > > bits I want to hide. No conciliation is possible, IPsec people > > (like Michael) will *never* accept to reveal transport layer or > > payload details for a 5F classifier. [...] > > > > Francis > > Let's put religion aside. > > Conceptually, with IP QoS, infrastructure devices delivering packets to > destination, are processing forwarding and QoS information. > > As traffic between two end-nodes may have distinct QoS requirements, it > is obvious that the information to be given to an infrastructure device > must provide the differentiation of the traffic between the two > end-nodes. > That information, by definition, is in some relationship with the > multiplexing > of the communication between the two end-nodes, which is being realized > through the > transport (host-to-host) header information. At an extreme, that > information is the > transport protocol and source and destination ports, themselves. > > Since, with IP QoS, the QoS information is in the same class, relative > to privacy, > with the forwarding information, if one needs to apply full privacy to > QoS information, > it will apply the same criteria as for forwarding information: use > tunnel ESP. > > Regards, > 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 Wed Sep 5 14:52:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Lq840022151 for ; Wed, 5 Sep 2001 14:52:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85Lq8F3022150 for ipng-dist; Wed, 5 Sep 2001 14:52:08 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Lq440022142 for ; Wed, 5 Sep 2001 14:52:04 -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 OAA21629 for ; Wed, 5 Sep 2001 14:52:12 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA17681 for ; Wed, 5 Sep 2001 15:52:09 -0600 (MDT) Received: from 157.54.9.101 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 Sep 2001 14:51:44 -0700 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Sep 2001 14:51:41 -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: Routing Header Considered Harmful Date: Wed, 5 Sep 2001 14:51:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Routing Header Considered Harmful Thread-Index: AcE2MoZxsENNKvQiRHy1gbkbQeYX7wAD7sSg From: "Brian Zill" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 05 Sep 2001 21:51:41.0988 (UTC) FILETIME=[F2B05640:01C13654] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f85Lq440022144 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note that besides Mobile IPv6 there is currently at least one other valid (and very handy) use for the routing header -- round-trip traceroute. You do the traceroute with the "destination" as the intermediate node and yourself as the final destination, and you get back replies from all the routers on both the forward and reverse paths. This is very useful for tracking down problems along asymmetric routes. Our traceroute implementation supports this feature, I believe others do as well. --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 Sep 5 16:40:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85New40022619 for ; Wed, 5 Sep 2001 16:40:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0/Submit) id f85Newre022618 for ipng-dist; Wed, 5 Sep 2001 16:40:58 -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.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Nes40022611 for ; Wed, 5 Sep 2001 16:40:54 -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 QAA21067 for ; Wed, 5 Sep 2001 16:41:05 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02510 for ; Wed, 5 Sep 2001 17:41:03 -0600 (MDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Wed, 05 Sep 2001 16:40:49 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 037110F44DC84B9B81ECD0D1BBC5B814 for plus 3 more; Wed, 05 Sep 2001 16:40:49 -0700 Reply-To: From: "Tony Hain" To: "Thomas Narten" , "Brian E Carpenter" Cc: , Subject: RE: A good point Date: Wed, 5 Sep 2001 16:40:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200109051146.f85BkpK03884@cichlid.adsl.duke.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-SLUIDL: 944D00CA-7091475E-91D87FFA-6E9C28D9 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f85Net40022612 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > If routers just modify any field in the IP header without regards to > what impact that has, we're in big trouble already. Witness NAT :) Actually we have this problem today because network operators have been led to believe that diffserv is all about giving them the power to remark the DSCP at their whim. Since they don't want to build the mechanism which would allow financial feedback to curtail abuse from the source, they simply assume the received values are bogus and mark them without even looking at anything except the port values. 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 Wed Sep 5 22:18:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865IGIQ023150 for ; Wed, 5 Sep 2001 22:18:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f865IGFC023149 for ipng-dist; Wed, 5 Sep 2001 22:18:16 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865ICIQ023142 for ; Wed, 5 Sep 2001 22:18:12 -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 WAA04673 for ; Wed, 5 Sep 2001 22:18:25 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21555 for ; Wed, 5 Sep 2001 22:18:24 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA03413; Thu, 6 Sep 2001 01:19:30 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA14704; Thu, 6 Sep 2001 01:19:15 -0400 Message-ID: <3B970750.C0B38F9B@txc.com> Date: Thu, 06 Sep 2001 01:19:12 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng Subject: Re: a), b), c), d), or e) References: <200109050904.f8594ql14067@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF8ED99216D2339B4AC6C144F" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF8ED99216D2339B4AC6C144F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > > Alex, perhaps I was unfair about the c) option. > > You were Francis. > > => I agree, c) is not a bad idea, the problem is with diffserv itself > (the MF re-classification on the 5/6 tuple or worse which: I do not agree that there is a problem with Diffserv itself or with M-F classifiers. > [..] > Core transit ISPs > are pseudo-randomly (for us) chosen and if they re-classify my packets > I'd like to know what silly rules on the 5/6 tuple they use... No silly rules, just rules. I would like to know too, and I may learn the standard rules but the proprietary rules, is much more difficult. Practically though, for most people, it would not really matter, as long as core providers provide the service people or people's access providers pay for (on people's behalf). > [...] > > Since, with IP QoS, the QoS information is in the same class, relative > to privacy, > with the forwarding information, if one needs to apply full privacy to > QoS information, > it will apply the same criteria as for forwarding information: use > tunnel ESP. > > => I disagree: your proposal is to drop diffserv QoS if I'd like to get > security/privacy. I can't accept this. You do not have to drop diffserv QoS. Let's acknowledge first, that what is the most important is the confidentiality of the application payload, i.e. the user's message. Hiding completely the fields of the transport header, or the fields of the IP headers, that one may be worried about, does not eliminate the use of forwarding and QoS information. The tunnel header carries forwarding and QoS information that is pertinent to the tunnel (traffic). If the tunnel carries one flow, then that applies to one flow. If it carries an aggregation of flows, it applies to that set of flows. > As intserv has not this issue, > the problem seems to be in the QoS information, and how it can be used > by ISPs. By the way, RFC 2207 applies only to non-flow label based Intserv. So your assertion is not true for the use of Intserv flow label. Your 'has not this issue', or that the mechanism is perfect, applies in general terms. In very specific terms, for instance, it is not clear to me how an RFC 2207 classifier is able to distinguish one user's micro-flows between two end-nodes, based on 4-tuple classification rule. > I have contracts with my first ISPs (and my correspondent with last ISPs) > so I can mark my packets with the desired QoS, ISPs will apply the QoS > (keep my packets, drop others :-) and send the bill to me. For this case, if the providers have networks in which they use only Diffserv, why not allow them to use the flow label with Diffserv? > So I propose to refocus the discussion on the real issue: what will be > in practice MF re-classifiers and what constraints will this imply? > > Francis Let's not go on that path. We go in circles, and move the focus, when in fact the problem is fundamentally very simple: 1. premises a. Intserv and Diffserv are two IP QoS models. b. Intserv classifiers are similar to Diffserv M-F classifiers (in fact in hardware, one can use the same engine) c. the IPv6 flow label has a QoS purpose d. the IPv6 flow label can be used with Intserv RFC 2207 states reason - more efficient access to header fields 2. conclusion a. Diffserv should be able to use the IPv6 flow label, like Intserv. based on same reasons - more efficient access to header fields. Regards, alex --------------msF8ED99216D2339B4AC6C144F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDYwNTE5MTJaMCMGCSqGSIb3DQEJBDEWBBQh+TCM7rikWwD0qbDF lNujvXdqezBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gDjutenQsyEpcdlchOQIjJwVJqFBKaezPJUIa9Pi6p+XN7772IFIZktXNpeWNuuiyN0lpHwD tNujiZvAG5R0iPApgOae+GsaP8lU4Q+lyYSEx8ap1bmcQUVI7z2uYmMBfTmMP6bX+bIB2pf7 QMhx0zgxtstOROB/1Xu3uhadw9al --------------msF8ED99216D2339B4AC6C144F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 22:18:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865IjIQ023160 for ; Wed, 5 Sep 2001 22:18:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f865Ijer023159 for ipng-dist; Wed, 5 Sep 2001 22:18: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865IeIQ023152 for ; Wed, 5 Sep 2001 22:18:40 -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 WAA17461 for ; Wed, 5 Sep 2001 22:18:53 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA19500 for ; Wed, 5 Sep 2001 23:18:51 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA03418; Thu, 6 Sep 2001 01:19:58 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA14720; Thu, 6 Sep 2001 01:19:57 -0400 Message-ID: <3B97077A.126A76BB@txc.com> Date: Thu, 06 Sep 2001 01:19:54 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: <200109050922.f859M0l14200@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA49ABA8397F52893D898B314" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msA49ABA8397F52893D898B314 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > What Alex and I came here to discuss was doing better than > that with IPv6. > > => I understand but I shan't support the c) option until the 5-tuple > re-classifier monster is killed. > > Regards > > Francis.Dupont@enst-bretagne.fr In fact the c) option is not using the 5-tuple classifier. So I do not understand why you link them together. But the M-F Diffserv classifier is not different than the Intserv data path classifier. It uses the same fields, with the same type of capability to represent range of values by wildcarding some of the bits, or an entire field. How come you do not have a problem with the Intserv classifier? Regards, Alex --------------msA49ABA8397F52893D898B314 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDYwNTE5NTRaMCMGCSqGSIb3DQEJBDEWBBRfD8VzyA6O4vAnpdGv ANsv1DGWwzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gJ0wmM9RbZJS3oFFD4YiP7UIaJ0LMYDIonnMOkt7xZqL6cfypgejeCcT8/4+qx2lP8H1Yg9r rn3Kef/1i8PFnsx6Jti7p05GyOIGjDJw1ssJK5ncX5cwlZT8fDSqsuZB5ttLMfcNbmwBlMSF C2wvE+nHXAaBwPIH4EQCiA0z6NWl --------------msA49ABA8397F52893D898B314-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 22:26:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865QoIQ023189 for ; Wed, 5 Sep 2001 22:26:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f865QoCC023188 for ipng-dist; Wed, 5 Sep 2001 22:26: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865QjIQ023181 for ; Wed, 5 Sep 2001 22:26: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 WAA05561 for ; Wed, 5 Sep 2001 22:26:58 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA22279 for ; Wed, 5 Sep 2001 23:26:56 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA03480; Thu, 6 Sep 2001 01:28:03 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA14884; Thu, 6 Sep 2001 01:28:01 -0400 Message-ID: <3B97095F.F790D3EA@txc.com> Date: Thu, 06 Sep 2001 01:27:59 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: Francis Dupont , ipng Subject: Re: a), b), c), d), or e) References: <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8355C1EE09AA1E4393FDD57B" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms8355C1EE09AA1E4393FDD57B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Kre, Sorry for not answering your message earlier. I was on travel, and I tackled, shorter messages first. I left much of your text, which makes the message longer, but makes easier to follow the line of thought. Robert Elz wrote: > > Date: Tue, 04 Sep 2001 16:34:17 -0400 > From: Alex Conta > Message-ID: <3B953AC9.D2113B27@txc.com> > > | Remember, having a Intserv, and Diffserv use of the flow label gives > | the user the option, and that is a good thing. > [...] > > It is certainly a good thing to allow people to decide whether they > want to use intserv, or diffserv - but we also have to recognise that > they're not likely to have a free choice in large numbers of cases. > > That is, whether the end user uses intserv, or diffserv, will depend > upon what is supported between the source and destination of the packets, > not on which protocol the user happens to thing is best (or most > suitable for the particular traffic). Providers are routers/switches users, and they decide what to use in their networks, i.e. in their routers/switches. > As described so far, that isn't a problem, as long as the user gets the > choice to use the protocol that will actually work, that's what is > important, right? That's right. The "end-user" users, and "provider" users. But it is not right to say that "because there is Intserv, that might work, we must not allow Diffserv, that would also work". > > The problem comes because there's no guarantee which of intserv or > diffserv will be applicable to any particular network. It is entirely > possible that both will occur between the two end points of any > connection. As it is very possible that Diffserv will be used e2e. > What's more, aside from being extra work for the user > (the user's system) that shouldn't matter - the user should be able > to send packets with diffserv classifiers in it, after having requested > an intserv path from the intermediate systems that support it. > > That's why taking the flow label, and saying "this packet is for intserv" > or "this packet is for diffserv" is wrong - because the packet might need > to be for both. > You are right. But "is wrong", in fact, applies to RFC 2460, appendix A, i.e. the PRN number. You are pointing in fact to one of the main reasons why there was a need to define a flow label formatting, or value setting for Diffserv. That is because RFC 2460 appendix A, through the PRN rule and some others, excludes Diffserv. > Now, I understand that solving the "how do I work with both intserv and > diffserv" problem is out of scope for basically everyone at the minute, > and when that is suggested, everyone just says "we're not doing that". > And that's fine - but we cannot have a solution to anything which by its > very nature means that a solution to that problem can never be obtained, > because users are forced to choose (per packet) whether intserv or > diffserv is to be applied to that packet - with no way at all to say "both". > No. In fact it was in our scope, Brian and I, and those who support c), to have both Intserv, and Diffserv work. To make Intserv, and Diffserv flow labels work with the same flow label value on the same sequence of packets is an additional requirement, but is in my mind, a subset, and it can be resolved, it is just working out the details. It may imply some restrictions, like a router cannot use the same 3-tuple rule for both Diffserv and Intserv, if the QoS processing of the packet after classification is different, which most likely it is. Our proposal needs more work, we knew that -- to have both Intserv, and Diffserv work with the same label, Brian and I acknowledged that. But it is important to underline that "c)" does not exclude Intserv, " b)" does exclude Diffserv. In reality, nothing other than the using of a Pseudo Random Number (PRN) rule, of RFC 2460, appendix A, prevents a node to signal a Diffserv formatted label (ala our proposal) as part of a Intserv filter_spec. > [...] > Everyone has to > be able to work with one format of flow label, otherwise we're forcing > choices that mean too many possibilities are excluded. 10 years from > now we might know enough about how this is actually used to do that, now > we simply don't. Nothing more than guessing. This is an important point. Earlier, we also got the point that a static separation of the label space is not considered optimal, or acceptable by some people on the thread. I didn't mind working with the premise that the label space must not be statically divided. I would not mind to consider c) as it was, but with the extension that flow label is shared to the extent that a flow label value must work with both Diffserv and Intserv. > > | As traffic between two end-nodes may have distinct QoS requirements, it > | is obvious that the information to be given to an infrastructure device > | must provide the differentiation of the traffic between the two > | end-nodes. > > Yes, this is obvious. > > | At an extreme, that information is the > | transport protocol and source and destination ports, themselves. > > That's totally the wrong information, but it doesn't really matter, it > won't be available anyway - and what matters here anyway is not what the > actual information is, but that there needs to be some information. > You're right. That is in fact, exactly what I meant, which is why I said "at an extreme". > There was very little direct reaction to my previous message (Brian's > need to think about it more was about it), but there seems to be some > suggestion that an extra header would be too heavyweight, and so be > too slow to handle. I am not sure if I answered that directly or indirectly. I may have also missed your message. But you're right, it is too slow, too heavyweight. In fact I was looking for the same efficiency for Diffserv, as that given to Intserv by the flow label. Additionally... > > I can't see how that can possibly be (given what you're willing to allow > now anyway) ... just imagine that the IPv6 header was 48 bytes long > instead of 40. > [...] > of that for IPv4 - note that the transport header might be buried within > several layers of IP in IP headers). > ...Additionally, because it is the same field in the IPv6 main header, for both Intserv, and Diffserv, it allows the use of the same software/hardware/silicon classification engine core for both. > Just at the minute it seems to be (as an outsider) as if people on both > sides of this debate have become entrenched in their position, and rather > that looking for a solution that can work, are instead simply set on > making the solution that they originally conceived into the winner. > It is interesting that you perceive it this way. I said it many times on this thread, or related threads, that in my perception those who want "c)", like Brian, myself, Christian, and others, are /looking for/seeking/ a "win-win" situation, that is, Diffserv with no excluding of Intserv. Those who want "b)", in my perception, just want to exclude Diffserv from using the flow label (at any cost), which is a "win-lose" situation. > Please, everyone, back to the drawing board, come up with some solution > that is feasible, and can actually work. > kre So, I take your pointing to "c)" ,i.e. that is use of flow label by both Intserv, and Diffserv, with the caveat of a flow label format & value that can be used by both Intserv, and Diffserv. Alex --------------ms8355C1EE09AA1E4393FDD57B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDYwNTI3NTlaMCMGCSqGSIb3DQEJBDEWBBTSETemF5l2SzTC1jHA EThVK1Xi4zBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gARCuA8KyZVPkRm9xl+wvJ8G/LwR1ZlKBZuKXJCV8nkybGyErfeM5Y1jQ1o4uWtf8VdDt6nu UhPdpqBTeidgz3NAsjDaIZeJrL8GN8HJFc1pC3S27A/rDGAVPLT0AsPNVbIYLj/IyIYHgunc wOPOV2qKkzbQTtpBR+KMgEtbK/eB --------------ms8355C1EE09AA1E4393FDD57B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 22:28:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865SVIQ023206 for ; Wed, 5 Sep 2001 22:28:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f865SVBF023205 for ipng-dist; Wed, 5 Sep 2001 22:28:31 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865SRIQ023198 for ; Wed, 5 Sep 2001 22:28:27 -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 WAA05135 for ; Wed, 5 Sep 2001 22:28:40 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23194 for ; Wed, 5 Sep 2001 23:28:38 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA03505; Thu, 6 Sep 2001 01:29:46 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA14935; Thu, 6 Sep 2001 01:29:45 -0400 Message-ID: <3B9709C6.AD921F86@txc.com> Date: Thu, 06 Sep 2001 01:29:42 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: Brian E Carpenter , Francis Dupont , ipng Subject: Re: a), b), c), d), or e) References: <3B963EBC.79D4AE00@hursley.ibm.com> <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> <7080.999703376@brandenburg.cs.mu.OZ.AU> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms85C2DD01AA6B0D44D20E6577" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms85C2DD01AA6B0D44D20E6577 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Elz wrote: > > Date: Wed, 05 Sep 2001 10:03:24 -0500 > From: Brian E Carpenter > Message-ID: <3B963EBC.79D4AE00@hursley.ibm.com> > > | That's why the "well known value/locally unique value" dichotomy seems > | more hopeful. > > But that means that a packet is one or the other, and hence inserv > (which needs a micro-flow ID, not a fixed classifier) or diffserv > (which needs a classifier, but no micro-flow ID), but never both. > > How can that possibly allow a packet to flow through a local intserv > domain in my (end-user's net) and then through diffserv in the outside > ISPs, and then back into intserv processing again when it reaches the > destination net. > > I don't know how to do that now, but I know I don't want to make it > impossible. And given that we have ESP, that only the source/dest > nodes can decode, all we have left for anyone to look at is what we > put in the IPv6 header, and other headers before ESP. At the minute > the only proposal I have seen is the flow label usage. And that seems > to be being designed to preclude using more than one QoS paradigm (for > one particular packet). I think that this can be done. In fact, INTServ, could use the current Diffserv flow label as long as Intserv allows non-PRN numbers. The only issue is that a host MUST NOT set the same label value for the same pair of source and destination to be used by one router for both Diffserv and Intserv. Which is to say, that a router, MUST NOT have two identical classification rules, in two distinct tables, one in the Intserv classification table, one in the Diffserv classification table. This is to say that one router MUST have a certain 3 tuple, containing a certain flow label value, stored in a classification rule either by way of RSVP (Intserv), or by way, of Configuration/etc... (Diffserv), but not by both. > > | Not particularly. But I think we do need to find solutions that minimise > | change. As has been said, people are pouring silicon. > > Minimise change because people are making hardware today must mean > leaving the flow label the way it is in 2460 (or making that text be > normative instead of an appendix). > That is not acceptable because it excludes Diffserv. Something MUST be done to have both, and than maximize that (as much as possible). > [...] > > kre Alex --------------ms85C2DD01AA6B0D44D20E6577 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDYwNTI5NDJaMCMGCSqGSIb3DQEJBDEWBBR1J11RdydNB60yixfw rfNx98OmXzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gBp9mYju4QN+Vb4+i17yHJUfZzOzWMCpFt4cItRHl4zklqp6c/cGxNmgg2ViFJU7k5lKPROD UuSRL76aCpexLS1VH2ZESTRK9H4cBQY50eixZLuPPJcTrB77N6nAlCizQOhYELz1/ki9Tp7q CW/m5Q1iXJ2DLFmGr0YDhrL8pXOo --------------ms85C2DD01AA6B0D44D20E6577-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 22:29:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865TsIQ023226 for ; Wed, 5 Sep 2001 22:29:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f865Tsc1023225 for ipng-dist; Wed, 5 Sep 2001 22:29: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f865ToIQ023218 for ; Wed, 5 Sep 2001 22:29: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 WAA06243 for ; Wed, 5 Sep 2001 22:30:02 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24048 for ; Wed, 5 Sep 2001 22:30:02 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id BAA03528; Thu, 6 Sep 2001 01:31:08 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id BAA14984; Thu, 6 Sep 2001 01:31:07 -0400 Message-ID: <3B970A16.CBB84629@txc.com> Date: Thu, 06 Sep 2001 01:31:02 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Francis Dupont , Robert Elz , ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) References: <200109050817.f858H6l13939@givry.rennes.enst-bretagne.fr> <3B963A91.801940F6@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msE1E2E07143DCF1804D85D2B3" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msE1E2E07143DCF1804D85D2B3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Brian E Carpenter wrote: > > Francis Dupont wrote: > ... > > (ask the IAB to move diffserv to historic?) > > I don't think so :-) > > Actually the diffserv architecture does not formally require MF classifiers > and does not formally require them to be port/protocol based, although > the 5tuple classifier is cited. If somebody comes up with a better solution > it can be plugged right in. > > Brian No, no. Alex --------------msE1E2E07143DCF1804D85D2B3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDYwNTMxMDVaMCMGCSqGSIb3DQEJBDEWBBQ2O98Xuepwrrp62bRh GYvvLK0jHzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gJyoO/d00oXc5WYQeB7xS6pfXsXsDsim6dYIom2MwkAwirD1Nq2nxwclnoxChvHoD/ed01JU Fk1bxKGNscXBI5d0P+HhOajqPbAd1Q6bqvQa7Z0ZhV0UM+ZuXh3C5zqMCAK2F7WBNom2/OSu Ttd4bupNz4iQdYUdMoezEN2vhLqV --------------msE1E2E07143DCF1804D85D2B3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 00:05:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f8675HIQ023387 for ; Thu, 6 Sep 2001 00:05:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f8675GCw023386 for ipng-dist; Thu, 6 Sep 2001 00: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f8675DIQ023379 for ; Thu, 6 Sep 2001 00:05: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 AAA29124 for ; Thu, 6 Sep 2001 00:05:24 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA27570 for ; Thu, 6 Sep 2001 01:05:55 -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 f86701c02297; Thu, 6 Sep 2001 14:00:01 +0700 (ICT) From: Robert Elz To: Alex Conta cc: Francis Dupont , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B97095F.F790D3EA@txc.com> References: <3B9709C6.AD921F86@txc.com> <3B97095F.F790D3EA@txc.com> <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Sep 2001 14:00:00 +0700 Message-ID: <2295.999759600@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 06 Sep 2001 01:27:59 -0400 From: Alex Conta Message-ID: <3B97095F.F790D3EA@txc.com> | I left much of your text, which makes the message longer, but makes | easier to follow the line of thought. I'm going to try to send one reply to your 2 replies to me, and because your messages should be just before mine in everyone's mailboxes, and in the archives, I'll delete most of the context, leaving just the parts I am directly responding to. (The first 2 messages in the References header identify the 3 I am replying to directly, for anyone who needs to find them). | But it is not right to say that "because there is Intserv, that might | work, we must not allow Diffserv, that would also work". I don't know who is saying that, but it isn't me. There is some question about how diffserv needs to be supported, but "not allow" certainly isn't part of the answer. Nor "not allow" some other new QoS protocol that hasn't yet been invented. | That is because RFC 2460 appendix A, through the PRN rule and some others, | excludes Diffserv. No, it doesn't allow diffserv type use of the flow label field. That isn't "excludes diffserv", just alters the way it should be used. | No. In fact it was in our scope, Brian and I, and those who support c), | to have both Intserv, and Diffserv work. That would be good - nd if you can show me a plausible way it could be done (and ideally, how other different schemes yet to be invented could also be supported) then I think you'll find that much of the opposition (from an IPv6 perspective, rather than perhaps internal to how diffserv does, does not, or should, or should not, work, which is a different issue entirely). | To make Intserv, and Diffserv flow labels work with the same flow label | value on the same sequence of packets is an additional requirement, Perhaps, but I think an essential one, which hasn't been demonstrated yet. | is in my mind, a subset, and it can be resolved, it is just working out | the details. Yes... | It may imply some restrictions, like a router cannot use the | same 3-tuple rule for both Diffserv and Intserv, if the QoS processing | of the packet after classification is different, which most likely it | is. I'm not so worried about the same router wanting intserv & diffserv classification of the same packet - that would be a pretty silly thing to expect. But different routers wanting to handle the packet using different QoS schemes. | Our proposal needs more work, we knew that -- to have both Intserv, and | Diffserv work with the same label, Brian and I acknowledged that. I think that needs to be done before anyone would consider changing the flow label spec. At the very least you would need a pretty convincing argument that it can be done. | But it is important to underline that "c)" does not exclude Intserv, " As described so far, if the flow label is formatted in the diffserv way, it seems to me that it does, as a diffserv formatted packet carries the means for packet classification, where for intserv, the packet needs to carry the identifier of a previously setup classification scheme. That is, for any particular traffic type, the former will be a constant, and the latter will not be. That looks like "exclude" to me. Unless you can find some other way around that. | b)" does exclude Diffserv. b excludes diffserv use of the flow label field, yes - but that's a different thing than excludes diffserv. | In reality, nothing other than the using of a Pseudo Random Number (PRN) | rule, of RFC 2460, appendix A, prevents a node to signal a Diffserv | formatted label (ala our proposal) as part of a Intserv filter_spec. No, it doesn't - but there's just one diffserv formatted label for any particular traffic type, right? It is basically a well known value (otherwise it would be useless for diffserv classification). As I understand intserv (which isn't a lot, nor diffserv), a static value isn't very useful. | I didn't mind working with the premise that the label space must not be | statically divided. If there's been a proposal which avoids that, I must have missed it. Where was that? | I would not mind to consider c) as it was, but with the extension that | flow label is shared to the extent that | a flow label value must work with both Diffserv and Intserv. Fine - how? | In fact I was looking for the same efficiency for Diffserv, as that | given to Intserv by the flow label. As I understand it, and do correct me if I'm wrong - that's not really needed. That is, by your own earlier argument, the flow label should be used for packet forwarding in the fast path. In diffserv as I understand it, the bulk of the routers would never be looking at the classifier (the thing you want to stick in the flow label). Hence, it should not be there, as it isn't being used for forwarding. On the other hand, for intserv, every router uses this value - it is truly in the fast path of forwarding, and hence, by your own earlier argument, its value belongs in the flow label. On the other hand, I also appreciate that the routers that do do diffserv classification need to be able to process packets quickly as well, so the format to be used for the classifier needs to be efficient enough to extract for that subset of all the routers (what, 4 or 5 maybe in a path length of 30 or so? - assuming diffserv is used everywhere). [Quoted out of order, wrt getting the value from someplace else]: | I am not sure if I answered that directly or indirectly. I may have also | missed your message. But you're right, it is too slow, too heavyweight. I wouldn't be right in that case, I would be wrong. I don't believe that it would be, I think you're not understanding just what it is that I was proposing - but I will reply to that part of the other message stream (the one that is off the list - which I did, as my original message contained too much ignorance of what is actually required). | ...Additionally, because it is the same field in the IPv6 main header, | for both Intserv, and Diffserv, it allows the use of the same | software/hardware/silicon classification engine core for both. That's a good point if it actually gains a lot. I would have thought that the classification being done, and how it is used, would differ remarkably between the two, so as to negate that benefit. But who knows, I don't have much idea what is happening, perhaps I am completely wrong. But I thought that diffserv was to use this value to access its database of classification rules, and from that calculate a traffic class (I forget the acronym you're using for this value now), and then set that in the traffic class field for future routers in your domain, while simultaneously using it to decide upon queueing (perhaps routing) strategy for the packet (just like later routers will do). On the other hand, intserv is using the value (long with addresses, etc) to access its forwarding table to direct the packet along a path previously established (queueing, etc...) No access to the classification database, that was done before, instead access to a totally different place. So, while the silicon to actually get the field out of the packet might be shared, that seems to me to be the easy part of all of this - after that almost everything is different, until we finally have the "how do I process this packet" - which has come from elsewhere (different in the two cases), though it eventually will probably be processed the same way. I would certainly like to hear from someone who has ever designed silicon to actually process both intserv, and diffserv, and who has used, or could use, the ability to share the flow label access to good benefit (something that couldn't be essentially as easily done with the flow label elsewhere in the packet). | I said it many times on this thread, or related threads, that in my | perception those who want "c)", like Brian, myself, Christian, and | others, are /looking for/seeking/ a "win-win" situation, that is, | Diffserv with no excluding of Intserv. I would like that too. | Those who want "b)", in my perception, just want to exclude Diffserv | from using the flow label (at any cost), which is a "win-lose" | situation. I think they're mostly wanting to make sure that the current uses of the flow label aren't disadvantaged by its being given a static value, which until now has never been really considered. And I don't think it needs to be a win-lose. | So, I take your pointing to "c)" ,i.e. that is use of flow label by | both Intserv, | and Diffserv, with the caveat of a flow label format & value that can be | used by both Intserv, and Diffserv. Show us how that can be done. | I think that this can be done. In fact, INTServ, could use the current | Diffserv flow label as long as Intserv allows non-PRN numbers. Since any value, considered alone, is just as much a random number as any other value, using a number that happens to be identical to a diffserv classifier must be OK for intserv. For one flow. For the next flow however, intserv (as I understand it) would prefer a different value - even for the same QoS request. diffserv wants the same value. That's where it seems to get hard to me. | > Minimise change because people are making hardware today must mean | > leaving the flow label the way it is in 2460 (or making that text be | > normative instead of an appendix). | That is not acceptable because it excludes Diffserv. Something MUST be | done to have both, and than maximize that (as much as possible). My comment there was a response to Brian's "minimise change" as a request, which I suspect he intended as "minimise change to current thinking about diffserv" but which when treated properly, really would mean exclude diffserv from the flow label. The point was that "minimise change" is not what you need to be aiming for. 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 Sep 6 02:30:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f869UmIQ023679 for ; Thu, 6 Sep 2001 02:30:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f869UmRQ023678 for ipng-dist; Thu, 6 Sep 2001 02:30: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f869UiIQ023671 for ; Thu, 6 Sep 2001 02:30: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 CAA27276 for ; Thu, 6 Sep 2001 02:30:57 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03305 for ; Thu, 6 Sep 2001 02:30:56 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f869Uas20589; Thu, 6 Sep 2001 11:30:37 +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 LAA14321; Thu, 6 Sep 2001 11:30:37 +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 f869Ual19283; Thu, 6 Sep 2001 11:30:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109060930.f869Ual19283@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Robert Elz , ipng Subject: Re: Portmanteau reply Re: a), b), c), d), or e) In-reply-to: Your message of Wed, 05 Sep 2001 09:45:37 CDT. <3B963A91.801940F6@hursley.ibm.com> Date: Thu, 06 Sep 2001 11:30:36 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Actually the diffserv architecture does not formally require MF classifiers and does not formally require them to be port/protocol based, although the 5tuple classifier is cited. => this is my concern: the door is open for stupidity. If somebody comes up with a better solution it can be plugged right in. => perhaps this mailing list is not the good one (diffserv-interest?) but the fact we have again this discussion shows the issue has to be fixed ASAP. 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 Sep 6 02:47:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f869lcIQ023704 for ; Thu, 6 Sep 2001 02:47:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f869lcos023703 for ipng-dist; Thu, 6 Sep 2001 02:47: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f869lYIQ023696 for ; Thu, 6 Sep 2001 02:47:34 -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 CAA28396 for ; Thu, 6 Sep 2001 02:47:46 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA23478 for ; Thu, 6 Sep 2001 03:48:20 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f869kss22744; Thu, 6 Sep 2001 11:46:54 +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 LAA14616; Thu, 6 Sep 2001 11:46: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 f869knl19371; Thu, 6 Sep 2001 11:46:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109060946.f869knl19371@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: Michael Thomas , Alex Conta , alh-ietf@tndh.net, ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Wed, 05 Sep 2001 09:50:43 CDT. <3B963BC3.1AAC9EE0@hursley.ibm.com> Date: Thu, 06 Sep 2001 11:46:49 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => so you give up the appendix A of draft-conta-ipv6-flow-label-02.txt? > The diffserv flow label in proposition c) will be an extension of > the DS field with same kind of properties? Sure, it was included as FYI. => so the next version of the draft should be more accurate about the draw backs of appendix A proposals (introduction talks about positive and negative aspects but there is nothing/not enough thing about negative aspects). > What Alex and I came here to discuss was doing better than > that with IPv6. > > => I understand but I shan't support the c) option until the 5-tuple > re-classifier monster is killed. That is not the business of this WG and irrelevant to the issue of using the flow label. => so I suggest in a previous mail to move this discussion to another list. It's also running code and I think out of the hands of the IETF and in the hands of the market to decide. => I disagree because I am not so trusting in the wisdom of the market. Current diffserv specs are too neutral about misuses of 5F re-classifiers so: - IPsec users can get an unfair penalty - IPv6 users can get an unfair penalty - core router engineers have to find a way to implement 5F classification at very high speed (obviously a very hard task :-) If we can not stop stupidity we should document it ASAP, perhaps if we did that for NATs *in time* today the situation would be better. 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 Sep 6 09:09:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86G9EIQ024461 for ; Thu, 6 Sep 2001 09:09:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86G9E1O024460 for ipng-dist; Thu, 6 Sep 2001 09:09: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86G9AIQ024453 for ; Thu, 6 Sep 2001 09:09:10 -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 JAA01345 for ; Thu, 6 Sep 2001 09:09:24 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11897 for ; Thu, 6 Sep 2001 10:09:56 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f86G9Ds04788; Thu, 6 Sep 2001 18:09:14 +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 SAA20322; Thu, 6 Sep 2001 18:09:14 +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 f86G9Dl20427; Thu, 6 Sep 2001 18:09:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109061609.f86G9Dl20427@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Wed, 05 Sep 2001 20:33:24 +0300. Date: Thu, 06 Sep 2001 18:09:13 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > A flag will not, but how the flag would be set for hosts by default would > :-) > > => where in RFC 2460 you have read that. I am still looking for this kind > of statements and I can't find it. the spec talks about node. Hosts and routers are both nodes. => the problem is not node or host, it is with a requirement you can find and I can't find. > .. Unless you have a good suggestion on how to perform routing header > sanity checks in a real firewall, I think we should close this thread. > > => first you have three possible position for a firewall: > - filtering outbound traffic from your site > - filtering inbound traffic to your site > - inside the backbone > For many reasons (speed, lack of good policy, ...), no firewall should be > in the last position. About outbound traffic, I can't see a good reason to > check source routes, so the issue is with inbound traffic. Please also see above; why nobody bothered to do any checking for IPv4 source routes? => because options are not used for IPv4 so they don't matter (why to add a whole set of rules for 0.001% of the traffic?) I don't see people would be significantly more enthusiastic about that with IPv6, => the situation should be different for IPv6 because the broken in practice option mechanism has been replaced by the superior extension header mechanism. _unless_ there are some new killer applications using it _securely_. => multihoming, mobile IPv6, ... > First you can reject source routed packets with a type != 0, and > accept all with segment left == 0. Other source routed packets enter > in one of three cases: > - will bounce inside the site: apply a local policy (default is to reject > packets but if you ask a peer to source route via a specified router (*) > you may accept only packets via this router for instance). > - will bounce outside the site: reject them if they are not special cases > (testing tools for instance). Rate limit them! Basically these cover all significant applications (except MIPv6) where the packet would still be source-routed anywhere, yes? => yes (I've described three cases, the last one is MIPv6, so do you expect another answer? :-) (If not, please elaborate on how multihoming relations could be made abstract enough for a firewall). => multihoming stuff will be in the first case (source route for incoming traffic, home address option for outgoing traffic, both as optimizations for tunnels). > - for mobile node: apply a local policy, for instance detect mobile nodes > (home address option, binding updates (signaling), explicit negociation > via AAA (my favorite because it works for home address options too)) > and recognize this case. This scheme has already been implemented > so I can find more details... Only problem with this is that I fail to see how you _really_ could identify mobile nodes? => I've suggested three different ways. Requiring state in the firewall for this is probably unacceptable. => yes, you need a statefull firewall but a stateless firewall is *not* a real one, at least you may not say it is a good one (:-). In general, short of the MN problem above these sound rather good. => I was involved in a project about secure mobility for IPv6, one part (not mine :-) was about mobile aware firewalls so my colleagues had to solve all security issues with MIPv6 (the real problem is with home address options which fool ingress filtering but MN detection is good for source route filtering too). Only, I would want to have something like this implemented in every router => no, the job of a router is to route (which would make the behaviour rather close to "disable by default", => it is disabled if not justified, exactly what we can expect from a firewall, isn't it? except by mobile ipv6, if the problems can be identified). => mobile IPv6 is an interesting case because it uses the home address option which IMHO is more a security problem than source routing. And mobile IPv6 uses it even without routing optimization, the equivalent of not using home address option is the reverse tunneling, a kind of route anti-optimization. Regards Francis.Dupont@enst-bretagne.fr PS: I am surprised nobody else takes part in the discussion. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 09:15:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86GFUIQ024495 for ; Thu, 6 Sep 2001 09:15:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86GFTjZ024494 for ipng-dist; Thu, 6 Sep 2001 09:15: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86GFPIQ024487 for ; Thu, 6 Sep 2001 09:15: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 JAA21328 for ; Thu, 6 Sep 2001 09:15:39 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23810 for ; Thu, 6 Sep 2001 10:15:35 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f86GEss06742; Thu, 6 Sep 2001 18:14:54 +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 SAA20394; Thu, 6 Sep 2001 18:14: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 f86GEsl20485; Thu, 6 Sep 2001 18:14:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109061614.f86GEsl20485@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Alex Conta , ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Wed, 05 Sep 2001 12:36:51 PDT. <15254.32467.341293.958960@thomasm-u1.cisco.com> Date: Thu, 06 Sep 2001 18:14:54 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: This entire controversy surrounds whether diffserv networks which have interior routers do the classification is legitimate. Considering that it breaks a perfectly reasonable user desire -- privacy -- I'd say that's a pretty good reason to question the base premise. => I agree but where/how to fix this? Thanks 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 Sep 6 10:36:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86HanIQ024832 for ; Thu, 6 Sep 2001 10:36:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86HanOA024831 for ipng-dist; Thu, 6 Sep 2001 10:36: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86HajIQ024824 for ; Thu, 6 Sep 2001 10:36:45 -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 KAA29916 for ; Thu, 6 Sep 2001 10:37:00 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24346 for ; Thu, 6 Sep 2001 10:36:59 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f86HaTs16818; Thu, 6 Sep 2001 19:36:29 +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 TAA21284; Thu, 6 Sep 2001 19:36: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 f86HaTl20915; Thu, 6 Sep 2001 19:36:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109061736.f86HaTl20915@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alex Conta cc: ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Thu, 06 Sep 2001 01:19:12 EDT. <3B970750.C0B38F9B@txc.com> Date: Thu, 06 Sep 2001 19:36:29 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Since, with IP QoS, the QoS information is in the same class, relative > to privacy, > with the forwarding information, if one needs to apply full privacy to > QoS information, > it will apply the same criteria as for forwarding information: use > tunnel ESP. > > => I disagree: your proposal is to drop diffserv QoS if I'd like to get > security/privacy. I can't accept this. You do not have to drop diffserv QoS. => I've done an assumption on the default rule (not known ports), you too. If the default is not the worse QoS then to avoid to get the worse QoS is too easy, I could already see that with the port 80 -> low priority rule someone tried to apply here. > I have contracts with my first ISPs (and my correspondent with last ISPs) > so I can mark my packets with the desired QoS, ISPs will apply the QoS > (keep my packets, drop others :-) and send the bill to me. For this case, if the providers have networks in which they use only Diffserv, why not allow them to use the flow label with Diffserv? => they don't need this. The PHB ID flow label extends a bit the range of validity of marks I've put on my packets but they don't change something for core transit ISPs. This is a partial improvement, a real fix needs to fix the status of MF re-classification over the 5/6 tuple or worse in the middle of the network. > So I propose to refocus the discussion on the real issue: what will be > in practice MF re-classifiers and what constraints will this imply? Let's not go on that path. => I disagree: this is the real problem. We go in circles, and move the focus, when in fact the problem is fundamentally very simple: 1. premises a. Intserv and Diffserv are two IP QoS models. b. Intserv classifiers are similar to Diffserv M-F classifiers (in fact in hardware, one can use the same engine) => I disagree with 1b, Intserv classifiers are dynamic and they don't need to be over the 5 tuple because of 1d. c. the IPv6 flow label has a QoS purpose d. the IPv6 flow label can be used with Intserv RFC 2207 states reason - more efficient access to header fields 2. conclusion a. Diffserv should be able to use the IPv6 flow label, like Intserv. => I disagree: Intserv works on dynamically defined micro-flows, Diffserv works on statically defined aggregates. based on same reasons - more efficient access to header fields. => if you'd like to apply this argument you have to remove the possibility to apply a MF classifier over the 5/6 tuple anywhere. Intserv does this by 1b because signaling provides a 1-1 mapping between a slow MF classifier over the 5 tuple and a fast MF classifier over addresses+flow label. You can't do that with Intserv just because you don't know what are the silly rules applied in the middle of the network: a priori you don't know the characterization of aggregates so I can't see you can map them to flow labels. So IMHO the issue is really MF re-classifiers in core transit ISPs (something which is not an IPv6 WG mailing list topic :-). 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 Sep 6 10:47:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86HlpIQ024860 for ; Thu, 6 Sep 2001 10:47:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86HlpnP024859 for ipng-dist; Thu, 6 Sep 2001 10:47: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86HllIQ024852 for ; Thu, 6 Sep 2001 10:47: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 KAA18304 for ; Thu, 6 Sep 2001 10:48:02 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11206 for ; Thu, 6 Sep 2001 11:48:34 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f86HlPs17385; Thu, 6 Sep 2001 19:47:25 +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 TAA21367; Thu, 6 Sep 2001 19:47:26 +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 f86HlPl20960; Thu, 6 Sep 2001 19:47:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109061747.f86HlPl20960@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alex Conta cc: Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Thu, 06 Sep 2001 01:19:54 EDT. <3B97077A.126A76BB@txc.com> Date: Thu, 06 Sep 2001 19:47:25 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I understand but I shan't support the c) option until the 5-tuple > re-classifier monster is killed. In fact the c) option is not using the 5-tuple classifier. => in your question you didn't specify if c) uses it or not. So I do not understand why you link them together. => c) should be at least split in c)+PHB ID-like and c)+Appendix A-like. I don't believe the first c) is a complete solution for diffserv, and the second c) just triggers the issue with MF re-classifiers on the 5-tuple anywhere. But the M-F Diffserv classifier is not different than the Intserv data path classifier. It uses the same fields, with the same type of capability to represent range of values by wildcarding some of the bits, or an entire field. => devices are the same, ways to use them are very different. How come you do not have a problem with the Intserv classifier? => yes because I can use for instance flow labels in order to reduce an Intserv 5F classifier to a simpler one (making the assumption for the discussion that Intserv is usable in the core). 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 Sep 6 10:57:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86HvoIQ025016 for ; Thu, 6 Sep 2001 10:57:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86Hvlqu025012 for ipng-dist; Thu, 6 Sep 2001 10:57:47 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86HvZIQ025004 for ; Thu, 6 Sep 2001 10:57: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 KAA05889 for ; Thu, 6 Sep 2001 10:57:47 -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 KAA05492 for ; Thu, 6 Sep 2001 10:57:47 -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 f86Hvjp27382; Thu, 6 Sep 2001 10:57:45 -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 ABI25380; Thu, 6 Sep 2001 10:57:33 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA24639; Thu, 6 Sep 2001 10:57:33 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15255.47373.298798.299193@thomasm-u1.cisco.com> Date: Thu, 6 Sep 2001 10:57:33 -0700 (PDT) To: Francis Dupont Cc: Michael Thomas , Alex Conta , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <200109061614.f86GEsl20485@givry.rennes.enst-bretagne.fr> References: <15254.32467.341293.958960@thomasm-u1.cisco.com> <200109061614.f86GEsl20485@givry.rennes.enst-bretagne.fr> 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 Francis Dupont writes: > In your previous mail you wrote: > > This entire controversy surrounds whether diffserv > networks which have interior routers do the > classification is legitimate. Considering that it > breaks a perfectly reasonable user desire -- > privacy -- I'd say that's a pretty good reason > to question the base premise. > > => I agree but where/how to fix this? I'm not sure there's anything to be fixed. This strikes me as the same sort of contradiction that NAT's impose on the network. This is a zero sum game; something loses. 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 Thu Sep 6 11:59:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86IxCIQ025163 for ; Thu, 6 Sep 2001 11:59:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86IxCCG025162 for ipng-dist; Thu, 6 Sep 2001 11:59: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86Ix9IQ025155 for ; Thu, 6 Sep 2001 11:59:09 -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 LAA09535 for ; Thu, 6 Sep 2001 11:59:22 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA20286 for ; Thu, 6 Sep 2001 12:59:54 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA41982; Thu, 6 Sep 2001 19:59:14 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA32018; Thu, 6 Sep 2001 19:59:14 +0100 Message-ID: <3B97C4C7.275EFE2B@hursley.ibm.com> Date: Thu, 06 Sep 2001 13:47:35 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: ipng Subject: Re: a), b), c), d), or e) References: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <3B953AC9.D2113B27@txc.com> <15254.32467.341293.958960@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael, to be precise it is not interior routers, but ISP border routers, that would reclassify. But it doesn't change the principle of what you say. Indeed, it is clear that users who wish to be protected against anthing beyond source/destination traffic analysis cannot use the proposed flow-label diffserv mechanism. That's a user trade-off, not a decision for the IETF to make. Brian Michael Thomas wrote: > > With Intserv-like networks, you don't ever need to > reveal any L4+ headers. This is also true with > diffserv networks if you don't require > (re)classification, which is a perfectly > reasonable way to design a diffserv network. > > This entire controversy surrounds whether diffserv > networks which have interior routers do the > classification is legitimate. Considering that it > breaks a perfectly reasonable user desire -- > privacy -- I'd say that's a pretty good reason > to question the base premise. > > Mike > > Alex Conta writes: > > > > > > Francis Dupont wrote: > > > > > > Alex, perhaps I was unfair about the c) option. > > > > You were Francis. > > > > > I understood that you'd like to replace the MF classifier on > > > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > > > the 5F classifier by a simpler MF classifier with the flow label > > > in place of protocol and ports. This cancels the efficiency issue > > > of the extension header chain of IPv6. > > > > > > My first concern is the 5F reclassification is a bad idea because > > > an ACL-like classifier will never give what I want as an user. > > > This is too rigid, not real-time, ... > > > > > > > It may not give you what you want as a user, but it would give me > > what "I" (read my customers) want as user(s). > > > > Remember, having a Intserv, and Diffserv use of the flow label gives > > the user the option, and that is a good thing. > > > > > The second concern is with ESP: the 5F classifier wants to look at > > > bits I want to hide. No conciliation is possible, IPsec people > > > (like Michael) will *never* accept to reveal transport layer or > > > payload details for a 5F classifier. [...] > > > > > > Francis > > > > Let's put religion aside. > > > > Conceptually, with IP QoS, infrastructure devices delivering packets to > > destination, are processing forwarding and QoS information. > > > > As traffic between two end-nodes may have distinct QoS requirements, it > > is obvious that the information to be given to an infrastructure device > > must provide the differentiation of the traffic between the two > > end-nodes. > > That information, by definition, is in some relationship with the > > multiplexing > > of the communication between the two end-nodes, which is being realized > > through the > > transport (host-to-host) header information. At an extreme, that > > information is the > > transport protocol and source and destination ports, themselves. > > > > Since, with IP QoS, the QoS information is in the same class, relative > > to privacy, > > with the forwarding information, if one needs to apply full privacy to > > QoS information, > > it will apply the same criteria as for forwarding information: use > > tunnel ESP. > > > > Regards, > > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Board Chairman, Internet Society http://www.isoc.org "We shall need a number of efficient librarian types to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 12:08:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86J8dIQ025189 for ; Thu, 6 Sep 2001 12:08:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86J8cvx025188 for ipng-dist; Thu, 6 Sep 2001 12:08: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86J8UIQ025181 for ; Thu, 6 Sep 2001 12:08:31 -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 MAA12041 for ; Thu, 6 Sep 2001 12:08:41 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13157 for ; Thu, 6 Sep 2001 12:08:39 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA21270; Thu, 6 Sep 2001 20:08:25 +0100 Received: from hursley.ibm.com ([9.29.3.172]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA14810; Thu, 6 Sep 2001 20:08:26 +0100 Message-ID: <3B97C6C4.C6AB48FA@hursley.ibm.com> Date: Thu, 06 Sep 2001 13:56:04 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Robert Elz CC: Alex Conta , ipng Subject: Re: a), b), c), d), or e) References: <3B9709C6.AD921F86@txc.com> <3B97095F.F790D3EA@txc.com> <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> <2295.999759600@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: ... > | I didn't mind working with the premise that the label space must not be > | statically divided. > > If there's been a proposal which avoids that, I must have missed it. > Where was that? > It's been hinted at in several messages; it will work if you can assert that the same triple {source address, destination address, flow label} is never used in any router for both an intserv flow and a diffserv aggregate simultaneously. I am not yet convinced that this assertion can be made. It will take some thought. 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 Thu Sep 6 13:39:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86Kd2IQ025629 for ; Thu, 6 Sep 2001 13:39:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86Kd2cd025628 for ipng-dist; Thu, 6 Sep 2001 13: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86KcxIQ025621 for ; Thu, 6 Sep 2001 13:38:59 -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 NAA05546 for ; Thu, 6 Sep 2001 13:39:13 -0700 (PDT) Received: from net.apc.gr.jp (apc.allnet.ne.jp [210.228.3.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05400 for ; Thu, 6 Sep 2001 14:39:46 -0600 (MDT) Received: by net.apc.gr.jp (Postfix, from userid 100) id BC8C612A6D2; Fri, 7 Sep 2001 05:41:26 +0900 (JST) Date: Fri, 7 Sep 2001 05:41:26 +0900 From: yasuo shiga To: ipng@sunroof.eng.sun.com Cc: yasuo@apc.gr.jp Subject: RFC-2472 IPV6CP extension Message-ID: <20010907054126.A27701@net.apc.gr.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Mutt/1.2.5i-jp2 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi ALl, this is my first time to participate ipngwg. If I'm wrong, tell me please. If ipngwg did not discuss RFC-2472 IPV6CP, why don't you discuss RFC-2472 IPV6CP extension? Because current IPV6CP option is not enough to offer native IPv6 connectivity for ISP services. PPP has two merits for ISP. The one is stateful configuration, the other is automatic configuration. In IPv4 PPP, ISP have been using IPCP to negotiate and assign an address and default route configuration and resolv configuration to customers. With PPP, customers don't have to configure the difficult configuration. In IPv6, customer will assign not an address but /48 or /64 address space. So customer may configure router configuration. But with IPV6CP extension option, router configuration may be automatic. I've read draft-itojun-ipv6-dialup-requirement-01.txt, I thought that we must discuss IPV6CP options. yasuo shiga -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 15:32:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86MW8IQ025891 for ; Thu, 6 Sep 2001 15:32:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86MW8MA025890 for ipng-dist; Thu, 6 Sep 2001 15:32:08 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86MW6IQ025883 for ; Thu, 6 Sep 2001 15:32:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f86MU5f22442 for ipng@sunroof.eng.sun.com; Thu, 6 Sep 2001 15:30:05 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma0+Sun/8.12.0.Gamma0) with ESMTP id f85Er140020128 for ; Wed, 5 Sep 2001 07:53: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 HAA21414 for ; Wed, 5 Sep 2001 07:53:11 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22328 for ; Wed, 5 Sep 2001 08:53:43 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA22975 for ; Wed, 5 Sep 2001 07:53:10 -0700 (MST)] Received: [from m-il06-r3.mot.com (m-il06-r3.mot.com [129.188.137.194]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA01276 for ; Wed, 5 Sep 2001 07:53:09 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Wed, 5 Sep 2001 07:53:04 -0700 Received: from crm.mot.com (elmer.crm.mot.com [140.101.173.49]) by thorgal.crm.mot.com (Postfix) with ESMTP id 1CC322ECAC; Wed, 5 Sep 2001 16:51:18 +0200 (CEST) Message-Id: <3B963C50.4364FF35@crm.mot.com> Date: Wed, 05 Sep 2001 16:53:04 +0200 From: Emmanuel Varagnat Reply-To: Emmanuel Varagnat-AEV010 Organization: Centre de Recherche de Motorola - Paris X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola Cc: Srinivasa Rao Nalluri , IPng Subject: Re: a doubt on MTU discovery in IPv6 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > > Your confusion may be based on the difference that in IPv4, routers also > may fragment packets. IPv6 fragmentation is end-to-end, and you either > use minimum MTU 1280, or implement Path MTU Discovery (above). This makes me think about something strange in Path MTU Discovery. A note in the section 4 of Path MTU Discovery for IPv6 (RFC1981) say: "A node may receive a Packet Too Big message reporting a next-hop MTU that is less than the IPv6 minimum link MTU. In that case, the node is not required to reduce the size of subsequent packets sent on the path to less than the IPv6 minimun link MTU, but rather must include a Fragment header in those packets [IPv6- SPEC]." Does this can cause problems with the IPv6 standard that specify that under 1280 octets, the layer below IPv6 must deal with the fragmentation ? -Manu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 15:36:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86MaXIQ025934 for ; Thu, 6 Sep 2001 15:36:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86MaWu3025933 for ipng-dist; Thu, 6 Sep 2001 15:36:32 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86MaSIQ025926 for ; Thu, 6 Sep 2001 15:36: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 PAA05419 for ; Thu, 6 Sep 2001 15:36:40 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA17102 for ; Thu, 6 Sep 2001 15:36:40 -0700 (PDT) Received: from 157.54.1.52 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 Sep 2001 15:34:52 -0700 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.2966); Thu, 6 Sep 2001 15:34:51 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 6 Sep 2001 15:34:51 -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.2966); Thu, 6 Sep 2001 15:34:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: refocusing: what about the flow label? Date: Thu, 6 Sep 2001 15:34:14 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: refocusing: what about the flow label? Thread-Index: AcE3B14An+KI5dSQQWedKlSa7OROmgAGN3gw From: "Christian Huitema" To: "Brian E Carpenter" , "Michael Thomas" Cc: "ipng" X-OriginalArrivalTime: 06 Sep 2001 22:34:14.0574 (UTC) FILETIME=[0E8FCCE0:01C13724] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f86MaTIQ025927 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I hope that after three weeks of exchanges, everybody is convinced that we will not get any consensus on whether the best handling of QoS is diffserv, intserv, or maybe no QoS at all. Let's try to be practical. We have a simple problem to solve, the definition of the flow label in the IPv6 specification. I propose the following compromise: The flow label is comprised of 20 bits, divided between a four bit label type and a 16 bit label value. IPv6 sources may set the flow label type and the flow label value to label sequences of packets for which they request special handling by the IPv6 routers, such as non-default quality of service or "real-time" service; the label type defines how the label value shall be used in the production of these services. Label types may be defined in IETF standards and registered with the IANA. This specification (i.e. IPv6) defines only one label type, the basic label, whose value in binary is 0000. Sources that do not require any specific service should set the label type to the basic label and the label value to a null value. When the label type is the basic label and the label value to a non null value, IPv6 routers are expected to treat identically all packets that carry the same source address, destination address and flow label. For example, when traffic is load balanced along several alternate paths, these packets should all sent on a single path; when classification is performed for the purpose of quality of service, these packets should all be classified in the same class. If the label type is set to the basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label value. Processing of the flow label, and possibly rewriting of the label value, is specified in the IETF standard defining the label type. When a router encounters a packet with an unknown flow label type, it should treat the packet as if the label type was the basic value and the label value was the null value. Routers SHOULD NOT rewrite or alter the flow label value if the flow label type is unknown. I believe it captures most of our discussions: we get a basic label that is roughly equivalent to the label currently assumed by RSVP/Intserv; we get reserved bits for the future generations; and we get an extension mechanism that can possibly used by Diffserv, charge to them to describe exactly how they intend to use it. -- 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 Thu Sep 6 16:45:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86NjFIQ026224 for ; Thu, 6 Sep 2001 16:45:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f86NjF3G026223 for ipng-dist; Thu, 6 Sep 2001 16:45: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f86NjBIQ026216 for ; Thu, 6 Sep 2001 16:45: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 QAA02941 for ; Thu, 6 Sep 2001 16:45:25 -0700 (PDT) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19556 for ; Thu, 6 Sep 2001 16:45:20 -0700 (PDT) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 06 Sep 2001 16:44:11 -0700 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with ESMTP id 805B67D2C21947FF9913AB5D3A9329F8 for plus 3 more; Thu, 06 Sep 2001 16:44:11 -0700 Reply-To: From: "Tony Hain" To: "Christian Huitema" , "Brian E Carpenter" , "Michael Thomas" Cc: "ipng" Subject: RE: refocusing: what about the flow label? Date: Thu, 6 Sep 2001 16:44:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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.4522.1200 X-SLUIDL: 90905D3A-52A7497A-88FCC374-F7D19F24 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f86NjBIQ026217 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I can live with this. > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Christian Huitema > Sent: Thursday, September 06, 2001 3:34 PM > To: Brian E Carpenter; Michael Thomas > Cc: ipng > Subject: refocusing: what about the flow label? > > > I hope that after three weeks of exchanges, everybody is > convinced that > we will not get any consensus on whether the best handling of QoS is > diffserv, intserv, or maybe no QoS at all. Let's try to be > practical. We > have a simple problem to solve, the definition of the flow > label in the > IPv6 specification. I propose the following compromise: > > The flow label is comprised of 20 bits, divided between a > four bit label > type and a 16 bit label value. IPv6 sources may set the flow > label type > and the flow label value to label sequences of packets for which they > request special handling by the IPv6 routers, such as non-default > quality of service or "real-time" service; the label type defines how > the label value shall be used in the production of these services. > Label types may be defined in IETF standards and registered with the > IANA. This specification (i.e. IPv6) defines only one label type, the > basic label, whose value in binary is 0000. Sources that do > not require > any specific service should set the label type to the basic label and > the label value to a null value. > > When the label type is the basic label and the label value to > a non null > value, IPv6 routers are expected to treat identically all packets that > carry the same source address, destination address and flow label. For > example, when traffic is load balanced along several alternate paths, > these packets should all sent on a single path; when classification is > performed for the purpose of quality of service, these packets should > all be classified in the same class. If the label type is set to the > basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label > value. > > Processing of the flow label, and possibly rewriting of the > label value, > is specified in the IETF standard defining the label type. > When a router > encounters a packet with an unknown flow label type, it > should treat the > packet as if the label type was the basic value and the label > value was > the null value. Routers SHOULD NOT rewrite or alter the flow > label value > if the flow label type is unknown. > > I believe it captures most of our discussions: we get a basic > label that > is roughly equivalent to the label currently assumed by > RSVP/Intserv; we > get reserved bits for the future generations; and we get an extension > mechanism that can possibly used by Diffserv, charge to them > to describe > exactly how they intend to use it. > > -- 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 18:09:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f8719lIQ026353 for ; Thu, 6 Sep 2001 18:09:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f8719lW6026352 for ipng-dist; Thu, 6 Sep 2001 18:09:47 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f8719gIQ026345 for ; Thu, 6 Sep 2001 18:09: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 SAA17551 for ; Thu, 6 Sep 2001 18:09:56 -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 TAA02793 for ; Thu, 6 Sep 2001 19:10:29 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C0F944B20; Fri, 7 Sep 2001 10:09:48 +0900 (JST) To: yasuo shiga Cc: ipng@sunroof.eng.sun.com In-reply-to: yasuo's message of Fri, 07 Sep 2001 05:41:26 +0900. <20010907054126.A27701@net.apc.gr.jp> 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-2472 IPV6CP extension From: itojun@iijlab.net Date: Fri, 07 Sep 2001 10:09:48 +0900 Message-ID: <3564.999824988@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I've read draft-itojun-ipv6-dialup-requirement-01.txt, >I thought that we must discuss IPV6CP options. in my analysis and past history, IPv6CP option for assigning address space has been discussed and rejected (i guess i mentioned the history in the draft). this partly because that this does not belong to PPP layer. rough agreement at this point is to (1) use RA if /64 assignment is to the ppp link itself, (2) use ICMPv6 prefix delegation for other 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 Thu Sep 6 18:34:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f871YpIQ026411 for ; Thu, 6 Sep 2001 18:34:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f871YpFL026410 for ipng-dist; Thu, 6 Sep 2001 18:34: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f871YlIQ026403 for ; Thu, 6 Sep 2001 18:34: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 SAA17394 for ; Thu, 6 Sep 2001 18:35:03 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA05738 for ; Thu, 6 Sep 2001 18:35:02 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id VAA24185; Thu, 6 Sep 2001 21:36:09 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id VAA00806; Thu, 6 Sep 2001 21:36:08 -0400 Message-ID: <3B982483.CA4F4972@txc.com> Date: Thu, 06 Sep 2001 21:36:03 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert Elz CC: ipng Subject: Re: a), b), c), d), or e) References: <3B9709C6.AD921F86@txc.com> <3B97095F.F790D3EA@txc.com> <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> <2295.999759600@brandenburg.cs.mu.OZ.AU> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms99D362018FB9E700252F6E73" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms99D362018FB9E700252F6E73 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Elz wrote: > > [...] > | That is because RFC 2460 appendix A, through the PRN rule and some others, > | excludes Diffserv. > > No, it doesn't allow diffserv type use of the flow label field. That's correct. > > | No. In fact it was in our scope, Brian and I, and those who support c), > | to have both Intserv, and Diffserv work. > > That would be good - nd if you can show me a plausible way it could be > done (and ideally, how other different schemes yet to be invented could > also be supported) [...] > > [...] > > | Our proposal needs more work, we knew that -- to have both Intserv, and > | Diffserv work with the same label, Brian and I acknowledged that. > The above "the same label" was meant "the same label space". As a further clarification, it means to work on removing a static separation of the flow label space. > I think that needs to be done before anyone would consider changing the > flow label spec. At the very least you would need a pretty convincing > argument that it can be done. > Your statements suggest that any specification of the use of the flow label with Diffserv must work with the use of the flow label by Intserv, and any other possible schemes to be invented... In principle, and I said this before with other words, I do not have trouble with a standard in which both Intserv and Diffserv can share the same label space, and therefore the same label. But I should say that I am troubled, if the standard is not applied fairly, and equally on both sides. Your statements above, and implicitly anything supporting them, I am afraid, create a double standard, don't you think? One, in which it is OK that the specification of the use of the flow label with Intserv, in Appendix A of RFC 2460, which, by requesting the use of a Pseudo-Random Number, excludes currently the use of the flow label by Diffserv, which back in 94-95, 97-98, was "a possible scheme that could be invented in the future". The other, in which any specification for the use of the flow label with Diffserv, MUST work with a Intserv flow label, and anything that could be invented in the future. > | But it is important to underline that "c)" does not exclude Intserv, " > > As described so far, if the flow label is formatted in the diffserv way, > it seems to me that it does, as a diffserv formatted packet carries the > means for packet classification, where for intserv, the packet needs to > carry the identifier of a previously setup classification scheme. That > is, for any particular traffic type, the former will be a constant, and > the latter will not be. That looks like "exclude" to me. Unless you > can find some other way around that. According to the proposal, there is a separation of label space. That ensures that the use of the flow label with Intserv, and Diffserv do not intersect, and therefore, in light of the AD's clarifications regarding normative, non-normative text, there is not need to change "appendix A", in RFC 2460. > > | In reality, nothing other than the using of a Pseudo Random Number (PRN) > | rule, of RFC 2460, appendix A, prevents a node to signal a Diffserv > | formatted label (ala our proposal) as part of a Intserv filter_spec. > > No, it doesn't - but there's just one diffserv formatted label for any > particular traffic type, right? It is basically a well known value > (otherwise it would be useless for diffserv classification). > > As I understand intserv (which isn't a lot, nor diffserv), a static > value isn't very useful. Why not? > > | In fact I was looking for the same efficiency for Diffserv, as that > | given to Intserv by the flow label. > > As I understand it, and do correct me if I'm wrong - that's not really > needed. I correct you. > [Quoted out of order, wrt getting the value from someplace else]: > | I am not sure if I answered that directly or indirectly. I may have also > | missed your message. But you're right, it is too slow, too heavyweight. > > I wouldn't be right in that case, I would be wrong. I was answering your statement "but there seems to be some suggestion that an extra header would be too heavyweight, and so be too slow to handle" So, you were right, there were such suggestions. But please do not misunderstand me, if it is a good approach, please write it up. > I don't believe that > it would be, I think you're not understanding just what it is that I was > proposing - but I will reply to that part of the other message stream > (the one that is off the list - which I did, as my original message > contained too much ignorance of what is actually required). I thought that as a Hop-by-Hop header option, only for Diffserv, it is not going to provide the same efficiency as the flow label, a fixed size field at a fixed offset in the main header, and the advantage of using the classification engine for both Intserv and Diffserv. I replied to you in more detail, with my observations, in a private message. > > | ...Additionally, because it is the same field in the IPv6 main header, > | for both Intserv, and Diffserv, it allows the use of the same > | software/hardware/silicon classification engine core for both. > > That's a good point if it actually gains a lot. I would have thought > that the classification being done, and how it is used, would differ > remarkably between the two, so as to negate that benefit. But who knows, > I don't have much idea what is happening, perhaps I am completely wrong. > I think this was mentioned at least a couple of times, by a couple of people, besides me, on adjacent threads, or this one, for instance Frank Kastenholtz. > > I would certainly like to hear from someone who has ever designed silicon to > actually process both intserv, and diffserv, and who has used, or could use, > the ability to share the flow label access to good benefit You just heard it (-:. > > | I said it many times on this thread, or related threads, that in my > | perception those who want "c)", like Brian, myself, Christian, and > | others, are /looking for/seeking/ a "win-win" situation, that is, > | Diffserv with no excluding of Intserv. > > I would like that too. > > | Those who want "b)", in my perception, just want to exclude Diffserv > | from using the flow label (at any cost), which is a "win-lose" > | situation. > > I think they're mostly wanting to make sure that the current uses of the > flow label aren't disadvantaged by its being given a static value, which > until now has never been really considered. Even though we knew it does not really matter whether the flow label value is PRN or not, it is exactly why Brian and I put out a proposal that would not change the PRN rule for the Intserv use of flow label -- the proposal of a static separation of the flow label space. But again, I am quite concerned by the double standard being suggested, and in fact, applied (see above). > And I don't think it needs to > be a win-lose. > This is a very positive step. > | So, I take your pointing to "c)" ,i.e. that is use of flow label by > | both Intserv, > | and Diffserv, with the caveat of a flow label format & value that can be > | used by both Intserv, and Diffserv. > > Show us how that can be done. > > | I think that this can be done. In fact, INTServ, could use the current > | Diffserv flow label as long as Intserv allows non-PRN numbers. > > Since any value, considered alone, is just as much a random number as > any other value, using a number that happens to be identical to a > diffserv classifier must be OK for intserv. For one flow. For > the next flow however, intserv (as I understand it) would prefer a > different value - even for the same QoS request. diffserv wants the > same value. That's where it seems to get hard to me. > For Diffserv, for a different flow, between the same two end-nodes as the previous flow, there is a need for a different flow label value. For a different flow, between two end-nodes that are different than those of the previous flow, the flow label value can be the same, or can be different. > [..] > kre Alex --------------ms99D362018FB9E700252F6E73 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDcwMTM2MDRaMCMGCSqGSIb3DQEJBDEWBBT37c38X8KBQ+JREI7U 9EZndf0tNjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gEBhdvnL2fb1oOhInDu5l9K/To6fAIe9f59WrsHBahfnOfGL1sDyMLX8T5qncEvfwB0voG4U KkATj0ehDYjE9q7vE0caICCJ4yLQ3RkLL7jPk8CKVQ7gU3UGpaR7E5EJytROH1rfWk33E+86 zKS1pAf9jeGhH0IzF5tQiRorS56Z --------------ms99D362018FB9E700252F6E73-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 19:27:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f872RLIQ026455 for ; Thu, 6 Sep 2001 19:27:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f872RL9b026454 for ipng-dist; Thu, 6 Sep 2001 19:27: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f872RHIQ026447 for ; Thu, 6 Sep 2001 19:27: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 TAA23179 for ; Thu, 6 Sep 2001 19:27:33 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27771 for ; Thu, 6 Sep 2001 20:28:07 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id WAA24684; Thu, 6 Sep 2001 22:28:38 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id WAA01979; Thu, 6 Sep 2001 22:28:37 -0400 Message-ID: <3B9830CF.3D328AC8@txc.com> Date: Thu, 06 Sep 2001 22:28:31 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: ipng Subject: Re: a), b), c), d), or e) References: <200109061736.f86HaTl20915@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF9A5F62FDF204617165BCF4F" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF9A5F62FDF204617165BCF4F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > > For this case, if the providers have networks in which they use only > Diffserv, why not allow them to use the flow label with Diffserv? > > => they don't need this. This is your interpretation. This is needed wherever there is a Diffserv router which does M-F classification, whether access or edge. > The PHB ID flow label extends a bit the range > of validity of marks I've put on my packets but they don't change something > for core transit ISPs. What the PHB ID flow label does is irrelevant, relative to the ability to do an efficient M-F classification, using the same fast and efficient classification engine as the one that can be used by Intserv. This ability is what is relevant. > This is a partial improvement, a real fix needs > to fix the status of MF re-classification over the 5/6 tuple or worse > in the middle of the network. > As the resetting of a machinery to a fresh starting point, anywhere in the network, the M-F re-classification can be seen in fact, as part of the mechanisms that helps Diffserv scale. > > So I propose to refocus the discussion on the real issue: what will be > > in practice MF re-classifiers and what constraints will this imply? > > Let's not go on that path. > > => I disagree: this is the real problem. > It is not a problem at all. It is a feature -- please see above. > We go in circles, and move the focus, when in > fact the problem is fundamentally very simple: > > 1. premises > a. Intserv and Diffserv are two IP QoS models. > b. Intserv classifiers are similar to Diffserv M-F classifiers > (in fact in hardware, one can use the same engine) > > => I disagree with 1b, Intserv classifiers are dynamic and they don't need > to be over the 5 tuple because of 1d. Dynamic or static is irrelevant to the control plane. Classification rules have to be set in a classification rules table, whether for a short duration, or long duration. In fact noone requires a Intserv flow state to be shorter than a certain time interval, so it can be as long as a week, or a month. It is irrelevant to the data plane classification engine that processes the packets, since they process packets regardless of how long a certain classification rule table entry is lived. > > c. the IPv6 flow label has a QoS purpose > d. the IPv6 flow label can be used with Intserv > RFC 2207 states reason - more efficient access to header fields > 2. conclusion > a. Diffserv should be able to use the IPv6 flow label, like > Intserv. > > => I disagree: Intserv works on dynamically defined micro-flows, > Diffserv works on statically defined aggregates. This has no relevance on the data plane classification engine - see above. The statically defined aggregates can have a fine granularity of one application communication between two end nodes. > > based on same reasons - more efficient access to header fields. > > => if you'd like to apply this argument you have to remove the possibility > to apply a MF classifier over the 5/6 tuple anywhere. Intserv does this > by 1b because signaling provides a 1-1 mapping between a slow MF classifier > over the 5 tuple and a fast MF classifier over addresses+flow label. > You can't do that with Intserv just because you don't know what are > the silly rules applied in the middle of the network: a priori you don't > know the characterization of aggregates so I can't see you can map them > to flow labels. I always assumed that the Diffserv flow label based MF classifier, will not exclude the possibility of a 1-1 mapping between a slow classifier ( 5-tuple) and a fast flow classifier (3-tuple). In fact that is one of the essential reasons for the proposals. > So IMHO the issue is really MF re-classifiers in core transit ISPs > (something which is not an IPv6 WG mailing list topic :-). > > Regards > > Francis.Dupont@enst-bretagne.fr I agree with completely, but since you brought it up, I responded. Regards, Alex --------------msF9A5F62FDF204617165BCF4F Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDcwMjI4MzNaMCMGCSqGSIb3DQEJBDEWBBSIds7xAdF5R0aHh/Hd aluCVt4GiTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gH6cn6KxW9lnJb+npFpa2rR5KzLD6fz9WzkYhBWgXU34TvrtS1s/qyKNntAewY9JGJ1mjp0p iCm39mvnliJJNSccMAVc48R4RTwdDvGpx6pB2cTuhKa2Xo2onY702S1g6CI+0tOpIWgfqGqL 3kWpjZ5JqYS4Ez2Hzyb14q1pFfPo --------------msF9A5F62FDF204617165BCF4F-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 19:46:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f872kvIQ026477 for ; Thu, 6 Sep 2001 19:46:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f872kup2026476 for ipng-dist; Thu, 6 Sep 2001 19:46:56 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f872kqIQ026469 for ; Thu, 6 Sep 2001 19:46:52 -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 TAA18305 for ; Thu, 6 Sep 2001 19:47:06 -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 UAA22267 for ; Thu, 6 Sep 2001 20:47:02 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 107474B20; Fri, 7 Sep 2001 11:47:02 +0900 (JST) To: yasuo shiga , ipng@sunroof.eng.sun.com In-reply-to: itojun's message of Fri, 07 Sep 2001 10:09:48 +0900. <3564.999824988@itojun.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: RFC-2472 IPV6CP extension From: itojun@iijlab.net Date: Fri, 07 Sep 2001 11:47:02 +0900 Message-ID: <4547.999830822@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > in my analysis and past history, IPv6CP option for assigning address > space has been discussed and rejected (i guess i mentioned the history > in the draft). this partly because that this does not belong to > PPP layer. rough agreement at this point is to (1) use RA if /64 "this" in "this does not belong to" refers to "the negotiation of global address prefix between upstream and downstream". sorry if it was ambiguous. 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 Sep 6 19:47:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f872l8IQ026487 for ; Thu, 6 Sep 2001 19:47:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f872l8hY026486 for ipng-dist; Thu, 6 Sep 2001 19:47:08 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f872l4IQ026479 for ; Thu, 6 Sep 2001 19:47:04 -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 TAA29497 for ; Thu, 6 Sep 2001 19:47:17 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA24805 for ; Thu, 6 Sep 2001 19:47:17 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id WAA24871; Thu, 6 Sep 2001 22:48:23 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id WAA02369; Thu, 6 Sep 2001 22:48:23 -0400 Message-ID: <3B983571.E43B6B82@txc.com> Date: Thu, 06 Sep 2001 22:48:17 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Brian E Carpenter , ipng Subject: Re: a), b), c), d), or e) References: <200109061747.f86HlPl20960@givry.rennes.enst-bretagne.fr> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDBDB8DECA1F498A8672D3E15" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDBDB8DECA1F498A8672D3E15 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > > => I understand but I shan't support the c) option until the 5-tuple > > re-classifier monster is killed. > > In fact the c) option is not using the 5-tuple classifier. > > => in your question you didn't specify if c) uses it or not. > It was related to flow label wasn't it? So it meant 3-tuple classifier. > > But the M-F Diffserv classifier is not different than the Intserv data > path classifier. > It uses the same fields, with the same type of capability to represent > range of values by wildcarding some of the bits, or an entire field. > > => devices are the same, ways to use them are very different. > The fact that the Intserv and Diffserv model are different, is irrelevant to the classification engine. > How come you do not have a problem with the Intserv classifier? > > => yes because I can use for instance flow labels in order to > reduce an Intserv 5F classifier to a simpler one (making the assumption > for the discussion that Intserv is usable in the core). > So you like that feature. So do we, and we would like to use with Diffserv. That's exactly what our proposal is supposed to accomplish for Diffserv. And your voting b) and the argumentation against c), means in fact that you do not allow us to accomplish that. > Regards > > Francis.Dupont@enst-bretagne.fr Regards, Alex --------------msDBDB8DECA1F498A8672D3E15 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MDcwMjQ4MThaMCMGCSqGSIb3DQEJBDEWBBQ/0d0HhDlFm3cp7ilF UyMtU+n3fzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gIBB1/3V25d4JP4A71fwrJccCP62TO8o3Rq/IoDQXHM+p1O6nTlkXqrpVzJ21MvUPgve8jmz uzPHEfPPXIjEBQv8Rhf42tQ76CAJKJNZVmmWogV1lkEtvYhuHGXVeI5+RxHVheXN0p8SrgDH aSEOzSWxermBgu6FbWgqRBdW5nyI --------------msDBDB8DECA1F498A8672D3E15-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 00:42:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877goIQ026798 for ; Fri, 7 Sep 2001 00:42:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f877gnuG026797 for ipng-dist; Fri, 7 Sep 2001 00:42:49 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877gfIQ026790 for ; Fri, 7 Sep 2001 00:42:45 -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 f877gqN25511; Fri, 7 Sep 2001 09:42:52 +0200 (MET DST) Date: Fri, 7 Sep 2001 09:39:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" To: Brian E Carpenter Cc: Bob Hinden , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I also think that abolishing the term "format prefix" is obfuscation. The > fact is that the leading bits of an address *are* a format prefix and > implementors *will* look at those bits before processing an address. Why > obscure that fact? Brian, It is exactly this that we want to avoid - implementors thinking that they need to inspect the first 3 bits of the addresses. There is no need to do this and we need to reduce the probability that implementors hard-code any knowledge of any leading 3 bit combinations since it will make it harder to use the other 15/16th of the address space in the future. 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 Sep 7 00:48:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877mGIQ026826 for ; Fri, 7 Sep 2001 00:48:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f877mFhE026825 for ipng-dist; Fri, 7 Sep 2001 00:48:15 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877mCIQ026818 for ; Fri, 7 Sep 2001 00:48:12 -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 AAA18366 for ; Fri, 7 Sep 2001 00:48:26 -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 AAA09137 for ; Fri, 7 Sep 2001 00:48:25 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f877mC505143; Fri, 7 Sep 2001 10:48:12 +0300 Date: Fri, 7 Sep 2001 10:48:12 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: Subject: Re: Routing Header Considered Harmful In-Reply-To: <200109061609.f86G9Dl20427@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 Thu, 6 Sep 2001, Francis Dupont wrote: > In your previous mail you wrote: > > > A flag will not, but how the flag would be set for hosts by default would > > :-) > > > > => where in RFC 2460 you have read that. I am still looking for this kind > > of statements and I can't find it. > > the spec talks about node. Hosts and routers are both nodes. > > => the problem is not node or host, it is with a requirement you can find > and I can't find. Not nearly all cases of the IPv6 specification use "must" clauses, even though they are clearly required. A bit tongue-in-cheek now..: For example, by your analogy, if an implementation might choose to (ridiculous!) omit Payload Length field altogether(!) or replace it with something else, it would still be compliant? There is _nothing_ AFAICS in the spec that says Payload Length is a _required_ field, or it _must_ be processed in a certain way. Back to Routing Header.. there are a few cases which hint at it being required: --- IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, [...] --- So IPv6 hosts must accept and (attempt to) process Routing Headers, regardless of order (order issue not important here) "Attempt to" is IMO there because: 1) the implementation must know _how_ to process header, ie. know of the header type; and 2) the header fields must be as specified, ie. parseable --- If, after processing a Routing header of a received packet, an intermediate node determines that the packet is to be forwarded onto a link whose link MTU is less than the size of the packet, the node must discard the packet and send an ICMP Packet Too Big message to the packet's Source Address. --- Routing Headers are to be processed, as above, and it's specified how you must (discard) react on certain failure conditions. So, if the routing header is syntactically correct, it appears that hosts must at least send packet too big messages. Note that 'intermediate node' is not a (big) contradiction here, as it's intermediate only in routing header forwarding sense. > Please also see above; why nobody bothered to do any checking for IPv4 > source routes? > > => because options are not used for IPv4 so they don't matter (why to add > a whole set of rules for 0.001% of the traffic?) But why they aren't used? There are mobile ipv4, multihoming, traceroute etc. solutions very possible for IPv4 too! One could argue that at least at this point, Routing Headers constitute a very small percentage of IPv6 traffic also. > _unless_ there are some new killer applications using it _securely_. > > => multihoming, mobile IPv6, ... Did you forget the last part? :-) Mobile IPv6 will at least need it. > > - for mobile node: apply a local policy, for instance detect mobile nodes > > (home address option, binding updates (signaling), explicit negociation > > via AAA (my favorite because it works for home address options too)) > > and recognize this case. This scheme has already been implemented > > so I can find more details... > > Only problem with this is that I fail to see how you _really_ could > identify mobile nodes? > > => I've suggested three different ways. Do you have more specific ideas how these could work? - Home address option: check if it exists (could be added by anyone, isn't enough) - Binding updates (requires state) - Explicit negotiation (requires state to be exported from AAA to firewall) > Requiring state in the firewall for this is probably unacceptable. > > => yes, you need a statefull firewall but a stateless firewall is *not* > a real one, at least you may not say it is a good one (:-). Stateful firewall usually creates a SPOF, which may not be acceptable for multihoming solutions at least. > Only, I would want to have something like this implemented in every router > > => no, the job of a router is to route There are different kinds of routers. I agree with you when "core" routers are concerned, but "access routers" e.g. of a small-midsize company (not necessaily even classical "router hardware router") must be able to perform these checks. I don't like the idea that everyone should get a big, expensive stateful firewall if all you want is basic security and stateless access-lists. -- 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 Sep 7 00:58:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877w0IQ026855 for ; Fri, 7 Sep 2001 00:58:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f877w0ng026854 for ipng-dist; Fri, 7 Sep 2001 00:58: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877vuIQ026847 for ; Fri, 7 Sep 2001 00:57: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 AAA17834 for ; Fri, 7 Sep 2001 00:58:10 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA15099 for ; Fri, 7 Sep 2001 01:58:31 -0600 (MDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f877wN328780 for ; Fri, 7 Sep 2001 10:58:23 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Sep 2001 10:57:54 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWGSL6>; Fri, 7 Sep 2001 10:57:54 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F911757198013@esebe004.NOE.Nokia.com> To: huitema@windows.microsoft.com, brian@hursley.ibm.com, mat@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: RE: refocusing: what about the flow label? Date: Fri, 7 Sep 2001 10:57:47 +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 Christian, While you intended to stay outside of the different QoS schemes, you still wanted to cover the intserv/RSVP use of the flow label. Some clarifying questions: Assuming that you proposed intserv to use the label type basic: With the label type basic and a non-null label value, are routers supposed to do what you propose regardless of the presence of intserv state? I.e. to nail down the path even if intserv is not used? Could routers not interested in QoS classification based on the flow label at all (e.g. diffserv interior routers) safely use just the 16 bit label value for path distribution (ignoring the label type)? With the current flow label semantics the routers can avoid doing intserv state lookup if the flow label is null. If the flow label is used for path distribution, the router will be searching for the intserv state for all the packets (assuming the router does intserv at all). So from this point-of-view it might be better to designate a separate label type for intserv? Or maybe intserv should be able to use whatever label type it wishes. Some other type could allow for example rewrite at the intserv domain egress, allowing the flow label to be mapped a value meaningful for some other QoS/forwarding domain. (The value itself could be either carried in RSVP or decided by the SLA between the intserv domain egress and the next domain). What I'm aiming at is to see if a classifying router (intserv, diffserv, or other) could be ignorant of the different flow label types when doing the lookup based on the 3-tuple of the source address, destination address and the 20 bit flow label. What state is then found based on the lookup would tell the router what to do with the packet (which flow it belongs to, how to police it, queue it, possibly remark DSCP and/or flow label, which interface to use for output, etc.). In this scenario all the difference of the different label types would be in the control plane (i.e. population of the state found by the lookup engine). The silicon doing the classification would remain the same regardless of the label type. Or will the definition of the label type result in specialized silicon for the different type values? Jarno Christian Huitema wrote: > I hope that after three weeks of exchanges, everybody is > convinced that > we will not get any consensus on whether the best handling of QoS is > diffserv, intserv, or maybe no QoS at all. Let's try to be > practical. We > have a simple problem to solve, the definition of the flow > label in the > IPv6 specification. I propose the following compromise: > > The flow label is comprised of 20 bits, divided between a > four bit label > type and a 16 bit label value. IPv6 sources may set the flow > label type > and the flow label value to label sequences of packets for which they > request special handling by the IPv6 routers, such as non-default > quality of service or "real-time" service; the label type defines how > the label value shall be used in the production of these services. > Label types may be defined in IETF standards and registered with the > IANA. This specification (i.e. IPv6) defines only one label type, the > basic label, whose value in binary is 0000. Sources that do > not require > any specific service should set the label type to the basic label and > the label value to a null value. > > When the label type is the basic label and the label value to > a non null > value, IPv6 routers are expected to treat identically all packets that > carry the same source address, destination address and flow label. For > example, when traffic is load balanced along several alternate paths, > these packets should all sent on a single path; when classification is > performed for the purpose of quality of service, these packets should > all be classified in the same class. If the label type is set to the > basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label > value. > > Processing of the flow label, and possibly rewriting of the > label value, > is specified in the IETF standard defining the label type. > When a router > encounters a packet with an unknown flow label type, it > should treat the > packet as if the label type was the basic value and the label > value was > the null value. Routers SHOULD NOT rewrite or alter the flow > label value > if the flow label type is unknown. > > I believe it captures most of our discussions: we get a basic > label that > is roughly equivalent to the label currently assumed by > RSVP/Intserv; we > get reserved bits for the future generations; and we get an extension > mechanism that can possibly used by Diffserv, charge to them > to describe > exactly how they intend to use it. > > -- 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 00:57:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877vlIQ026845 for ; Fri, 7 Sep 2001 00:57:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f877vlKT026844 for ipng-dist; Fri, 7 Sep 2001 00:57:47 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f877vgIQ026837 for ; Fri, 7 Sep 2001 00:57:43 -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 f877vrN26518; Fri, 7 Sep 2001 09:57:53 +0200 (MET DST) Date: Fri, 7 Sep 2001 09:54:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt To: Richard Draves Cc: Stig Venaas , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Catching up on some old mail ...] > Perhaps it would be best to just remove the "no route" clause from Rule > 1, and say that a destination D is considered unusable if Source(D) is > undefined or if the next-hop neighbor for D is known to be unreachable. The problem with "known to be unreachable" is that it is a very transient condition as RFC 2461 is done. At least the way I read 2461 when NUD declares that a neighbor is unreachable it goes ahead and redoes next hop determination etc but it doesn't retain any state about the node being unreachable - instead it effectively forgets this knowledge. Thus declaring to be unreachable is an event and not a state. So I don't see what you can check - the fact that the event ocurred in the last millisecond? 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 Sep 7 03:26:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87AQBIQ027099 for ; Fri, 7 Sep 2001 03:26:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87AQAgj027098 for ipng-dist; Fri, 7 Sep 2001 03:26: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87AQ7IQ027091 for ; Fri, 7 Sep 2001 03:26:07 -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 DAA09413 for ; Fri, 7 Sep 2001 03:26:19 -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 DAA24761 for ; Fri, 7 Sep 2001 03:26:18 -0700 (PDT) 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 f87AQHv06498 for ; Fri, 7 Sep 2001 12:26:17 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Sep 07 12:26:16 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Sep 2001 12:26:16 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008C86@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'jarno.rajahalme@nokia.com'" , huitema@windows.microsoft.com, brian@hursley.ibm.com, mat@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: RE: refocusing: what about the flow label? Date: Fri, 7 Sep 2001 12:26:04 +0200 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 After observing the discussions for some time I'd like to add my 2 cents on this. I appreciate Christian's efforts to achieve some concensus on this issue, but I'd like to add to Jarno's comments below. What are we doing by allowing multiple uses for the flow label: - Perhaps resolving the "conflict" of opinions and getting some concencus - Creating some conflict in the network, between what the user wants / needs and the way the network and business models are influencing flow treatment. How do we solve that ? Negotiation between the host and network ? compromising one of the two (probably the host/user) ? - We're opening the door for 15 possible uses of the flow label. who knows what will happen there ! Are we happy with ending up in situations where the user has to choose between 2 orthogonal issues like QoS and privacy (just an example) ?? If we are then a split maybe possible, but personally I don't understand why I should make a choice like that. At the same time I also understand and appreciate the need for satisfying the requirements of ISPs and router vendors. It's a matter of deciding how much should be compromised. Regards, Hesham > While you intended to stay outside of the different QoS schemes, you still > wanted to cover the intserv/RSVP use of the flow label. Some clarifying > questions: > > Assuming that you proposed intserv to use the label type basic: With the > label type basic and a non-null label value, are routers supposed to do what > you propose regardless of the presence of intserv state? I.e. to nail down > the path even if intserv is not used? > > Could routers not interested in QoS classification based on the flow label > at all (e.g. diffserv interior routers) safely use just the 16 bit label > value for path distribution (ignoring the label type)? > > With the current flow label semantics the routers can avoid doing intserv > state lookup if the flow label is null. If the flow label is used for path > distribution, the router will be searching for the intserv state for all the > packets (assuming the router does intserv at all). So from this > point-of-view it might be better to designate a separate label type for > intserv? > > Or maybe intserv should be able to use whatever label type it wishes. Some > other type could allow for example rewrite at the intserv domain egress, > allowing the flow label to be mapped a value meaningful for some other > QoS/forwarding domain. (The value itself could be either carried in RSVP or > decided by the SLA between the intserv domain egress and the next domain). > > What I'm aiming at is to see if a classifying router (intserv, diffserv, or > other) could be ignorant of the different flow label types when doing the > lookup based on the 3-tuple of the source address, destination address and > the 20 bit flow label. What state is then found based on the lookup would > tell the router what to do with the packet (which flow it belongs to, how to > police it, queue it, possibly remark DSCP and/or flow label, which interface > to use for output, etc.). In this scenario all the difference of the > different label types would be in the control plane (i.e. population of the > state found by the lookup engine). The silicon doing the classification > would remain the same regardless of the label type. > > Or will the definition of the label type result in specialized silicon for > the different type values? > > Jarno > > Christian Huitema wrote: > > I hope that after three weeks of exchanges, everybody is > > convinced that > > we will not get any consensus on whether the best handling of QoS is > > diffserv, intserv, or maybe no QoS at all. Let's try to be > > practical. We > > have a simple problem to solve, the definition of the flow > > label in the > > IPv6 specification. I propose the following compromise:> > > > > The flow label is comprised of 20 bits, divided between a > > four bit label > > type and a 16 bit label value. IPv6 sources may set the flow > > label type > > and the flow label value to label sequences of packets for which they > > request special handling by the IPv6 routers, such as non-default > > quality of service or "real-time" service; the label type defines how > > the label value shall be used in the production of these services. > > Label types may be defined in IETF standards and registered with the > > IANA. This specification (i.e. IPv6) defines only one label type, the > > basic label, whose value in binary is 0000. Sources that do > > not require > > any specific service should set the label type to the basic label and > > the label value to a null value. > > > > When the label type is the basic label and the label value to > > a non null > > value, IPv6 routers are expected to treat identically all packets that > > carry the same source address, destination address and flow label. For > > example, when traffic is load balanced along several alternate paths, > > these packets should all sent on a single path; when classification is > > performed for the purpose of quality of service, these packets should > > all be classified in the same class. If the label type is set to the > > basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label > > value. > > > > Processing of the flow label, and possibly rewriting of the > > label value, > > is specified in the IETF standard defining the label type. > > When a router > > encounters a packet with an unknown flow label type, it > > should treat the > > packet as if the label type was the basic value and the label > > value was > > the null value. Routers SHOULD NOT rewrite or alter the flow > > label value > > if the flow label type is unknown. > > > > I believe it captures most of our discussions: we get a basic > > label that > > is roughly equivalent to the label currently assumed by > > RSVP/Intserv; we > > get reserved bits for the future generations; and we get an extension > > mechanism that can possibly used by Diffserv, charge to them > > to describe > > exactly how they intend to use it. > > > > -- 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 > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 7 03:59:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87AxuIQ027181 for ; Fri, 7 Sep 2001 03:59:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87AxuLq027180 for ipng-dist; Fri, 7 Sep 2001 03:59:56 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87AxqIQ027173 for ; Fri, 7 Sep 2001 03:59:52 -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 EAA05260 for ; Fri, 7 Sep 2001 04:00:05 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15523 for ; Fri, 7 Sep 2001 04:00:02 -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 f87AxBE01251; Fri, 7 Sep 2001 17:59:12 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: "ipng" Subject: Re: refocusing: what about the flow label? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Sep 2001 17:59:11 +0700 Message-ID: <1249.999860351@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 6 Sep 2001 15:34:14 -0700 From: "Christian Huitema" Message-ID: | Let's try to be practical. We | have a simple problem to solve, the definition of the flow label in the | IPv6 specification. Yes, good. | I propose the following compromise: Unfortunately ... | I believe it captures most of our discussions: we get a basic label that | is roughly equivalent to the label currently assumed by RSVP/Intserv; Roughly yes, but very roughly. The flow label used to be 28 bits (all but the version in the first word). It is already down to 20 bits. Now 4 more bits are to be removed and used as a label type field for label types that we have no idea will ever be required? That seems wrong to me. With a 20 bit field, and a PRNG value in the field, then there's room for a million different flows, all passing through a router, and all being uniquely matched by just the flow label (with address verification later). My guess is that a million is already too small, but it is also most probably not so far away from what's needed as to be unusable (to use the million we'd need rather more flows than that, because we know we'll get collisions, which is what saves such a small number). Your proposal reduces that to 64K flows. That I know is way too small. If we revert the flow label field back to being strictly a flow identifier set by the source host to identify its flows, then we get a nice clean definition that can be used by anyone and everyone. That's what I'd like to see happen. 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 Sep 7 04:27:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87BRtIQ027214 for ; Fri, 7 Sep 2001 04:27:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87BRsUg027213 for ipng-dist; Fri, 7 Sep 2001 04:27: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87BRpIQ027206 for ; Fri, 7 Sep 2001 04:27:51 -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 EAA13856 for ; Fri, 7 Sep 2001 04:28:03 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03026 for ; Fri, 7 Sep 2001 05:28:39 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f87BKXx07379; Fri, 7 Sep 2001 04:20:33 -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 ABI43755; Fri, 7 Sep 2001 04:20:27 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id EAA24950; Fri, 7 Sep 2001 04:20:27 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15256.44411.396795.853220@thomasm-u1.cisco.com> Date: Fri, 7 Sep 2001 04:20:27 -0700 (PDT) To: Robert Elz Cc: "Christian Huitema" , "ipng" Subject: Re: refocusing: what about the flow label? In-Reply-To: <1249.999860351@brandenburg.cs.mu.OZ.AU> References: <1249.999860351@brandenburg.cs.mu.OZ.AU> 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 Robert Elz writes: > That seems wrong to me. With a 20 bit field, and a PRNG value in the > field, then there's room for a million different flows, all passing through > a router, and all being uniquely matched by just the flow label (with > address verification later). My guess is that a million is already too > small, but it is also most probably not so far away from what's needed > as to be unusable (to use the million we'd need rather more flows than > that, because we know we'll get collisions, which is what saves such a > small number). > > Your proposal reduces that to 64K flows. That I know is way too small. Er, the flow key is src/dst/flowlabel, right? That means it's 64k per host pair which seems like plenty. 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 Fri Sep 7 04:45:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87BjjIQ027233 for ; Fri, 7 Sep 2001 04:45:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87BjjrN027232 for ipng-dist; Fri, 7 Sep 2001 04:45: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87BjfIQ027225 for ; Fri, 7 Sep 2001 04:45:42 -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 EAA08874 for ; Fri, 7 Sep 2001 04:45:54 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08877 for ; Fri, 7 Sep 2001 05:46:20 -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 f87BiIE01290; Fri, 7 Sep 2001 18:44:18 +0700 (ICT) From: Robert Elz To: Alex Conta cc: ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B982483.CA4F4972@txc.com> References: <3B982483.CA4F4972@txc.com> <3B9709C6.AD921F86@txc.com> <3B97095F.F790D3EA@txc.com> <3B953AC9.D2113B27@txc.com> <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <1450.999682051@brandenburg.cs.mu.OZ.AU> <2295.999759600@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Sep 2001 18:44:18 +0700 Message-ID: <1288.999863058@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 06 Sep 2001 21:36:03 -0400 From: Alex Conta Message-ID: <3B982483.CA4F4972@txc.com> | > | Our proposal needs more work, we knew that -- to have both Intserv, | > | and Diffserv work with the same label, Brian and I acknowledged that. | The above "the same label" was meant "the same label space". Then that's not good enough - they need to be able both work on the exact same label. | As a further clarification, it means to work on removing a static | separation of the flow label space. Since Christian has just proposed a compromise, which would embed that static separation, that's nice to hear... A unified space is all that I think is reasonable. | Your statements suggest that any specification of the use of the flow | label with Diffserv must work with the use of the flow label by Intserv, | and any other possible schemes to be invented... Intserv is irrelevant to me ... I'd characterise my statements as more along the lines of expecting that any proposed used of the flow label be able to use it as it is defined. If one user can adapt to the definition that exists, and another cannot, well, then one is going to have a seeming advantage over the other. Live with it. | In principle, and I said this before with other words, I do not have | trouble with a standard in which both Intserv and Diffserv can share the | same label space, and therefore the same label. It is no good to just share the label space, to be effective, they both need to be able to use the same precise label (as one packet can only carry one label, and it can pass through both diffserv and intserv sections of the net - and perhaps others yet to be invented). | But I should say that I am troubled, if the standard is not applied | fairly, and equally on both sides. Wah - mummy - its not fair, he has pink icecream, I want pink icecream too!!! You're allergic to strawberries, they make you itch, and you don't like it. I don't care, it's not fair, I want pink icecream too!!! A fine argument from a 4 year old... | Your statements above, and implicitly anything supporting them, I am | afraid, create a double standard, don't you think? No. | One, in which it is OK that the specification of the use of the flow | label with Intserv, in Appendix A of RFC 2460, which, by requesting | the use of a Pseudo-Random Number, excludes currently the use of the | flow label by Diffserv, which back in 94-95, 97-98, was "a possible | scheme that could be invented in the future". The flow label identifies flows, it should be doing no more than that. A PRNG is just fine for that. Anyone is free to make use of that identification for any purpose they can dream up. Changing it however is an entirely different thing. No double standards at all. | According to the proposal, there is a separation of label space. That | ensures that the use of the flow label with Intserv, and Diffserv do not | intersect, For me, that isn't good enough. These aren't different choices, in which you pick whichever one you like, and use the label that suits. Rather, you have to use the one that is used to actually classify the packets, except there isn't just one - there can be many, so they all need to work together. | > As I understand intserv (which isn't a lot, nor diffserv), a static | > value isn't very useful. | | Why not? I explained that off list. | > As I understand it, and do correct me if I'm wrong - that's not really | > needed. | I correct you. Again, off list, in an earlier reply, I explained why... | But please do not misunderstand me, | if it is a good approach, please write it up. Unfortunately, at the minute, I don't have time, I have other things to do that are more urgent. Further, it isn't for me to define how diffserv (or intserv, or anyone else) should do their thing - I just threw out a suggestion that I think would work just fine. Again, off list, I have tried to explain to you just how. | I thought that as a Hop-by-Hop header option, only for Diffserv, it is | not going to provide the same efficiency as the flow label, Close enough, it is. | a fixed size field at a fixed offset in the main header, That one it also is, absolutely. | and the advantage of using the classification engine That one might take a little extra work, if it is appropriate at all. I'm not the one to answer - the problem would be more or less that the bits would come from two different places in the packet, one if you're doing diffserv, a different one for intserv. Whether that's a really difficult problem to handle (in silicon, it is trivial in software) I'll leave for someone else to answer. | for both Intserv and Diffserv. I replied to you in more detail, with my | observations, in a private message. Yes, I replied... | Even though we knew it does not really matter whether the flow label | value is PRN or not, it is exactly why Brian and I put out a proposal | that would not change the PRN rule for the Intserv use of flow label -- | the proposal of a static separation of the flow label space. I'm not sure if I'm not being clear, or if you're just ignoring the requests - Brian clearly understands what I am asking, and why. Static separation isn't the answer to anything - that is the problem that I am trying to avoid - the precise problem, almost the only problem. 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 Sep 7 07:02:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87E22IQ027331 for ; Fri, 7 Sep 2001 07:02:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87E22Gt027330 for ipng-dist; Fri, 7 Sep 2001 07:02:02 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87E1vIQ027323 for ; Fri, 7 Sep 2001 07:01:58 -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 HAA27004 for ; Fri, 7 Sep 2001 07:02:11 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28294 for ; Fri, 7 Sep 2001 07:02:00 -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 f87CcIE01645; Fri, 7 Sep 2001 19:39:39 +0700 (ICT) From: Robert Elz To: Michael Thomas cc: "Christian Huitema" , "ipng" Subject: Re: refocusing: what about the flow label? In-Reply-To: <15256.44411.396795.853220@thomasm-u1.cisco.com> References: <15256.44411.396795.853220@thomasm-u1.cisco.com> <1249.999860351@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Sep 2001 19:38:18 +0700 Message-ID: <1643.999866298@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 7 Sep 2001 04:20:27 -0700 (PDT) From: Michael Thomas Message-ID: <15256.44411.396795.853220@thomasm-u1.cisco.com> | Er, the flow key is src/dst/flowlabel, right? That means it's | 64k per host pair which seems like plenty. Sure, as far as identifying the flow is concerned. I guess I was thinking more of a usage model .. that is, src/dst/flowlabel is 272 bits (16 bit label), that's a hell of a huge database lookup key - to actually be used, (as a hash table lookup key for example) it needs to be reduced to some reasonable size. Doing that the "normal way" (value modulo some prime) seems like it would be a much too expensive operation to contemplate. Doing it by calculating some kind of CRC of the 272 bits, then using however many bits of that would be better, but still not blindingly cheap. What's left is the "use N of the M bits, ignore the rest" (where "ignore" doesn't mean we don't compare them with the result of the has lookup). If we do that, then which N? Clearly if the flow label is a PRNG, those bits, or as many of them as are needed, would be a good choice. If there are insufficient of those bits (and I suspect 16 isn't enough) then more bits are needed. Some kind of guessing game could be done with picking extra bits out of the addresses (xoring the two, ...) but those bits, while often seemingly random, aren't - and they're clearly not going to be as good as having more PRNG bits would be. That's what I was getting at. 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 Sep 7 07:08:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87E7xIQ027350 for ; Fri, 7 Sep 2001 07:07:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87E7wrB027349 for ipng-dist; Fri, 7 Sep 2001 07:07:58 -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.201.15]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87E7mIQ027342 for ; Fri, 7 Sep 2001 07:07:52 -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 f87E7vN14827; Fri, 7 Sep 2001 16:07:57 +0200 (MET DST) Date: Fri, 7 Sep 2001 16:04:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: a doubt on MTU discovery in IPv6 To: Emmanuel Varagnat-AEV010 Cc: Pekka Savola , Srinivasa Rao Nalluri , IPng In-Reply-To: "Your message with ID" <3B963C50.4364FF35@crm.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This makes me think about something strange in Path MTU Discovery. > > A note in the section 4 of Path MTU Discovery for IPv6 (RFC1981) say: > "A node may receive a Packet Too Big message reporting a > next-hop MTU that is less than the IPv6 minimum link MTU. In that > case, the node is not required to reduce the size of subsequent > packets sent on the path to less than the IPv6 minimun link MTU, > but rather must include a Fragment header in those packets [IPv6- > SPEC]." > > Does this can cause problems with the IPv6 standard that specify that > under 1280 octets, the layer below IPv6 must deal with the > fragmentation ? That language, and similar language in RFC 2460 is present to handle IPv4<->IPv6 packet translators such as those defined in RFC 2765 and RFC 2766. Hopefully an update to RFC 1981 (when moving to draft standard) can add a reference to those RFCs to help explain the intended use. 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 Sep 7 08:20:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FK6IQ027613 for ; Fri, 7 Sep 2001 08:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87FK5s3027612 for ipng-dist; Fri, 7 Sep 2001 08:20:05 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FK2IQ027605 for ; Fri, 7 Sep 2001 08:20:02 -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 IAA14947 for ; Fri, 7 Sep 2001 08:20:15 -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 IAA01534 for ; Fri, 7 Sep 2001 08:20:14 -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 f87FCqp16118; Fri, 7 Sep 2001 08:12:52 -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 ABI46012; Fri, 7 Sep 2001 08:12:40 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA24965; Fri, 7 Sep 2001 08:12:40 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15256.58344.122643.585822@thomasm-u1.cisco.com> Date: Fri, 7 Sep 2001 08:12:40 -0700 (PDT) To: Robert Elz Cc: Michael Thomas , "Christian Huitema" , "ipng" Subject: Re: refocusing: what about the flow label? In-Reply-To: <1643.999866298@brandenburg.cs.mu.OZ.AU> References: <15256.44411.396795.853220@thomasm-u1.cisco.com> <1249.999860351@brandenburg.cs.mu.OZ.AU> <1643.999866298@brandenburg.cs.mu.OZ.AU> 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 Robert Elz writes: > From: Michael Thomas > > | Er, the flow key is src/dst/flowlabel, right? That means it's > | 64k per host pair which seems like plenty. > > Sure, as far as identifying the flow is concerned. I guess I was thinking > more of a usage model .. that is, src/dst/flowlabel is 272 bits (16 bit > label), that's a hell of a huge database lookup key - to actually be used, > (as a hash table lookup key for example) it needs to be reduced to some > reasonable size. Considering that the normal 5 tuple is 288 bits, I think the size of the flow key is already factored in with the rest of the protocol. Admittedly this causes a lot of hardware designers waking apnea, but having another wide key to deal with isn't nearly as bad as having to deal with the first. > Doing that the "normal way" (value modulo some prime) seems like it would be > a much too expensive operation to contemplate. Doing it by calculating some > kind of CRC of the 272 bits, then using however many bits of that would be > better, but still not blindingly cheap. Associative memory is your friend :-) 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 Fri Sep 7 08:30:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FU3IQ027656 for ; Fri, 7 Sep 2001 08:30:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87FU3Nb027655 for ipng-dist; Fri, 7 Sep 2001 08:30: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FU0IQ027648 for ; Fri, 7 Sep 2001 08:30: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 IAA17991 for ; Fri, 7 Sep 2001 08:30:13 -0700 (PDT) Received: from mail.internet2.edu (mail.internet2.edu [209.211.239.218]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12154 for ; Fri, 7 Sep 2001 08:30:11 -0700 (PDT) Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.11.1/8.11.1/Debian 8.11.0-6) with ESMTP id f87FUAQ04168 for ; Fri, 7 Sep 2001 11:30:10 -0400 X-Authentication-Warning: mail.internet2.edu: Host localhost [127.0.0.1] claimed to be cain.internet2.edu Received: by cain.internet2.edu (Postfix, from userid 1000) id 63AC05B3; Fri, 7 Sep 2001 11:30:09 -0400 (EDT) To: ipng@sunroof.eng.sun.com Subject: Re: refocusing: what about the flow label? References: <1249.999860351@brandenburg.cs.mu.OZ.AU> From: stanislav shalunov Date: 07 Sep 2001 11:30:09 -0400 In-Reply-To: <1249.999860351@brandenburg.cs.mu.OZ.AU> Message-ID: <87vgivf27y.fsf@cain.internet2.edu> Lines: 27 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > With a 20 bit field, and a PRNG value in the field, then there's > room for a million different flows, all passing through a router, > and all being uniquely matched by just the flow label (with address > verification later). I'm not sure what do you mean by your parenthetical comment. If you are to match on source and destination later, you could as well include them in the key. They are either part of the key or not, "order" of matching bits in the key isn't the issue (you probably want to hash the whole key anyway). With 20 bits PRN as flow label, collisions will start occuring after roughly 1000 flows. That's obviously way too low a number. If you want to be able to identify flows by their labels you'd need many more bits for the label. What's the point, though? Why is matching on some bits (flow label) preferable to matching on other bits (addresses)? Is your concern to have a contiguous block of bits? (That shouldn't matter in ASICs, I suppose.) -- Stanislav Shalunov http://www.internet2.edu/~shalunov/ "Nuclear war can ruin your whole compile." -- Karl Lehenbauer -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 08:40:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87Fe1IQ027679 for ; Fri, 7 Sep 2001 08:40:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87Fe1nc027678 for ipng-dist; Fri, 7 Sep 2001 08:40: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FdvIQ027671 for ; Fri, 7 Sep 2001 08:39:57 -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 IAA14632 for ; Fri, 7 Sep 2001 08:40:10 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA17469 for ; Fri, 7 Sep 2001 08:40:07 -0700 (PDT) Received: from 157.54.9.100 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 08:38:56 -0700 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.2966); Fri, 7 Sep 2001 08:38:55 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:38:55 -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.2966); Fri, 7 Sep 2001 08:38:25 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: refocusing: what about the flow label? Date: Fri, 7 Sep 2001 08:38:24 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: refocusing: what about the flow label? Thread-Index: AcE3sIsMuFNPp5CMSD+EAONID1ZFGQAAVzVA From: "Christian Huitema" To: "Michael Thomas" , "Robert Elz" Cc: "ipng" X-OriginalArrivalTime: 07 Sep 2001 15:38:25.0074 (UTC) FILETIME=[21E9F920:01C137B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f87FdvIQ027672 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Doing that the "normal way" (value modulo some prime) seems like it > would be > > a much too expensive operation to contemplate. Doing it by > calculating some > > kind of CRC of the 272 bits, then using however many bits of that > would be > > better, but still not blindingly cheap. > > Associative memory is your friend :-) In fact, one of the points that were made clear in the debate is that the router manufacturers will never "just trust the host", i.e. just trust that the "flow label" is sufficiently random and sufficiently unique that they could use it without looking at the addresses. Then, even if the flow was unique, we should note that even 20 bits would be two small to be practical: the birthday paradox would kick in as soon as the router processes 1,024 flows, which is not a very large number; you would need some kind of tie-breaking logic, which means that you would have at a minimum to process the source address. So, it is much safer to assume that the primary classification will be based on the address pair, and that the label is just a differentiator for packets that carry the same address pair and require specific treatment; Mike points out one possible solution; there are certainly others; hashing 256 bits of source-destination should not require an inordinate number of gates in a VLSI. -- 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 Fri Sep 7 08:44:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FiwIQ027733 for ; Fri, 7 Sep 2001 08:44:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87Fiw04027732 for ipng-dist; Fri, 7 Sep 2001 08:44:58 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87FisIQ027725 for ; Fri, 7 Sep 2001 08:44:54 -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 IAA15807 for ; Fri, 7 Sep 2001 08:45:07 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA20008 for ; Fri, 7 Sep 2001 08:45:06 -0700 (PDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 08:44:52 -0700 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); Fri, 7 Sep 2001 08:44:51 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 08:44:50 -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.2966); Fri, 7 Sep 2001 08:44:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: refocusing: what about the flow label? Date: Fri, 7 Sep 2001 08:44:19 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: refocusing: what about the flow label? Thread-Index: AcE3c0l9rAf0TrwTQSKpMmlA+VmLxQAQAVmg From: "Christian Huitema" To: , , Cc: X-OriginalArrivalTime: 07 Sep 2001 15:44:19.0980 (UTC) FILETIME=[F57454C0:01C137B3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f87FisIQ027726 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > With the current flow label semantics the routers can avoid doing > intserv > state lookup if the flow label is null. If the flow label is used for > path > distribution, the router will be searching for the intserv state for > all the > packets (assuming the router does intserv at all). So from this > point-of-view it might be better to designate a separate label type > for > intserv? That should be a question for the Intserv WG. Either they can live with the default mechanism, or they expand the effort of specifying their own solution. I have no personal preference on this subject. > What I'm aiming at is to see if a classifying router (intserv, > diffserv, or other) could be ignorant of the different flow label > types when doing the lookup based on the 3-tuple of the source > address, destination address and the 20 bit flow label. That is indeed debatable. My proposal is to treat any non-understood label as if it had been null; an alternate proposal could be to treat any non-understood label as a basic label. Again, I don't have a strong preference, we just need to pick one specification. -- 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 Fri Sep 7 10:31:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87HVOIQ027918 for ; Fri, 7 Sep 2001 10:31:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87HVOYv027917 for ipng-dist; Fri, 7 Sep 2001 10:31:24 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87HVKIQ027910 for ; Fri, 7 Sep 2001 10:31:20 -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 KAA17619 for ; Fri, 7 Sep 2001 10:31:34 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24973 for ; Fri, 7 Sep 2001 10:31:33 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f87HUos25103; Fri, 7 Sep 2001 19:30:50 +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 TAA05922; Fri, 7 Sep 2001 19:30:51 +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 f87HUol24972; Fri, 7 Sep 2001 19:30:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109071730.f87HUol24972@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Alex Conta , ipng Subject: Re: a), b), c), d), or e) In-reply-to: Your message of Thu, 06 Sep 2001 10:57:33 PDT. <15255.47373.298798.299193@thomasm-u1.cisco.com> Date: Fri, 07 Sep 2001 19:30:50 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => I agree but where/how to fix this? I'm not sure there's anything to be fixed. This strikes me as the same sort of contradiction that NAT's impose on the network. This is a zero sum game; something loses. => I object: there is a real difference: today NATs are a fact, diffserv is not yet deployed: we have still time to stop this (optimistic point) but perhaps we have not the power to stop this (pessimistic point). Thanks 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 Fri Sep 7 11:07:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87I75IQ027965 for ; Fri, 7 Sep 2001 11:07:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87I75ug027964 for ipng-dist; Fri, 7 Sep 2001 11:07: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87I71IQ027957 for ; Fri, 7 Sep 2001 11:07:01 -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 LAA28900 for ; Fri, 7 Sep 2001 11:07:11 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09168 for ; Fri, 7 Sep 2001 11:07:10 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f87I7Cx23310; Fri, 7 Sep 2001 11:07:12 -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 ABI50880; Fri, 7 Sep 2001 11:07:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA24994; Fri, 7 Sep 2001 11:07:04 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15257.3272.692172.766610@thomasm-u1.cisco.com> Date: Fri, 7 Sep 2001 11:07:04 -0700 (PDT) To: Brian E Carpenter Cc: Michael Thomas , ipng Subject: Re: a), b), c), d), or e) In-Reply-To: <3B97C4C7.275EFE2B@hursley.ibm.com> References: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <3B953AC9.D2113B27@txc.com> <15254.32467.341293.958960@thomasm-u1.cisco.com> <3B97C4C7.275EFE2B@hursley.ibm.com> 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 Brian E Carpenter writes: > Indeed, it is clear that users who wish to be protected against > anthing beyond source/destination traffic analysis cannot use > the proposed flow-label diffserv mechanism. That's a user trade-off, > not a decision for the IETF to make. Moving the lose-lose situation to the user does not seem like a very useful recommendation. We shouldn't be in the business of letting end users decide which lossage due to bad architectural assumptions is better. Foisting the NAT hackitecture on the world was bad enough and is probably the single largest source of entropy we face; we shouldn't take this sort of thing lightly. Mike > > Brian > > Michael Thomas wrote: > > > > With Intserv-like networks, you don't ever need to > > reveal any L4+ headers. This is also true with > > diffserv networks if you don't require > > (re)classification, which is a perfectly > > reasonable way to design a diffserv network. > > > > This entire controversy surrounds whether diffserv > > networks which have interior routers do the > > classification is legitimate. Considering that it > > breaks a perfectly reasonable user desire -- > > privacy -- I'd say that's a pretty good reason > > to question the base premise. > > > > Mike > > > > Alex Conta writes: > > > > > > > > > Francis Dupont wrote: > > > > > > > > Alex, perhaps I was unfair about the c) option. > > > > > > You were Francis. > > > > > > > I understood that you'd like to replace the MF classifier on > > > > the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call > > > > the 5F classifier by a simpler MF classifier with the flow label > > > > in place of protocol and ports. This cancels the efficiency issue > > > > of the extension header chain of IPv6. > > > > > > > > My first concern is the 5F reclassification is a bad idea because > > > > an ACL-like classifier will never give what I want as an user. > > > > This is too rigid, not real-time, ... > > > > > > > > > > It may not give you what you want as a user, but it would give me > > > what "I" (read my customers) want as user(s). > > > > > > Remember, having a Intserv, and Diffserv use of the flow label gives > > > the user the option, and that is a good thing. > > > > > > > The second concern is with ESP: the 5F classifier wants to look at > > > > bits I want to hide. No conciliation is possible, IPsec people > > > > (like Michael) will *never* accept to reveal transport layer or > > > > payload details for a 5F classifier. [...] > > > > > > > > Francis > > > > > > Let's put religion aside. > > > > > > Conceptually, with IP QoS, infrastructure devices delivering packets to > > > destination, are processing forwarding and QoS information. > > > > > > As traffic between two end-nodes may have distinct QoS requirements, it > > > is obvious that the information to be given to an infrastructure device > > > must provide the differentiation of the traffic between the two > > > end-nodes. > > > That information, by definition, is in some relationship with the > > > multiplexing > > > of the communication between the two end-nodes, which is being realized > > > through the > > > transport (host-to-host) header information. At an extreme, that > > > information is the > > > transport protocol and source and destination ports, themselves. > > > > > > Since, with IP QoS, the QoS information is in the same class, relative > > > to privacy, > > > with the forwarding information, if one needs to apply full privacy to > > > QoS information, > > > it will apply the same criteria as for forwarding information: use > > > tunnel ESP. > > > > > > Regards, > > > 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 > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment for IBM at http://www.iCAIR.org > Board Chairman, Internet Society http://www.isoc.org > > "We shall need a number of efficient librarian types > to keep us in order." - Alan Turing, 1947. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 7 11:11:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87IBPIQ027982 for ; Fri, 7 Sep 2001 11:11:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87IBOxA027981 for ipng-dist; Fri, 7 Sep 2001 11:11:24 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87IBLIQ027974 for ; Fri, 7 Sep 2001 11:11:21 -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 LAA00260 for ; Fri, 7 Sep 2001 11:11:35 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA23717 for ; Fri, 7 Sep 2001 12:12:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f87IBCs27023; Fri, 7 Sep 2001 20:11:12 +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 UAA06285; Fri, 7 Sep 2001 20:11:13 +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 f87IBCl25201; Fri, 7 Sep 2001 20:11:12 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109071811.f87IBCl25201@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Christian Huitema" cc: "Brian E Carpenter" , "Michael Thomas" , "ipng" Subject: Re: refocusing: what about the flow label? In-reply-to: Your message of Thu, 06 Sep 2001 15:34:14 PDT. Date: Fri, 07 Sep 2001 20:11:12 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If the label type is set to the basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label value. => even if the source is the best place to put a non-zero/non-default value I'd like to enable one of the first routers to set the flow label on the behalf of a dumb source. (PS: to change to basic type and null value is not enough because we need to catch the "on the behalf of the source" too). 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 Fri Sep 7 11:26:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87IQBIQ028028 for ; Fri, 7 Sep 2001 11:26:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87IQAG1028027 for ipng-dist; Fri, 7 Sep 2001 11:26:10 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87IQ6IQ028020 for ; Fri, 7 Sep 2001 11:26:06 -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 LAA04417 for ; Fri, 7 Sep 2001 11:26:18 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25979 for ; Fri, 7 Sep 2001 11:26:18 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f87IQMv09893; Fri, 7 Sep 2001 11:26:24 -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 ABI51607; Fri, 7 Sep 2001 11:26:00 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA24998; Fri, 7 Sep 2001 11:25:59 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15257.4407.766229.250442@thomasm-u1.cisco.com> Date: Fri, 7 Sep 2001 11:25:59 -0700 (PDT) To: Francis Dupont Cc: "Christian Huitema" , "Brian E Carpenter" , "Michael Thomas" , "ipng" Subject: Re: refocusing: what about the flow label? In-Reply-To: <200109071811.f87IBCl25201@givry.rennes.enst-bretagne.fr> References: <200109071811.f87IBCl25201@givry.rennes.enst-bretagne.fr> 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 Francis Dupont writes: > In your previous mail you wrote: > > If the label type is set to the basic type, IPv6 routers SHOULD NOT > rewrite or alter the flow label value. > > => even if the source is the best place to put a non-zero/non-default > value I'd like to enable one of the first routers to set the flow label > on the behalf of a dumb source. (PS: to change to basic type and null > value is not enough because we need to catch the "on the behalf of the > source" too). Slippery slope! Slippery slope! Most of the lossage floating around here is due to the network trying to be intelligent for dumb hosts. Long live the dumb network! 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 Fri Sep 7 11:52:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87IqoIQ028067 for ; Fri, 7 Sep 2001 11:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87IqoMi028066 for ipng-dist; Fri, 7 Sep 2001 11:52: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87IqkIQ028059 for ; Fri, 7 Sep 2001 11:52:47 -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 LAA11469; Fri, 7 Sep 2001 11:52:59 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00784; Fri, 7 Sep 2001 12:52:55 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA17532; Fri, 7 Sep 2001 19:52:56 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id TAA44872; Fri, 7 Sep 2001 19:52:55 +0100 Message-ID: <3B9916AD.11C4FDB1@hursley.ibm.com> Date: Fri, 07 Sep 2001 13:49:17 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Erik Nordmark CC: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I miswrote slightly - the fact is that an implementation has to first check if the address is any of the non-global-unicast cases, and that involves doing a sequence of matches which involve the bits Formerly Known as the Format Prefix (not just 3 of them of course). I think the new text makes this harder to understand. It doesn't change what implementors should do. Feel free to ignore my comment if nobody else has the same reaction. Brian Erik Nordmark wrote: > > > I also think that abolishing the term "format prefix" is obfuscation. The > > fact is that the leading bits of an address *are* a format prefix and > > implementors *will* look at those bits before processing an address. Why > > obscure that fact? > > Brian, > It is exactly this that we want to avoid - implementors thinking that they > need to inspect the first 3 bits of the addresses. > There is no need to do this and we need to reduce the probability that > implementors hard-code any knowledge of any leading 3 bit combinations > since it will make it harder to use the other 15/16th of the address space > in the future. > > 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 Sep 7 12:03:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87J3wIQ028146 for ; Fri, 7 Sep 2001 12:03:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87J3wGE028145 for ipng-dist; Fri, 7 Sep 2001 12:03: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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87J3sIQ028135 for ; Fri, 7 Sep 2001 12:03:54 -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 MAA15239 for ; Fri, 7 Sep 2001 12:04:06 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06368 for ; Fri, 7 Sep 2001 12:04:05 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA22924; Fri, 7 Sep 2001 20:04:02 +0100 Received: from hursley.ibm.com ([9.29.3.173]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA48004; Fri, 7 Sep 2001 20:04:01 +0100 Message-ID: <3B99193A.4511A37D@hursley.ibm.com> Date: Fri, 07 Sep 2001 14:00:10 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Christian Huitema CC: jarno.rajahalme@nokia.com, mat@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: refocusing: what about the flow label? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe Christian's proposal is quite viable. However I want to think a bit more about this, since there may actually be a solution much closer to "no change" - I just don't feel quite ready to write it down yet, but I suspect we can actually achieve the same effect without labels. One more comment below: Christian Huitema wrote: > > > With the current flow label semantics the routers can avoid doing > > intserv > > state lookup if the flow label is null. If the flow label is used for > > path > > distribution, the router will be searching for the intserv state for > > all the > > packets (assuming the router does intserv at all). So from this > > point-of-view it might be better to designate a separate label type > > for > > intserv? > > That should be a question for the Intserv WG. Either they can live with > the default mechanism, or they expand the effort of specifying their own > solution. I have no personal preference on this subject. > > > What I'm aiming at is to see if a classifying router (intserv, > > diffserv, or other) could be ignorant of the different flow label > > types when doing the lookup based on the 3-tuple of the source > > address, destination address and the 20 bit flow label. That depends quite critically on the extent to which the standard limits the semantics of the field. A classifier is a dumb animal driven by a simple configuration table; the real work is done after classification. So there is a good chance this condition can be met (with unrecognised labels reverting to default treatment, as Christian says). Brian > That is indeed debatable. My proposal is to treat any non-understood > label as if it had been null; an alternate proposal could be to treat > any non-understood label as a basic label. Again, I don't have a strong > preference, we just need to pick one specification. > > -- 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 Fri Sep 7 12:44:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87JibIQ028259 for ; Fri, 7 Sep 2001 12:44:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1/Submit) id f87Jia1n028258 for ipng-dist; Fri, 7 Sep 2001 12:44:36 -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.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87JiWIQ028251 for ; Fri, 7 Sep 2001 12:44:32 -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 MAA24301 for ; Fri, 7 Sep 2001 12:44:45 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA08962 for ; Fri, 7 Sep 2001 13:45:22 -0600 (MDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GJB009OJ5IJPC@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Fri, 07 Sep 2001 14:44:43 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f87Jigm23148; Fri, 07 Sep 2001 14:44:42 -0500 (CDT) Date: Fri, 07 Sep 2001 14:44:41 -0500 From: Matt Crawford Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-reply-to: "07 Sep 2001 13:49:17 CDT." <3B9916AD.11C4FDB1@hursley.ibm.com> To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Message-id: <200109071944.f87Jigm23148@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Feel free to ignore my comment if nobody else has the same reaction. I, for one, do not have the same reaction. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 05:26:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f89CQ549029906 for ; Sun, 9 Sep 2001 05:26:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f89CQ4bC029905 for ipng-dist; Sun, 9 Sep 2001 05:26: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+Sun/8.12.0) with ESMTP id f89CQ149029898 for ; Sun, 9 Sep 2001 05:26: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 FAA03540 for ; Sun, 9 Sep 2001 05:26:15 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29221 for ; Sun, 9 Sep 2001 05:26:09 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f89CPns12915; Sun, 9 Sep 2001 14:25:49 +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 OAA16346; Sun, 9 Sep 2001 14:25:49 +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 f89CPjl31896; Sun, 9 Sep 2001 14:25:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109091225.f89CPjl31896@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Routing Header Considered Harmful In-reply-to: Your message of Fri, 07 Sep 2001 10:48:12 +0300. Date: Sun, 09 Sep 2001 14:25:45 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => the problem is not node or host, it is with a requirement you can find > and I can't find. Not nearly all cases of the IPv6 specification use "must" clauses, even though they are clearly required. => no, nothing without a MUST is clearly required. If I apply your argument to RFC 791 IPv4 source route processing an forwarding is mandatory for IPv4 hosts. RFC 2460 defines the processing rule, it says *nothing* about any requirement for a node to forward a source routed packet. As I said, RFC 2460 is not a IPv6 node requirement document. > Only problem with this is that I fail to see how you _really_ could > identify mobile nodes? > > => I've suggested three different ways. Do you have more specific ideas how these could work? - Home address option: check if it exists (could be added by anyone, isn't enough) => I disagree, if you see an outgoing packet from C without home address H you can decide to accept incoming packet to C with a source route to H. - Binding updates (requires state) => I can't see a problem with state! - Explicit negotiation (requires state to be exported from AAA to firewall) => same. > Requiring state in the firewall for this is probably unacceptable. > > => yes, you need a statefull firewall but a stateless firewall is *not* > a real one, at least you may not say it is a good one (:-). Stateful firewall usually creates a SPOF, which may not be acceptable for multihoming solutions at least. => I am afraid that you have to accept a single-point-of-failure if you'd like to get a high level of security. Note that for AAA the state is not in the firewall, it is in the AAA system. > => no, the job of a router is to route There are different kinds of routers. I agree with you when "core" routers are concerned, but "access routers" e.g. of a small-midsize company (not necessaily even classical "router hardware router") must be able to perform these checks. => I believe a router is a bad firewall (and a firewall a bad router). I don't like the idea that everyone should get a big, expensive stateful firewall => you are not required to pay a lot of money to get a good software (:-). if all you want is basic security and stateless access-lists. => you can't both ask for good security and propose in order to archieve it basic security and known to be not enough tools. 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 Sep 9 07:08:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f89E8R49029988 for ; Sun, 9 Sep 2001 07:08:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f89E8RB1029987 for ipng-dist; Sun, 9 Sep 2001 07:08:27 -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+Sun/8.12.0) with ESMTP id f89E8I49029980 for ; Sun, 9 Sep 2001 07:08:18 -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 HAA03049 for ; Sun, 9 Sep 2001 07:08:31 -0700 (PDT) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15686 for ; Sun, 9 Sep 2001 07:08:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id XAA27191; Sun, 9 Sep 2001 23:09:56 +0900 To: ipng@sunroof.eng.sun.com, usagi-users@linux-ipv6.org, netdev@oss.sgi.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.hongo.wide.ad.jp/%7Eyoshfuji/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://cerberus.hongo.wide.ad.jp/%7Eyoshfuji/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20010909230956M.yoshfuji@linux-ipv6.org> Date: Sun, 09 Sep 2001 23:09:56 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 16 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Sun, 9 Sep 2001 15:55:21 +0300 (EEST)), Pekka Savola says: > There has not been an "official" statement on ipng IETF list on this, but > the general consensus seems to be that hosts should not forward > source-routed frames, at least by default. Who did say that it should be disabled by default? Consensus seems to be "hosts are expected to forward source-routed frames by default." ...or, do I misunderstand something? We need the conclusion of this discussion... -- yoshfuji -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 9 07:25:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f89EPv49000029 for ; Sun, 9 Sep 2001 07:25:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f89EPvg9000028 for ipng-dist; Sun, 9 Sep 2001 07:25:57 -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+Sun/8.12.0) with ESMTP id f89EPr49000021 for ; Sun, 9 Sep 2001 07:25:53 -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 HAA04771 for ; Sun, 9 Sep 2001 07:26:06 -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 IAA03904 for ; Sun, 9 Sep 2001 08:26:02 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f89EQ0Y26052; Sun, 9 Sep 2001 17:26:00 +0300 Date: Sun, 9 Sep 2001 17:26:00 +0300 (EEST) From: Pekka Savola To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= cc: , , Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <20010909230956M.yoshfuji@linux-ipv6.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 9 Sep 2001, YOSHIFUJI Hideaki / [iso-2022-jp] $B5HF#1QL@(B wrote: > In article (at Sun, 9 Sep 2001 15:55:21 +0300 (EEST)), Pekka Savola says: > > > There has not been an "official" statement on ipng IETF list on this, but > > the general consensus seems to be that hosts should not forward > > source-routed frames, at least by default. > > Who did say that it should be disabled by default? > Consensus seems to be "hosts are expected to forward source-routed > frames by default." > > ...or, do I misunderstand something? > > We need the conclusion of this discussion... I think it was quite widely accepted (at least nobody objected, thus I said "consensus") that _hosts_, at least by default, should not forward source-routed packets. "local source-routing" from IPv4 context (same incoming/outgoing interface) was also mentioned w.r.t. host behaviour. There were ... arguments back and forth whether forwarding source-routed packets by default is safe (enough) for routers. -- 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 Sep 10 06:28:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ADS249001317 for ; Mon, 10 Sep 2001 06:28:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8ADS2sr001316 for ipng-dist; Mon, 10 Sep 2001 06: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ADRv49001309 for ; Mon, 10 Sep 2001 06:27:58 -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 GAA13722 for ; Mon, 10 Sep 2001 06:28:12 -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 HAA08441 for ; Mon, 10 Sep 2001 07:27:49 -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 WAA23725; Mon, 10 Sep 2001 22:26:40 +0900 (JST) Date: Mon, 10 Sep 2001 22:26:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: narten@raleigh.ibm.com, richdr@microsoft.com Cc: ipng@sunroof.eng.sun.com Subject: comments about temp-addresses-v2-00 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: 74 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've implemented draft-ietf-ipngwg-temp-addresses-v2-00.txt and have a couple of comments: In section 3.3. Generating Temporary Addresses 1) Process the Prefix Information Option as defined in [ADDRCONF], either creating a public address or adjusting the lifetimes of existing addresses, both public and temporary. When adjusting the lifetime of an existing temporary address, there are two cases to consider: (snip) b) In many cases, the lifetime in a received option will extend the lifetime of a public address. For example, a site might advertise short lifetimes (on the order of hours or minutes) that are effectively extended with each new RA. In such cases, the lifetimes of temporary addresses should be extended, subject to the overall constraint that no temporary addresses should ever remain "valid" or "preferred" for a time longer than (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^I think this should be just "TEMP_VALID_LIFETIME", because there is no timing issue for regeneration on valid lifetimes. (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The configuration variables TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to approximate target lifetimes for temporary addresses. In section 3.2.1, 4) Compare the generated identifier against a list of known values that should not be used. Inappropriate values include those used in reserved anycast addresses [RFC 2526], those used by ISATAP [ISATAP], the value 0, and those already assigned to an address on the local device. ... I'm not sure what "the local device" exactly means. Is it the "interface" on which a new identifier are being generated, or is it the "whole node"? Our current implementation takes the latter interpretation. In any case, probably due to this addition, Step 4) in section 3.3 was simplified: 4) New temporary addresses are created by appending the interface's current randomized interface identifier to the prefix that was used to generate the corresponding public address. than the one in RFC3041: 4) New temporary addresses are created by appending the interface's current randomized interface identifier to the prefix that was used to generate the corresponding public address. If by chance the new temporary address is the same as an address already assigned to the interface, generate a new randomized interface identifier and repeat this step. That is, the duplication check was omitted. But, technically, this cannot be omitted, because there is a time-lag between the generation of interface identifiers and the generation of actual temporary addresses. If the draft regards this time-lag as practically negligible, I think it's okay. But IMH it should mention the issue anyway. Our current implementation checks the duplication at the generation of actual addresses as well as at the generation of interface identifiers. 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 Sep 10 10:38:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8AHcB49002006 for ; Mon, 10 Sep 2001 10:38:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8AHcAZi002005 for ipng-dist; Mon, 10 Sep 2001 10:38:10 -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+Sun/8.12.0) with ESMTP id f8AHc649001998 for ; Mon, 10 Sep 2001 10:38:07 -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 KAA18356 for ; Mon, 10 Sep 2001 10:38:21 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA15575 for ; Mon, 10 Sep 2001 10:38:18 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Sep 2001 10:36:53 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 10:36:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? Date: Mon, 10 Sep 2001 10:36:46 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF92B@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (usagi-users 00767) Re: source routing honored by hosts? Thread-Index: AcE5PMD4q7zP/tzSQJGzVcQRgE0MDAA4ecrQ From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 10 Sep 2001 17:36:46.0635 (UTC) FILETIME=[2A036FB0:01C13A1F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8AHc749001999 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think it was quite widely accepted (at least nobody > objected, thus I said "consensus") that _hosts_, at least by > default, should not forward source-routed packets. My understanding of RFC 2460 is that all nodes, meaning both hosts and routers, should process Routing Headers. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 11:20:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8AIKq49002109 for ; Mon, 10 Sep 2001 11:20:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8AIKqOJ002108 for ipng-dist; Mon, 10 Sep 2001 11:20: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+Sun/8.12.0) with ESMTP id f8AIKm49002101 for ; Mon, 10 Sep 2001 11:20:49 -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 LAA22882 for ; Mon, 10 Sep 2001 11:21:02 -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 MAA27751 for ; Mon, 10 Sep 2001 12:21:39 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8AIJuJ03066; Mon, 10 Sep 2001 21:19:56 +0300 Date: Mon, 10 Sep 2001 21:19:56 +0300 (EEST) From: Pekka Savola To: Richard Draves cc: Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8024EF92B@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 10 Sep 2001, Richard Draves wrote: > > I think it was quite widely accepted (at least nobody > > objected, thus I said "consensus") that _hosts_, at least by > > default, should not forward source-routed packets. > > My understanding of RFC 2460 is that all nodes, meaning both hosts and > routers, should process Routing Headers. It is mine as well, but that still doesn't make it sane or safe behaviour; which is why I was gauging opinions on 1) how you interpret RFC2460 and 2) how you should implement RFC2460 wrt. routing headers. -- 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 Sep 10 13:38:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8AKc949002439 for ; Mon, 10 Sep 2001 13:38:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8AKc9SK002438 for ipng-dist; Mon, 10 Sep 2001 13:38: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+Sun/8.12.0) with ESMTP id f8AKc549002431 for ; Mon, 10 Sep 2001 13:38: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 NAA10301 for ; Mon, 10 Sep 2001 13:38:20 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09734 for ; Mon, 10 Sep 2001 14:39:01 -0600 (MDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 5AFA9786B; Mon, 10 Sep 2001 16:38:19 -0400 (EDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 17EA2AE2E for ; Mon, 10 Sep 2001 16:38:19 -0400 (EDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id AC0D8B8B; Mon, 10 Sep 2001 15:38:18 -0500 (CDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 6513BAE2 for ; Mon, 10 Sep 2001 15:38:18 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id QAA0000029164; Mon, 10 Sep 2001 16:38:17 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id QAA0000005656; Mon, 10 Sep 2001 16:38:16 -0400 (EDT) Message-ID: <3B9D24B8.5C1ECC9C@zk3.dec.com> Date: Mon, 10 Sep 2001 16:38:16 -0400 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: IPNG Working Group Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The aproach that we have taken is to introduce a tuning knob for for forwarding traffic that's addressed to us, such as traffic with routing headers. All nodes process the routing header, but the traffic is not forwarded unless the forwarding feature is enabled. The feature is off by default in hosts and on by default in routers, so I wouldn't really have a problem with specifiying this in a document. -vlad Pekka Savola wrote: > > On Mon, 10 Sep 2001, Richard Draves wrote: > > > I think it was quite widely accepted (at least nobody > > > objected, thus I said "consensus") that _hosts_, at least by > > > default, should not forward source-routed packets. > > > > My understanding of RFC 2460 is that all nodes, meaning both hosts and > > routers, should process Routing Headers. > > It is mine as well, but that still doesn't make it sane or safe behaviour; > which is why I was gauging opinions on 1) how you interpret RFC2460 and 2) > how you should implement RFC2460 wrt. routing headers. > > -- > 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 > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Mon Sep 10 16:36:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ANaL49002656 for ; Mon, 10 Sep 2001 16:36:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8ANaLl6002655 for ipng-dist; Mon, 10 Sep 2001 16:36: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+Sun/8.12.0) with ESMTP id f8ANaH49002648 for ; Mon, 10 Sep 2001 16:36:17 -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 QAA15798 for ; Mon, 10 Sep 2001 16:36:31 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13247 for ; Mon, 10 Sep 2001 17:37:12 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8ANaVx28758; Mon, 10 Sep 2001 16:36:31 -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 ABQ04619; Mon, 10 Sep 2001 16:36:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA26460; Mon, 10 Sep 2001 16:36:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15261.20087.261742.501590@thomasm-u1.cisco.com> Date: Mon, 10 Sep 2001 16:36:23 -0700 (PDT) To: "Richard Draves" Cc: "Pekka Savola" , Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA8024EF92B@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA8024EF92B@red-msg-06.redmond.corp.microsoft.com> 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 Richard Draves writes: > > I think it was quite widely accepted (at least nobody > > objected, thus I said "consensus") that _hosts_, at least by > > default, should not forward source-routed packets. > > My understanding of RFC 2460 is that all nodes, meaning both hosts and > routers, should process Routing Headers. So, like, that means that I can turn any host on the net into a router, assuming I supply the route? Groovy. 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 Sep 10 23:07:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8B67X49003014 for ; Mon, 10 Sep 2001 23:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8B67XV6003013 for ipng-dist; Mon, 10 Sep 2001 23:07: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+Sun/8.12.0) with ESMTP id f8B67T49003006 for ; Mon, 10 Sep 2001 23:07:29 -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 XAA22782 for ; Mon, 10 Sep 2001 23:07:45 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA22220 for ; Tue, 11 Sep 2001 00:07:40 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Sep 2001 23:06:40 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Sep 2001 23:06:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Date: Mon, 10 Sep 2001 23:06:40 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCA9@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt Thread-Index: AcE3ctdQUzYZ7WUjQASNri/FKSLJhADFH9wA From: "Richard Draves" To: "Erik Nordmark" Cc: "Stig Venaas" , X-OriginalArrivalTime: 11 Sep 2001 06:06:40.0629 (UTC) FILETIME=[EC861250:01C13A87] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8B67T49003007 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Perhaps it would be best to just remove the "no route" clause from > > Rule 1, and say that a destination D is considered unusable if > > Source(D) is undefined or if the next-hop neighbor for D is > known to > > be unreachable. > > The problem with "known to be unreachable" is that it is a > very transient condition as RFC 2461 is done. At least the > way I read 2461 when NUD declares that a neighbor is > unreachable it goes ahead and redoes next hop determination > etc but it doesn't retain any state about the node being > unreachable - instead it effectively forgets this knowledge. > > Thus declaring to be unreachable is an event and not a state. > So I don't see what you can check - the fact that the event > ocurred in the last millisecond? I think whether this state is retained after NUD decides that a neighbor is unreachable is implementation dependent. I had in mind other ways that an implementation might know that the neighbor is unreachable. For example if the interface is currently unplugged from the link on which the neighbor resides, the neighbor is unreachable. Basically by saying "known to be unreachable" without being more specific I'm trying to give implementations some flexibility. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 01:54:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8B8s149003140 for ; Tue, 11 Sep 2001 01:54:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8B8s14k003139 for ipng-dist; Tue, 11 Sep 2001 01:54: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+Sun/8.12.0) with ESMTP id f8B8rv49003132 for ; Tue, 11 Sep 2001 01:53:57 -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 BAA22759 for ; Tue, 11 Sep 2001 01:54:12 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18201 for ; Tue, 11 Sep 2001 01:54:11 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f8B8ros16998; Tue, 11 Sep 2001 10:53:50 +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 KAA14844; Tue, 11 Sep 2001 10:53: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 f8B8rol39509; Tue, 11 Sep 2001 10:53:50 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109110853.f8B8rol39509@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" cc: "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-reply-to: Your message of Mon, 10 Sep 2001 10:36:46 PDT. <7695E2F6903F7A41961F8CF888D87EA8024EF92B@red-msg-06.redmond.corp.microsoft.com> Date: Tue, 11 Sep 2001 10:53:49 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I think it was quite widely accepted (at least nobody > objected, thus I said "consensus") that _hosts_, at least by > default, should not forward source-routed packets. My understanding of RFC 2460 is that all nodes, meaning both hosts and routers, should process Routing Headers. => two points: - should process is too strong, my feeling is "should implement the processing of Routing Headers" - to process and to forward are two different things (forward is stronger). IMHO the default policy for hosts should be process but not forward. Thanks 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 Sep 11 09:28:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8BGSx49003694 for ; Tue, 11 Sep 2001 09:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8BGSwx8003693 for ipng-dist; Tue, 11 Sep 2001 09:28:58 -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+Sun/8.12.0) with ESMTP id f8BGSt49003686 for ; Tue, 11 Sep 2001 09:28:55 -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 JAA17080 for ; Tue, 11 Sep 2001 09:29:13 -0700 (PDT) Received: from gw.osaru.yi.org (fw134121.kitanet.ne.jp [210.237.134.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08410 for ; Tue, 11 Sep 2001 10:29:08 -0600 (MDT) Received: from [::1] (helo=dom.osaru.yi.org) by gw.osaru.yi.org with esmtp (Exim 3.12 #2) id 15gqCB-0003ua-00; Wed, 12 Sep 2001 01:15:31 +0900 Date: Wed, 12 Sep 2001 01:15:08 +0900 Message-ID: From: KANDA Mitsuru / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= To: Francis Dupont Cc: "Richard Draves" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <200109110853.f8B8rol39509@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.0 (Twist And Shout) Emacs/20.7 Mule/4.1 (AOI) References: <200109110853.f8B8rol39509@givry.rennes.enst-bretagne.fr> X-GnuPG-fingerprint: 9A35 D378 F084 9EA4 EFBA 925B 1C93 B376 F0EF BE59 X-URL: http://www.osaru.yi.org/~mk/ X-My-AutoMobile: M2-1001 chassis#030 X-Using-IP-Version: IP version 6 MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, At Tue, 11 Sep 2001 10:53:49 +0200, Francis Dupont wrote: > > In your previous mail you wrote: > > > I think it was quite widely accepted (at least nobody > > objected, thus I said "consensus") that _hosts_, at least by > > default, should not forward source-routed packets. > > My understanding of RFC 2460 is that all nodes, meaning both hosts and > routers, should process Routing Headers. > > => two points: > - should process is too strong, my feeling is "should implement the > processing of Routing Headers" > - to process and to forward are two different things (forward is stronger). > IMHO the default policy for hosts should be process but not forward. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do you mean as follows: Hosts know this extention header is Routing Header, but do nothing (just discard). regards, -mk -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 10:55:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8BHtN49003758 for ; Tue, 11 Sep 2001 10:55:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8BHtNKJ003757 for ipng-dist; Tue, 11 Sep 2001 10:55:23 -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+Sun/8.12.0) with ESMTP id f8BHtH49003750 for ; Tue, 11 Sep 2001 10:55: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 KAA26480 for ; Tue, 11 Sep 2001 10:55:36 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13267 for ; Tue, 11 Sep 2001 10:55:36 -0700 (PDT) Received: by zcamail05.zca.compaq.com (Postfix, from userid 12345) id BB049728B; Tue, 11 Sep 2001 10:59:52 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 8FDD37134; Tue, 11 Sep 2001 10:59:52 -0700 (PDT) Received: by taynzmail03.nz-tay.cpqcorp.net (Postfix, from userid 12345) id 215D71634; Tue, 11 Sep 2001 13:55:26 -0400 (EDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 0FBD71611; Tue, 11 Sep 2001 13:55:26 -0400 (EDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000017397; Tue, 11 Sep 2001 13:55:25 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id NAA0000006580; Tue, 11 Sep 2001 13:55:23 -0400 (EDT) Message-ID: <3B9E500A.B1A4F772@zk3.dec.com> Date: Tue, 11 Sep 2001 13:55:22 -0400 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: kanda@nn.iij4u.or.jp Cc: ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? References: <200109110853.f8B8rol39509@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think what Francis means is that all nodes should know how to process the routing header. That is, they know the header type and they layout of the header. That does not mean that they should process the header whenever they see it. Processing the header would imply verifying the contents and forwarding if necessary. Some implementations took a really simplistic approach and process routing header every time including forwarding. This is what started the whole thread. Other implementations took a safer approach an decided that processing or forwarding is not appropriate under some circumstances (like when the node is configured as a host). So as you can see, this whole thread simply a different interpretation of the specs. It would nice if this issue would be clarified in some document, but I can live without it. -vlad Forwarding is a different issue. KANDA Mitsuru / $B?@ED(B $B=<(B wrote: > > Hello, > > At Tue, 11 Sep 2001 10:53:49 +0200, > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > > > I think it was quite widely accepted (at least nobody > > > objected, thus I said "consensus") that _hosts_, at least by > > > default, should not forward source-routed packets. > > > > My understanding of RFC 2460 is that all nodes, meaning both hosts and > > routers, should process Routing Headers. > > > > => two points: > > - should process is too strong, my feeling is "should implement the > > processing of Routing Headers" > > - to process and to forward are two different things (forward is stronger). > > IMHO the default policy for hosts should be process but not forward. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Do you mean as follows: > > Hosts know this extention header is Routing Header, but do nothing (just discard). > > regards, > -mk > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Sep 11 12:33:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8BJXW49003889 for ; Tue, 11 Sep 2001 12:33:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8BJXW8B003888 for ipng-dist; Tue, 11 Sep 2001 12:33:32 -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+Sun/8.12.0) with ESMTP id f8BJXS49003881 for ; Tue, 11 Sep 2001 12:33:28 -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 MAA24926 for ; Tue, 11 Sep 2001 12:33:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11213 for ; Tue, 11 Sep 2001 13:33:32 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA34776; Tue, 11 Sep 2001 20:33:28 +0100 Received: from hursley.ibm.com ([9.45.189.125]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA69336; Tue, 11 Sep 2001 20:33:29 +0100 Message-ID: <3B9E667C.E49B4E84@hursley.ibm.com> Date: Tue, 11 Sep 2001 14:31:08 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: ipng Subject: Re: a), b), c), d), or e) References: <200109011722.f81HM7l99552@givry.rennes.enst-bretagne.fr> <3B953AC9.D2113B27@txc.com> <15254.32467.341293.958960@thomasm-u1.cisco.com> <3B97C4C7.275EFE2B@hursley.ibm.com> <15257.3272.692172.766610@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > > Brian E Carpenter writes: > > Indeed, it is clear that users who wish to be protected against > > anthing beyond source/destination traffic analysis cannot use > > the proposed flow-label diffserv mechanism. That's a user trade-off, > > not a decision for the IETF to make. > > Moving the lose-lose situation to the user does > not seem like a very useful recommendation. We > shouldn't be in the business of letting end users > decide which lossage due to bad architectural > assumptions is better. Foisting the NAT > hackitecture on the world was bad enough and > is probably the single largest source of > entropy we face; we shouldn't take this sort > of thing lightly. I don't take it lightly, but many users simply don't care about traffic analysis risks and there is no argument for penalising them; the users who do care will *inevitably* lose something in exchange for hiding their traffic type; that is truly a zero-sum game. 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 Sep 11 12:42:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8BJgl49003917 for ; Tue, 11 Sep 2001 12:42:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8BJglYp003916 for ipng-dist; Tue, 11 Sep 2001 12:42:47 -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+Sun/8.12.0) with ESMTP id f8BJgi49003909 for ; Tue, 11 Sep 2001 12:42:44 -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 MAA29764 for ; Tue, 11 Sep 2001 12:43:02 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16594 for ; Tue, 11 Sep 2001 13:42:58 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA12102; Tue, 11 Sep 2001 20:42:59 +0100 Received: from hursley.ibm.com ([9.45.189.125]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id UAA39086; Tue, 11 Sep 2001 20:42:57 +0100 Message-ID: <3B9E68B4.F330870F@hursley.ibm.com> Date: Tue, 11 Sep 2001 14:40:36 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Michael Thomas CC: Francis Dupont , Christian Huitema , ipng Subject: Re: refocusing: what about the flow label? References: <200109071811.f87IBCl25201@givry.rennes.enst-bretagne.fr> <15257.4407.766229.250442@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > > Francis Dupont writes: > > In your previous mail you wrote: > > > > If the label type is set to the basic type, IPv6 routers SHOULD NOT > > rewrite or alter the flow label value. > > > > => even if the source is the best place to put a non-zero/non-default > > value I'd like to enable one of the first routers to set the flow label > > on the behalf of a dumb source. (PS: to change to basic type and null > > value is not enough because we need to catch the "on the behalf of the > > source" too). > > Slippery slope! Slippery slope! > > Most of the lossage floating around here is due to > the network trying to be intelligent for dumb hosts. > > Long live the dumb network! I agree. We were actually *forced* into allowing the network to rewrite the DSCP in the diffserv case, because of having to deal with a non-TOS-aware IPv4 legacy. And as Francis has so eloquently stated, having the network guess the correct value is not a clean solution - it's just the only one we have. If we can use the flow label at all, IMHO we should *not* cater for a non-flow-label-aware IPv6 legacy! 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 Sep 11 21:36:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8C4ab49004322 for ; Tue, 11 Sep 2001 21:36:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8C4abvU004321 for ipng-dist; Tue, 11 Sep 2001 21:36:37 -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+Sun/8.12.0) with ESMTP id f8C4aY49004314 for ; Tue, 11 Sep 2001 21:36:34 -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 VAA15056 for ; Tue, 11 Sep 2001 21:36:53 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10664 for ; Tue, 11 Sep 2001 21:36:52 -0700 (PDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id f8C4ak820556 for ; Wed, 12 Sep 2001 13:36:47 +0900 (KST) Message-ID: <001101c13b45$55d243b0$10e0d5a5@cychong> From: "Chae-yong Chong" To: Subject: Question about stateless address autoconfiguration Date: Wed, 12 Sep 2001 13:42:31 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f8C4aY49004315 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, all I get a question about IPv6 stateless address autoconfiguration. RFC2462 said that: 5.5.3 Router Advertisement Processing If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error in this case. It is the responsibility of the system administrator to insure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type. Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH]. Does that mean that MN could not generate its unique global unicast address unless a router advertise its prefix length as 64. What if a host attached to a link which is administered by a router which has non-64 bits long prefix? In this case the stateless address autoconfiguration is not applicable? I am not sure the stateless address autoconfiguration is only applied to the bottom subnet which prefix length is 64? I think this issue may be already resolved in this mailing list. But I can not find any information from IPv6 archive. Chae-yong -------------------------------------------- Samsung Electronics Co. Ltd E-mail : cychong@telecom.samsung.co.kr -------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 23:54:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8C6s049004439 for ; Tue, 11 Sep 2001 23:54:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8C6s0tD004438 for ipng-dist; Tue, 11 Sep 2001 23: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8C6ru49004431 for ; Tue, 11 Sep 2001 23:53:56 -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 XAA03572 for ; Tue, 11 Sep 2001 23:54:15 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16030 for ; Wed, 12 Sep 2001 00:54:10 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f8C6rLs31723; Wed, 12 Sep 2001 08:53:22 +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 IAA25583; Wed, 12 Sep 2001 08:53: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 f8C6rKl43026; Wed, 12 Sep 2001 08:53:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109120653.f8C6rKl43026@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: KANDA Mitsuru / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?= cc: "Richard Draves" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-reply-to: Your message of Wed, 12 Sep 2001 01:15:08 +0900. Date: Wed, 12 Sep 2001 08:53:20 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > IMHO the default policy for hosts should be process but not forward. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Do you mean as follows: Hosts know this extention header is Routing Header, but do nothing (just discard) => no, what I've meant is hosts process routing headers but don't forward it. There are many ways to program the routing header stuff (one is in RFC 2460), the important point is to block (if the knob is not explicitely set) the sending of source route packets by the forwarding routine. So if segment left is zero or if the next destination is the same host (*) the packet is accepted. I have no strong idea about error cases. Regards Francis.Dupont@enst-bretagne.fr PS: (*) is used by the routing optimization of mobile IPv6 and is easy to detect (just consider that special case is common :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 00:02:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8C72c49004485 for ; Wed, 12 Sep 2001 00:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8C72ckP004484 for ipng-dist; Wed, 12 Sep 2001 00:02:38 -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+Sun/8.12.0) with ESMTP id f8C72Y49004477 for ; Wed, 12 Sep 2001 00:02: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 AAA17261 for ; Wed, 12 Sep 2001 00:02:53 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19802 for ; Wed, 12 Sep 2001 01:02:48 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f8C722s32577; Wed, 12 Sep 2001 09:02: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 JAA25676; Wed, 12 Sep 2001 09:02:02 +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 f8C722l43093; Wed, 12 Sep 2001 09:02:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109120702.f8C722l43093@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vladislav Yasevich cc: kanda@nn.iij4u.or.jp, ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-reply-to: Your message of Tue, 11 Sep 2001 13:55:22 EDT. <3B9E500A.B1A4F772@zk3.dec.com> Date: Wed, 12 Sep 2001 09:02:01 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think what Francis means is that all nodes should know how to process the routing header. That is, they know the header type and they layout of the header. => exactly. Your previous mail is a more accurate (than mine) description of what should be the policy for a host implementation. Some implementations took a really simplistic approach and process routing header every time including forwarding. This is what started the whole thread. Other implementations took a safer approach an decided that processing or forwarding is not appropriate under some circumstances (like when the node is configured as a host). => safer is better! So as you can see, this whole thread simply a different interpretation of the specs. It would nice if this issue would be clarified in some document, but I can live without it. => this is a policy issue so we can understand why the current specs say nothing about it. But I disagree about different interpretation, in fact there is nothing to interpret (:-)! The IPv6 host requirement document should fill the gap, if the issue becomes critical we can write and adopt a specific document (which will be included in host requirement). I don't know if there is an emergency? 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 Sep 12 01:58:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8C8w349004626 for ; Wed, 12 Sep 2001 01:58:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8C8w3uY004625 for ipng-dist; Wed, 12 Sep 2001 01:58:03 -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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8C8vw49004618 for ; Wed, 12 Sep 2001 01:57:58 -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 f8C8wCN15748; Wed, 12 Sep 2001 10:58:12 +0200 (MET DST) Date: Wed, 12 Sep 2001 10:54:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt To: Richard Draves Cc: Erik Nordmark , Stig Venaas , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA80355FCA9@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think whether this state is retained after NUD decides that a neighbor > is unreachable is implementation dependent. I had in mind other ways > that an implementation might know that the neighbor is unreachable. For > example if the interface is currently unplugged from the link on which > the neighbor resides, the neighbor is unreachable. Basically by saying > "known to be unreachable" without being more specific I'm trying to give > implementations some flexibility. If that's the intent it might be good to give the implementors some advise in addition to flexibility. Thus giving examples (perhaps in an appendix) of what implementors might want to consider "unreachable". While the unplugged interface is hard data there might be other cases where an implementation might have softer information that a peer might be unreachable. An example of this is the issue about what to do when all addresses are considered to be on-link (when there are no default routers). I don't know if it makes sense to try to cover such non-binary information in the architecture for address selection since I suspect it would add significant complexity. 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 Sep 12 22:25:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8D5PC49005613 for ; Wed, 12 Sep 2001 22:25:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8D5PCca005612 for ipng-dist; Wed, 12 Sep 2001 22:25:12 -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+Sun/8.12.0) with ESMTP id f8D5P949005605 for ; Wed, 12 Sep 2001 22:25:09 -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 WAA04175 for ; Wed, 12 Sep 2001 22:25:30 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA25486 for ; Wed, 12 Sep 2001 23:25:26 -0600 (MDT) Received: from 157.54.1.52 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 Sep 2001 22:25:21 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 12 Sep 2001 22:25:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? Date: Wed, 12 Sep 2001 22:25:21 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCAC@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (usagi-users 00767) Re: source routing honored by hosts? Thread-Index: AcE6JvtqVrI+CaqjRqOy865e+LXFRQB6d8Qg From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 13 Sep 2001 05:25:21.0891 (UTC) FILETIME=[7BE82B30:01C13C14] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8D5P949005606 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > My understanding of RFC 2460 is that all nodes, meaning > both hosts and > > routers, should process Routing Headers. > > It is mine as well, but that still doesn't make it sane or > safe behaviour; which is why I was gauging opinions on 1) how > you interpret RFC2460 and 2) how you should implement RFC2460 > wrt. routing headers. After giving this some thought, I think RFC 2460 should be revised to incorporate some security precautions. I suggest two separate restrictions on Routing Header processing. 1. When processing a Routing Header, hosts should only forward the packet to another node via the same interface by which it arrived. 2. When processing a Routing Header, nodes should compare the scope of the current and new destination addresses and only forward the packet if the new destination address has scope equal or greater than the old destination scope. The first rule will allow the Mobile IP use of Routing Headers, because in that case the packet is forwarded from a Care-Of address to a Home address on the same node. It will also allow diagnostic uses like round-trip traceroute. Forwarding from an address on one interface to an address on a second interface and then to a different node via the second interface is not allowed. The first rule prevents security problems, in the following sense: Define N1 to be the set of nodes that can attacker A can reach with a packet if hosts implement the first rule. Define N2 to be the set of nodes that A can reach if hosts do not honor Routing Headers at all. It's easy to see that N1 = N2, ie source routing with the first rule introduces no loss of security. The second rule assists applications that may be relying on address scope. For example an application that is using a site-local address might assume that packets sent to the site-local address originated within the site, or similarly packets sent to the loopback address originated within the node. The second rule prevents attackers from using source routing to violate this kind of assumption. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 23:16:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8D6G049005703 for ; Wed, 12 Sep 2001 23:16:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8D6G0oB005702 for ipng-dist; Wed, 12 Sep 2001 23:16: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+Sun/8.12.0) with ESMTP id f8D6Ft49005695 for ; Wed, 12 Sep 2001 23:15:55 -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 XAA10812 for ; Wed, 12 Sep 2001 23:15:52 -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 XAA27715 for ; Wed, 12 Sep 2001 23:15:51 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 438914B20; Thu, 13 Sep 2001 15:15:48 +0900 (JST) To: "Richard Draves" Cc: "Pekka Savola" , ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Wed, 12 Sep 2001 22:25:21 MST. <7695E2F6903F7A41961F8CF888D87EA80355FCAC@red-msg-06.redmond.corp.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: (usagi-users 00767) Re: source routing honored by hosts? From: itojun@iijlab.net Date: Thu, 13 Sep 2001 15:15:48 +0900 Message-ID: <16808.1000361748@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >1. When processing a Routing Header, hosts should only forward the >packet to another node via the same interface by which it arrived. > >The first rule will allow the Mobile IP use of Routing Headers, because >in that case the packet is forwarded from a Care-Of address to a Home >address on the same node. It will also allow diagnostic uses like >round-trip traceroute. Forwarding from an address on one interface to an >address on a second interface and then to a different node via the >second interface is not allowed. for mobile-ip6, i don't think there's a requirement to put care-of address and home address onto the same interface. forwarding from care-of to home address may not be considered an "output" in some stacks. therefore, i guess rule (1) should be augmented to cover other implementation choices. "another node" in the text looks confusing for 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 Thu Sep 13 00:28:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8D7SV49005792 for ; Thu, 13 Sep 2001 00:28:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8D7SUQv005791 for ipng-dist; Thu, 13 Sep 2001 00:28: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+Sun/8.12.0) with ESMTP id f8D7SR49005784 for ; Thu, 13 Sep 2001 00:28: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 AAA22796 for ; Thu, 13 Sep 2001 00:28:48 -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 BAA25769 for ; Thu, 13 Sep 2001 01:29:27 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8D7ShP24767; Thu, 13 Sep 2001 10:28:43 +0300 Date: Thu, 13 Sep 2001 10:28:43 +0300 (EEST) From: Pekka Savola To: Richard Draves cc: Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FCAC@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 12 Sep 2001, Richard Draves wrote: > 1. When processing a Routing Header, hosts should only forward the > packet to another node via the same interface by which it arrived. [snip rule 2] > The first rule will allow the Mobile IP use of Routing Headers, because > in that case the packet is forwarded from a Care-Of address to a Home > address on the same node. It will also allow diagnostic uses like > round-trip traceroute. Forwarding from an address on one interface to an > address on a second interface and then to a different node via the > second interface is not allowed. > > The first rule prevents security problems, in the following sense: > Define N1 to be the set of nodes that can attacker A can reach with a > packet if hosts implement the first rule. Define N2 to be the set of > nodes that A can reach if hosts do not honor Routing Headers at all. > It's easy to see that N1 = N2, ie source routing with the first rule > introduces no loss of security. I don't think this is enough. I'm not sure what you mean by round-trip traceroute, but I'm assuming it's probably like normal traceroute (increasing hop count), where you can send an additional packet to the intermediate router using routing header, to see what the return path from it is. If the intent is to send the packet with huge TTL to the destination directly, possibly with routing header, I don't see much "traceroute" in it, more like ping. The diagnostic uses don't seem interesting IMO here, as you can (assumedly) do round-trip traceroute to the next-hop router of the destination host. From there, the latency etc. changes should be minimal, and the patch symmetric assuming same-interface rule stands. So, I can't see much use for the diagnostic argument if it's assumed that routers enable source-route forwarding by default. "Local forwarding" _does_ cause a loss of security, depending on the policies. There are two kinds: 1) any host can use used as a traffic reflector 2) (more important) it can be used to avoid (simple) access-lists Of 2), I've already given an example, but I'll add it here again: host1 --- rtr1 - INET - rtr2 -+- host2 (other scenarios also exist) | +- host3 Assume that host2 is a web server. Assume that rtr2 blocks all traffic to port 80, except for host2. host3 is running an internal/testing web server. Now host1 can write: src = host1 dst = host2 tcp dport = 80 routing header = host3 Whoops.. traffic straight to host3 port 80 that was blocked. Not Good. -- 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 Thu Sep 13 05:41:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8DCf749006104 for ; Thu, 13 Sep 2001 05:41:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8DCf7BS006103 for ipng-dist; Thu, 13 Sep 2001 05:41:07 -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+Sun/8.12.0) with ESMTP id f8DCf349006096 for ; Thu, 13 Sep 2001 05:41:03 -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 FAA14189 for ; Thu, 13 Sep 2001 05:41:24 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25270 for ; Thu, 13 Sep 2001 05:41:23 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f8DCf4s12098; Thu, 13 Sep 2001 14:41: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 OAA11709; Thu, 13 Sep 2001 14:41:00 +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 f8DCewl48979; Thu, 13 Sep 2001 14:40:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109131240.f8DCewl48979@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Richard Draves" cc: "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-reply-to: Your message of Wed, 12 Sep 2001 22:25:21 PDT. <7695E2F6903F7A41961F8CF888D87EA80355FCAC@red-msg-06.redmond.corp.microsoft.com> Date: Thu, 13 Sep 2001 14:40:58 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: After giving this some thought, I think RFC 2460 should be revised to incorporate some security precautions. => I agree but this should not be in RFC 2460 (which is a draft standard i.e. not so easy to change BTW). I suggest two separate restrictions on Routing Header processing. 1. When processing a Routing Header, hosts should only forward the packet to another node via the same interface by which it arrived. => this rule is the RFC 1122 local forwarding rule. I proposed something a bit more strict (forbid forwarding)... I don't know if you really open a security hole (I don't believe this is the case), my proposal has the advantage (?) that the host definition (never forward) is still valid for source routes. Any opinion/good argument? 2. When processing a Routing Header, nodes should compare the scope of the current and new destination addresses and only forward the packet if the new destination address has scope equal or greater than the old destination scope. => I agree (note the destination can't reply because its address has not enough scope). 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 Sep 13 05:44:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8DCiV49006121 for ; Thu, 13 Sep 2001 05:44:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8DCiUkj006120 for ipng-dist; Thu, 13 Sep 2001 05: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8DCiR49006113 for ; Thu, 13 Sep 2001 05:44:27 -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 FAA14575 for ; Thu, 13 Sep 2001 05:44:47 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26379 for ; Thu, 13 Sep 2001 05:44:46 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id f8DCiOs12850; Thu, 13 Sep 2001 14:44:25 +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 OAA11754; Thu, 13 Sep 2001 14:44:24 +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 f8DCiNl49008; Thu, 13 Sep 2001 14:44:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200109131244.f8DCiNl49008@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: "Richard Draves" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? In-reply-to: Your message of Thu, 13 Sep 2001 15:15:48 +0900. <16808.1000361748@itojun.org> Date: Thu, 13 Sep 2001 14:44:23 +0200 X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >1. When processing a Routing Header, hosts should only forward the >packet to another node via the same interface by which it arrived. > >The first rule will allow the Mobile IP use of Routing Headers, because >in that case the packet is forwarded from a Care-Of address to a Home >address on the same node. It will also allow diagnostic uses like >round-trip traceroute. Forwarding from an address on one interface to an >address on a second interface and then to a different node via the >second interface is not allowed. for mobile-ip6, i don't think there's a requirement to put care-of address and home address onto the same interface. forwarding from care-of to home address may not be considered an "output" in some stacks. therefore, i guess rule (1) should be augmented to cover other implementation choices. "another node" in the text looks confusing for me. => for mobile IPv6 the source routed packet is not forwarded so rule (1) doesn't apply. Is it more clear now? 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 Sep 13 06:01:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8DD1O49006185 for ; Thu, 13 Sep 2001 06:01:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8DD1Ow4006184 for ipng-dist; Thu, 13 Sep 2001 06:01:24 -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+Sun/8.12.0) with ESMTP id f8DD1K49006177 for ; Thu, 13 Sep 2001 06:01: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 GAA24328 for ; Thu, 13 Sep 2001 06:01:41 -0700 (PDT) Received: from arianne.in.ishoni.com ([164.164.83.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02576 for ; Thu, 13 Sep 2001 06:01:37 -0700 (PDT) Received: from navaneetham ([192.168.1.212]) by arianne.in.ishoni.com (8.11.6/8.11.4/Ishonir2) with SMTP id f8DD6ej30513; Thu, 13 Sep 2001 18:36:40 +0530 Reply-To: From: "Navaneetham" To: Cc: Subject: Hi Date: Thu, 13 Sep 2001 18:33:40 +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 CWS, 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 If any body knows is Vxwroks supports IPV6 stack.??? Warm regards Navaneetham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 08:11:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8DFAp49006331 for ; Thu, 13 Sep 2001 08:11:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8DFApdV006330 for ipng-dist; Thu, 13 Sep 2001 08:10:51 -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+Sun/8.12.0) with ESMTP id f8DFA649006315 for ; Thu, 13 Sep 2001 08:10:21 -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 IAA07237 for ; Thu, 13 Sep 2001 08:10:16 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01617 for ; Thu, 13 Sep 2001 08:10:16 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f8DFAFx08293; Thu, 13 Sep 2001 08:10:15 -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 ABU06748; Thu, 13 Sep 2001 08:10:14 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA27085; Thu, 13 Sep 2001 08:10:14 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15264.52310.3834.176855@thomasm-u1.cisco.com> Date: Thu, 13 Sep 2001 08:10:14 -0700 (PDT) To: "Richard Draves" Cc: "Pekka Savola" , Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FCAC@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FCAC@red-msg-06.redmond.corp.microsoft.com> 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 Richard Draves writes: > > > My understanding of RFC 2460 is that all nodes, meaning > > both hosts and > > > routers, should process Routing Headers. > > > > It is mine as well, but that still doesn't make it sane or > > safe behaviour; which is why I was gauging opinions on 1) how > > you interpret RFC2460 and 2) how you should implement RFC2460 > > wrt. routing headers. > > After giving this some thought, I think RFC 2460 should be revised to > incorporate some security precautions. I suggest two separate > restrictions on Routing Header processing. > > 1. When processing a Routing Header, hosts should only forward the > packet to another node via the same interface by which it arrived. Is this to prevent bypass of firewall access control? If so, why couldn't you just reclassify the packet after you pop the routing header against the firewall rules again? I'd be a little worried about the implications routing loops if you don't follow least cost routing. (is this a really dumb question for a well known attack?) > 2. When processing a Routing Header, nodes should compare the scope of > the current and new destination addresses and only forward the packet if > the new destination address has scope equal or greater than the old > destination scope. Again, this seems to be trying to enforce something from within the routing system which is usually enforced by access control lists at border gateways. IP-IP encapsultation would yield the same result, and it seems to me that you just want to set up a rule at your site border router that just preclude site local addresses from entering the site *regardless* of how they get there. I'm a little worried that to put in half-measures in ipv6's treatment of site/link locals might lull people into a potentially false sense of security if there are other cases which are missed. 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 Thu Sep 13 09:12:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8DGC049006689 for ; Thu, 13 Sep 2001 09:12:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8DGC0eS006688 for ipng-dist; Thu, 13 Sep 2001 09:12: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+Sun/8.12.0) with ESMTP id f8DGBr49006681 for ; Thu, 13 Sep 2001 09:11:53 -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 JAA00919 for ; Thu, 13 Sep 2001 09:12:13 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07759 for ; Thu, 13 Sep 2001 10:12:09 -0600 (MDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 5BDC71EB3; Thu, 13 Sep 2001 11:12:12 -0500 (CDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 4FED91F0F; Thu, 13 Sep 2001 11:12:12 -0500 (CDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id A6C3F930; Thu, 13 Sep 2001 11:12:11 -0500 (CDT) Received: from yquarry.zk3.dec.com (oquarry.zk3.dec.com [16.140.112.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 215B785E; Thu, 13 Sep 2001 11:12:09 -0500 (CDT) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id LAA0000013945; Thu, 13 Sep 2001 11:54:45 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id LAA0000009340; Thu, 13 Sep 2001 11:54:42 -0400 (EDT) Message-ID: <3BA0D6C1.8FD2D7E@zk3.dec.com> Date: Thu, 13 Sep 2001 11:54:41 -0400 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont Cc: Richard Draves , Pekka Savola , ipng@sunroof.eng.sun.com Subject: Re: (usagi-users 00767) Re: source routing honored by hosts? References: <200109131240.f8DCewl48979@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > > In your previous mail you wrote: ... > > I suggest two separate restrictions on Routing Header processing. > > 1. When processing a Routing Header, hosts should only forward the > packet to another node via the same interface by which it arrived. > > => this rule is the RFC 1122 local forwarding rule. I proposed > something a bit more strict (forbid forwarding)... I don't know > if you really open a security hole (I don't believe this is the case), > my proposal has the advantage (?) that the host definition (never > forward) is still valid for source routes. Any opinion/good argument? I agree. I don't think a host should be doing any forwarding unless explicitly configured to do so. In the case of Mobile IP, the mobile is not really doing "forwarding" (however it may be implemented as such) since both the COA and HA are assigned to the mobile node. > > 2. When processing a Routing Header, nodes should compare the scope of > the current and new destination addresses and only forward the packet if > the new destination address has scope equal or greater than the old > destination scope. > > => I agree (note the destination can't reply because its address has > not enough scope). In this case, the final destination can't reverse and use the source route so this would need carefull wording. The node may end up sending a beyond scope icmp message following this rule. -vlad > > 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 > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Thu Sep 13 19:15:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2Fm7B000406 for ; Thu, 13 Sep 2001 19:15:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2FmaS000405 for ipng-dist; Thu, 13 Sep 2001 19:15: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+Sun/8.12.0) with ESMTP id f8E2Fg7D000396 for ; Thu, 13 Sep 2001 19:15:43 -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 NAA16857 for ; Thu, 13 Sep 2001 13:48:12 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA20480 for ; Thu, 13 Sep 2001 14:48:07 -0600 (MDT) Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 13:47:55 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 13:47:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? Date: Thu, 13 Sep 2001 13:47:54 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCAE@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (usagi-users 00767) Re: source routing honored by hosts? Thread-Index: AcE8UWLrHiL83Nc3T2KDS7HAWr6p5AAQ29rQ From: "Richard Draves" To: "Francis Dupont" Cc: X-OriginalArrivalTime: 13 Sep 2001 20:47:54.0587 (UTC) FILETIME=[5CAF4AB0:01C13C95] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8E2Fi7B000399 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > After giving this some thought, I think RFC 2460 should be > revised to > incorporate some security precautions. > > => I agree but this should not be in RFC 2460 (which is a > draft standard i.e. not so easy to change BTW). I don't care much how it ends being standardized. > I suggest two separate restrictions on Routing Header processing. > > 1. When processing a Routing Header, hosts should only forward the > packet to another node via the same interface by which it arrived. > > => this rule is the RFC 1122 local forwarding rule. I > proposed something a bit more strict (forbid forwarding)... I > don't know if you really open a security hole (I don't > believe this is the case), my proposal has the advantage (?) > that the host definition (never > forward) is still valid for source routes. Any opinion/good argument? I just looked at RFC 1122 section 3.3.5 and indeed my proposal is basically its "local source-routing". The only difference is that for IPv6 I think we need to allow source routing between interfaces within the host, for Mobile IP. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 19:34:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2YY7B000653 for ; Thu, 13 Sep 2001 19:34:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2YXxA000652 for ipng-dist; Thu, 13 Sep 2001 19:34:33 -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+Sun/8.12.0) with ESMTP id f8E2YT7B000643 for ; Thu, 13 Sep 2001 19:34:30 -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 NAA07616 for ; Thu, 13 Sep 2001 13:10:03 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA29161 for ; Thu, 13 Sep 2001 13:10:02 -0700 (PDT) Received: from 157.54.8.23 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 13:09:50 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 13:09:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? Date: Thu, 13 Sep 2001 13:09:50 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EF97B@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (usagi-users 00767) Re: source routing honored by hosts? Thread-Index: AcE8G40iQ3NeLkV5Qeegg/+JcMi21QAdBAIw From: "Richard Draves" To: Cc: X-OriginalArrivalTime: 13 Sep 2001 20:09:50.0412 (UTC) FILETIME=[0B35D8C0:01C13C90] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8E2YU7B000644 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >1. When processing a Routing Header, hosts should only forward the > >packet to another node via the same interface by which it arrived. > > > >The first rule will allow the Mobile IP use of Routing > Headers, because > >in that case the packet is forwarded from a Care-Of address > to a Home > >address on the same node. It will also allow diagnostic uses like > >round-trip traceroute. Forwarding from an address on one > interface to > >an address on a second interface and then to a different > node via the > >second interface is not allowed. > > for mobile-ip6, i don't think there's a requirement to put > care-of address and home address onto the same > interface. forwarding > from care-of to home address may not be considered an "output" > in some stacks. therefore, i guess rule (1) should be augmented > to cover other implementation choices. "another node" > in the text > looks confusing for me. I agree, there is no requirement to assign the care-of address and home address to the same interface and many implementations will in fact assign them to different interfaces. The rule does not prevent forwarding that is internal to the node - the "same interface" clause applies when forwarding the packet to another node. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 19:57:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2v67B000928 for ; Thu, 13 Sep 2001 19:57:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2v6Sf000927 for ipng-dist; Thu, 13 Sep 2001 19:57: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+Sun/8.12.0) with ESMTP id f8E2v27B000920 for ; Thu, 13 Sep 2001 19:57:02 -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 NAA19157 for ; Thu, 13 Sep 2001 13:55:08 -0700 (PDT) Received: from inet-imc-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02648 for ; Thu, 13 Sep 2001 13:55:07 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 13:55:07 -0700 Received: from 157.54.9.104 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 13:55:07 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 13:55:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? Date: Thu, 13 Sep 2001 13:55:06 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCAF@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (usagi-users 00767) Re: source routing honored by hosts? Thread-Index: AcE8ZjaYEYyTDJPRQaKopqOZXqlP7QAL0XpQ From: "Richard Draves" To: "Michael Thomas" Cc: X-OriginalArrivalTime: 13 Sep 2001 20:55:06.0611 (UTC) FILETIME=[5E30EC30:01C13C96] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8E2v37B000921 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > 1. When processing a Routing Header, hosts should only > forward the > packet to another node via the same interface > by which it arrived. > > Is this to prevent bypass of firewall access control? > If so, why couldn't you just reclassify the packet > after you pop the routing header against the firewall > rules again? I'd be a little worried about the implications > routing loops if you don't follow least cost routing. The idea is to prevent a multi-homed host from becoming an unintended conduit for packets between two networks. I'm not sure I understand your comment about least-cost routing, but there are already situations where some implementations restrict an outgoing packet to the same interface as incoming packet. For example when sending ICMP errors. > > 2. When processing a Routing Header, nodes should compare > the scope of > the current and new destination addresses and > only forward the packet if > the new destination address has > scope equal or greater than the old > destination scope. > > Again, this seems to be trying to enforce something > from within the routing system which is usually > enforced by access control lists at border gateways. > IP-IP encapsultation would yield the same result, and > it seems to me that you just want to set up a rule > at your site border router that just preclude site > local addresses from entering the site *regardless* > of how they get there. I'm a little worried that to > put in half-measures in ipv6's treatment of site/link > locals might lull people into a potentially false sense > of security if there are other cases which are missed. It's true there are many pieces that have to be covered to enforce containment of scope addresses. For example, having routers check the scope of source addresses. I do not view scoped address containment as something which is usually enforced by access control lists. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 19:58:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2wc7P000952 for ; Thu, 13 Sep 2001 19:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2S0lK000593 for ipng-dist; Thu, 13 Sep 2001 19:28: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+Sun/8.12.0) with ESMTP id f8E2Rt7B000583 for ; Thu, 13 Sep 2001 19:27:55 -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 JAA13061 for ; Thu, 13 Sep 2001 09:54:10 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA27209 for ; Thu, 13 Sep 2001 10:54:05 -0600 (MDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 Sep 2001 09:53:58 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 13 Sep 2001 09:53:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (usagi-users 00767) Re: source routing honored by hosts? Date: Thu, 13 Sep 2001 09:53:58 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCAD@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (usagi-users 00767) Re: source routing honored by hosts? Thread-Index: AcE8JbnE/g2i3SFSRq634f4oEoGA4gATMNpg From: "Richard Draves" To: "Pekka Savola" Cc: X-OriginalArrivalTime: 13 Sep 2001 16:53:57.0908 (UTC) FILETIME=[AE2C0D40:01C13C74] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8E2Ru7B000584 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > host1 --- rtr1 - INET - rtr2 -+- host2 (other scenarios also exist) > | > +- host3 > > Assume that host2 is a web server. > > Assume that rtr2 blocks all traffic to port 80, except for host2. > > host3 is running an internal/testing web server. > > Now host1 can write: > > src = host1 > dst = host2 > tcp dport = 80 > routing header = host3 > > Whoops.. traffic straight to host3 port 80 that was blocked. This is a good example of a potential problem with source routing, but it is a weak counter-example to my claim that allowing hosts to process source routes subject to the "same interface" rule does not introduce additional security problems beyond what you get if routers process source routes. For example, modify the example as follows: host1 --- rtr1 - INET - rtr2 -+- rtr3 -+- host2 | +- host4, etc | +- host3 Where rtr2 has a firewall policy that only allows port 80 towards the subnet of host2 & host4. Then host1 can construct a source route to reach host3 where the intermediate address is assigned to rtr3's interface towards host2. So my point is that whether or not hosts honor source routes, a firewall with destination-based policies should be cognizant of Routing Headers. It's really an orthogonal issue. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 19:58:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2wc7J000952 for ; Thu, 13 Sep 2001 19:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2ZNPV000669 for ipng-dist; Thu, 13 Sep 2001 19:35:23 -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+Sun/8.12.0) with ESMTP id f8E2ZK7B000662 for ; Thu, 13 Sep 2001 19:35:20 -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 NAA00158 for ; Thu, 13 Sep 2001 13:30:24 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20909 for ; Thu, 13 Sep 2001 13:30:20 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA15580; Thu, 13 Sep 2001 16:31:31 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA14263; Thu, 13 Sep 2001 16:31:30 -0400 Message-ID: <3BA11797.F2D7825D@txc.com> Date: Thu, 13 Sep 2001 16:31:19 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <4.3.2.7.2.20010824154601.0250edd8@mailhost.iprg.nokia.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msA7A9EF7AB2A1F66B949006BD" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msA7A9EF7AB2A1F66B949006BD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, Apologies for a late set of comments. I. Esthetics: (this was true in earlier incarnations of the document) There are 3 numbered sections in the document, which is a very conservative use of section numbering. Practically there is only one section, section 2, that has more than a couple of paragraphs of content. Each of the next level subsections of section 2, could be independent sections by themselves. The text representation could be grouped in one section, plus two subsections. Etc... For instance: (current) 2. IPv6 Addressing 2.1 Addressing Model 2.2 Text Representation of Addresses 2.3.... (suggested) 2. Addressing Model 3. Text Representation 3.1 Representation of Addresses 3.2 Representation of Prefixes 4. Address Type Representation 5. Type of Addresses 5.1 Unicast Addresses 5.2 Anycast.... etc.... II. Address space fully allocated. It seems that the new document specifies an address space which is fully allocated for IPv6. There is no space set aside at this time for experiments, or future use, while the future carving of the space is left to future specifications. The model in which space was set aside ahead of time worked well in IPv4, while the experience of carving out space from space already allocated for one purpose never worked well before, or it does not currently. Therefore I am a strong supporter of having some space set aside now - two chunks: experimental, and reserved. III Multicast address local scopes. The document defines now: interface-local subnet-local admin-local site-local organizational-local Some of the names used are self-explanatory, but others are not, and no explanations are given, or references to other documents, which I do not think it is good. For instance, I am not sure what what "interface local" means. "interface-local" means forwarding within the interface? Does not make too much sense to me. "node local" was dropped, although through its name it made sense as scope for multicast packets forwarded internally, within a node, but which never left the node. Regards, Alex , or Bob Hinden wrote: > > This is a short IPng working group last call for comments on advancing the > following document as an Draft Standard: > > Title : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-06.txt > Pages : 27 > Date : 19-Jul-01 > > A complete list of changes from RFC-2373 is in Appendix B of the draft and > is reproduced below. > > Please send substantive comments to the ipng mailing list, and minor > editorial comments to the authors. This last call period will end one > week from today on August 31, 2001. > > We are doing a short w.g. last call because there have been earlier w.g. > and IETF last calls on this document and wanted to insure that the changes > in the current draft has been reviewed by the w.g. > > Bob Hinden / Steve Deering > > -------------------------------------------------------------------------- > > APPENDIX B: Changes from RFC-2373 > --------------------------------- > > The following changes were made from RFC-2373 "IP Version 6 > Addressing Architecture": > > - Many small changes to clarify and make the text more consistent. > - Revised sections 2.4 and 2.5.6 to simplify and clarify how > different address types are identified. This was done to insure > that implementations do not build in any knowledge about global > unicast format prefixes. Changes include: > o Removed Format Prefix (FP) terminology > o Revised list of address types only includes exceptions to > global unicast and a singe entry that identifies everything > else as Global Unicast. > o Removed list of defined prefix exceptions from section 2.5.6 > as it is now the main part of section 2.4. > - Clarified text relating to EUI-64 identifiers to distinguish > between IPv6's "Modified EUI-64 format" identifiers and IEEE > EUI-64 identifiers. > - Combined the sections on the Global Unicast Addresses and NSAP > Addresses into a single section on Global Unicast Addresses, > generalized the Global Unicast format, and cited [AGGR] and [NSAP] > as examples. > - Reordered sections 2.5.4 and 2.5.5. > - Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses > because this is being redefined elsewhere. > - Added an IANA considerations section that updates the IANA IPv6 > address allocations and documents the NSAP and AGGR allocations. > - Added clarification that the "IPv4-compatible IPv6 address" must > use global IPv4 unicast addresses. > - Divided references in to normative and non-normative sections. > - Added reference to [PRIV] in section 2.5.1 > - Revised section 2.4 Address Type Representation to > - Added clarification that routers must not forward multicast > packets outside of the scope indicated in the multicast address. > - Added clarification that routers must not forward packets with > source address of the unspecified address. > - Added clarification that routers must drop packets received on an > interface with destination address of loopback. > - Clarified the definition of IPv4-mapped addresses. > - Removed the ABNF Description of Text Representations Appendix. > - Removed the address block reserved for IPX addresses. > - Multicast scope changes: > o Changed name of scope value 1 from "node-local" to "interface- > local" > o Defined scope value 3 for "subnet-local" for multi-link > subnets > o Defined scope value 4 as "admin-local" > - Corrected reference to RFC1933 and updated references. > > ------------------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------msA7A9EF7AB2A1F66B949006BD Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTMyMDMxMjFaMCMGCSqGSIb3DQEJBDEWBBSvc9Ac9K2xYKcLw/eQ GAsyFfwZazBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gCmJrkewkQ/Lj0GH2zA/mx3FuWHfD5E24kWhwIuj3d/MLxjGSKID7gBE2AYjO6jTeg7yRplo aYpzpnVBYYDZM5ywLNU7svWEigr5Zq9xMRVJxvevBRLCN/aHm6rK9tGg2aNHnjWN96qsnVV6 GWi7fQ5OjVklTZN09QN6Cs5xp4CY --------------msA7A9EF7AB2A1F66B949006BD-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 19:58:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2we7B000960 for ; Thu, 13 Sep 2001 19:58:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2wd3d000957 for ipng-dist; Thu, 13 Sep 2001 19:58:39 -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+Sun/8.12.0) with ESMTP id f8E2wX7B000937 for ; Thu, 13 Sep 2001 19:58: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 QAA27816 for ; Thu, 13 Sep 2001 16:13:12 -0700 (PDT) Received: from msgbas1.sgp.agilent.com (msgbas1x.net.asiapac.agilent.com [192.25.42.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08416 for ; Thu, 13 Sep 2001 16:13:11 -0700 (PDT) Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id A549420A; Fri, 14 Sep 2001 07:13:10 +0800 (SGP) Received: from apbrg2.jpn.agilent.com (apbrg2.jpn.agilent.com [146.208.102.163]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id D06F9570; Fri, 14 Sep 2001 07:13:09 +0800 (SGP) Received: from 146.208.102.163 by apbrg2.jpn.agilent.com (InterScan E-Mail VirusWall NT); Fri, 14 Sep 2001 08:13:09 +0900 Received: by apbrg2.jpn.agilent.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 08:13:09 +0900 Message-ID: <050F1F49D79BD3118F3B0090278CB91803A39AEB@apmail7.aus.agilent.com> From: "FIELD,GEOFF (A-Australia,ex1)" To: "'naveens@ishoni.com'" , ipng@sunroof.eng.sun.com Cc: senthiln@india.hp.com Subject: RE: Hi Date: Fri, 14 Sep 2001 08:13:05 +0900 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 You could always do the obvious and ask Wind River directly. Try www.windriver.com Searching that site for "IPv6" brought up 10 hits, including one announcing that they're members of "the IPv6 Forum" I suspect it's not supported in the normal code suite, but is or should be available. Geoff Field, Agilent Technologies Australia (Speaking just for myself) > -----Original Message----- > From: Navaneetham [mailto:naveens@ishoni.com] > Sent: Thursday, 13 September 2001 23:04 > To: ipng@sunroof.eng.sun.com > Cc: senthiln@india.hp.com > Subject: Hi > > > If any body knows is Vxwroks supports IPV6 stack.??? > > > Warm regards > Navaneetham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 13 19:58:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E2wc7N000952 for ; Thu, 13 Sep 2001 19:58:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E2ODIs000546 for ipng-dist; Thu, 13 Sep 2001 19:24: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+Sun/8.12.0) with ESMTP id f8E2O67B000538 for ; Thu, 13 Sep 2001 19:24:06 -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 KAA26128 for ; Thu, 13 Sep 2001 10:40:31 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14567 for ; Thu, 13 Sep 2001 11:41:11 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10698; Thu, 13 Sep 2001 13:40:38 -0400 (EDT) Message-Id: <200109131740.NAA10698@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Document Action: IPv6 multihoming support at site exit routers to Informational Date: Thu, 13 Sep 2001 13:40:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'IPv6 multihoming support at site exit routers' as an Informational RFC. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 02:05:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8E95r7B001634 for ; Fri, 14 Sep 2001 02:05:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8E95r4b001633 for ipng-dist; Fri, 14 Sep 2001 02:05: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+Sun/8.12.0) with ESMTP id f8E95n7B001626 for ; Fri, 14 Sep 2001 02:05:49 -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 CAA08405 for ; Fri, 14 Sep 2001 02:06:09 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27341 for ; Fri, 14 Sep 2001 03:06:49 -0600 (MDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 11:06:05 +0200 Message-ID: <31A473DBB655D21180850008C71E251A04ECAA80@mail.kebne.se> From: Thomas Eklund To: "'FIELD,GEOFF (A-Australia,ex1)'" , "'naveens@ishoni.com'" , ipng@sunroof.eng.sun.com Cc: senthiln@india.hp.com Subject: RE: Hi Date: Fri, 14 Sep 2001 11:06:03 +0200 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 They have had it for many years with their Epilouge stack. -- thomas >-----Original Message----- >From: FIELD,GEOFF (A-Australia,ex1) [mailto:geoff_field@agilent.com] >Sent: den 14 september 2001 01:13 >To: 'naveens@ishoni.com'; ipng@sunroof.eng.sun.com >Cc: senthiln@india.hp.com >Subject: RE: Hi > > >You could always do the obvious and ask Wind River directly. >Try www.windriver.com > >Searching that site for "IPv6" brought up 10 hits, including >one announcing >that they're members of "the IPv6 Forum" > >I suspect it's not supported in the normal code suite, but is >or should be >available. > >Geoff Field, >Agilent Technologies Australia >(Speaking just for myself) > > >> -----Original Message----- >> From: Navaneetham [mailto:naveens@ishoni.com] >> Sent: Thursday, 13 September 2001 23:04 >> To: ipng@sunroof.eng.sun.com >> Cc: senthiln@india.hp.com >> Subject: Hi >> >> >> If any body knows is Vxwroks supports IPV6 stack.??? >> >> >> Warm regards >> Navaneetham >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home 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 Fri Sep 14 08:33:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EFX27B002071 for ; Fri, 14 Sep 2001 08:33:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EFX2tA002070 for ipng-dist; Fri, 14 Sep 2001 08:33:02 -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+Sun/8.12.0) with ESMTP id f8EFWw7B002063 for ; Fri, 14 Sep 2001 08:32:58 -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 IAA24124 for ; Fri, 14 Sep 2001 08:33:19 -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 IAA16588 for ; Fri, 14 Sep 2001 08:33:18 -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 f8EFXHK26071 for ; Fri, 14 Sep 2001 17:33:17 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Sep 14 17:33:16 2001 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Sep 2001 17:26:16 +0200 Message-ID: <034BEFD03799D411A59F00508BDF754603008CC7@esealnt448.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Richard Draves Cc: ipng@sunroof.eng.sun.com Subject: RE: Some comments regarding draft-ietf-ipngwg-default-addr-select -05.txt Date: Fri, 14 Sep 2001 17:33:00 +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, Some comments from when you were disconnected from the list (after Seattle). I've copied the first 2 mails from me and reply from Erik. There might have been a couple more but you can see the rchives on those dates if you need more info. Hesham -----Original Message----- From: Erik Nordmark [SMTP:Erik.Nordmark@eng.sun.com] Sent: Tuesday, 5 June 2001 4:23 To: Hesham Soliman (ERA) Cc: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" > 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 -----Original Message----- From: Hesham Soliman (ERA) [SMTP:Hesham.Soliman@era.ericsson.se] Sent: Tuesday, 5 June 2001 12:40 To: ipng@sunroof.eng.sun.com Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" 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 Fri Sep 14 08:35:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EFZC7B002090 for ; Fri, 14 Sep 2001 08:35:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EFZCn7002089 for ipng-dist; Fri, 14 Sep 2001 08:35: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+Sun/8.12.0) with ESMTP id f8EFZ87B002082 for ; Fri, 14 Sep 2001 08:35:08 -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 IAA27995; Fri, 14 Sep 2001 08:35:28 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17671; Fri, 14 Sep 2001 08:35:28 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id LAA30380; Fri, 14 Sep 2001 11:36:36 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id LAA18724; Fri, 14 Sep 2001 11:36:31 -0400 Message-ID: <3BA223FC.4F368BFD@txc.com> Date: Fri, 14 Sep 2001 11:36:28 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brian E Carpenter CC: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDF3D383BDB6F7AC8CD00C4A4" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDF3D383BDB6F7AC8CD00C4A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit While I think an implementation does not have to explicitly be concerned about Prefix Format bits, since the bits are automatically included in a prefix, I am quite concerned about the fact that at this moment the entire IPv6 space is allocated, with no experimental, or reserved space for future development. Carving out such a space ahead of time, like in IPv4, worked well. It provides the benefit that if people experiment with a number of addresses, they know ahead of time, what they have available, and will not conflict with global addresses, or other addresses, already in use. Carving out space at a later time, experience showed, is a difficult thing to do, it is controversial, and the effort to standardize such an address block allocation may hamper the essential part of the work, which needs the address block. Additionally, when would one ask for such address space? when a projects starts, when is well underway? The model is quite questionable. Alex Brian E Carpenter wrote: > > Well, I miswrote slightly - the fact is that an implementation has to > first check if the address is any of the non-global-unicast cases, and that > involves doing a sequence of matches which involve the bits > Formerly Known as the Format Prefix (not just 3 of them of course). > I think the new text makes this harder to understand. It doesn't change > what implementors should do. > > Feel free to ignore my comment if nobody else has the same reaction. > > Brian > > Erik Nordmark wrote: > > > > > I also think that abolishing the term "format prefix" is obfuscation. The > > > fact is that the leading bits of an address *are* a format prefix and > > > implementors *will* look at those bits before processing an address. Why > > > obscure that fact? > > > > Brian, > > It is exactly this that we want to avoid - implementors thinking that they > > need to inspect the first 3 bits of the addresses. > > There is no need to do this and we need to reduce the probability that > > implementors hard-code any knowledge of any leading 3 bit combinations > > since it will make it harder to use the other 15/16th of the address space > > in the future. > > > > 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 > -------------------------------------------------------------------- --------------msDF3D383BDB6F7AC8CD00C4A4 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTQxNTM2MjlaMCMGCSqGSIb3DQEJBDEWBBQNMGPWLZcUHTATxM6Y H9cI6T0RmjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gGHQTNkXSQEUA+e34m/NjB52n7cx+qsrM9gZN6WqbnuJdp/8/fmZIOo0T9xkPLt/JqzV6ugR X5k0XfVumgFOLdTAtximY0U+4iEfwy6BjNCKpnksoqScGmQROPX5VCYvQ0tIw3e9GMkN1vKe 9Cv7qTIyWTroI2W7ct1dKVF+Mq2q --------------msDF3D383BDB6F7AC8CD00C4A4-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 08:49:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EFno7B002145 for ; Fri, 14 Sep 2001 08:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EFnoAj002144 for ipng-dist; Fri, 14 Sep 2001 08:49: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+Sun/8.12.0) with ESMTP id f8EFnk7B002137 for ; Fri, 14 Sep 2001 08:49: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 IAA02445 for ; Fri, 14 Sep 2001 08:50:07 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-108.research.att.com [135.207.10.108]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24750 for ; Fri, 14 Sep 2001 08:50:07 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15hvDc-0003lB-00; Fri, 14 Sep 2001 11:49:28 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Conta Cc: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> Message-Id: Date: Fri, 14 Sep 2001 11:49:28 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am quite concerned about the fact that at this moment the entire > IPv6 space is allocated, with no experimental, or reserved space for > future development. i don't perceive that this is at all the case. almost no space has been allocated, O(100) /35s. the current drafts have iana considerations asking that they only allocate from 001/3. what am i missing here 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 Fri Sep 14 09:54:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EGsC7B002234 for ; Fri, 14 Sep 2001 09:54:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EGsCw7002233 for ipng-dist; Fri, 14 Sep 2001 09:54: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+Sun/8.12.0) with ESMTP id f8EGs97B002226 for ; Fri, 14 Sep 2001 09:54: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 JAA17644 for ; Fri, 14 Sep 2001 09:54:30 -0700 (PDT) Received: from fridge.docomo-usa.com ([216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08720 for ; Fri, 14 Sep 2001 10:54:23 -0600 (MDT) Received: from localhost (gyj@localhost) by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f8EH1GU24119 for ; Fri, 14 Sep 2001 10:01:16 -0700 (PDT) Date: Fri, 14 Sep 2001 10:01:16 -0700 (PDT) From: Youngjune Lee Gwon X-Sender: gyj@fridge.docomo-usa.com To: ipng@sunroof.eng.sun.com Subject: Regarding IPv6 Implementation In-Reply-To: <034BEFD03799D411A59F00508BDF754603008CC7@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 Hi, Can anybody suggest what platform/implementation(s) of IPv6 support all of the following at this moment? 1) v6 Multicast 2) anycast 3) v6 address autoconfiguration using dhcpv6 In other words, which platform/implementation of IPv6 is most complete or mature so far? Your suggestion will be greatly appreciated. ---------------------------------------------- Youngjune Gwon gyj@docomolabs-usa.com Research Engineer Mobile Internet Laboratory DoCoMo Communications Laboratories USA, 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 Sep 14 11:36:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EIaJ7B002406 for ; Fri, 14 Sep 2001 11:36:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EIaJR9002405 for ipng-dist; Fri, 14 Sep 2001 11:36:19 -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+Sun/8.12.0) with ESMTP id f8EIaF7B002398 for ; Fri, 14 Sep 2001 11:36:15 -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 LAA12603; Fri, 14 Sep 2001 11:36:35 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18322; Fri, 14 Sep 2001 11:36:34 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id OAA02001; Fri, 14 Sep 2001 14:37:45 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id OAA28165; Fri, 14 Sep 2001 14:37:44 -0400 Message-ID: <3BA24E65.3334740@txc.com> Date: Fri, 14 Sep 2001 14:37:25 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms98F90C0496A69ADFA45F3515" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms98F90C0496A69ADFA45F3515 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Obviously, there was, and is confusion: a. My wording "allocated" refers to the specifications' allocation/partioning, as opposed to registries' allocation. Sorry. b. Comparing section 2.4 of RFC 2373 (page 6), and the draft (page 7), there is difference, since a table was removed/moved. Based on page 7 of the draft, the table in section 2.4 seem to suggest that the "global unicast" is "(everything else)", besides, unspecified, loopback, multicast, link-local, and site-local addresses. These were both a source of confusion. c. Why is the IANA Section in the Appendix C, following two informational appendices? It is not "normative"? Given the place and the order, one can simply miss it, as I did, sorry, which can be an obvious source of confusion. I think the specifications being more clear, would help lower the probability of confusion, in particular, information relative to the partitioning of the address space. Also the partitioning must be normative, or I am missing something Alex Randy Bush wrote: > > > I am quite concerned about the fact that at this moment the entire > > IPv6 space is allocated, with no experimental, or reserved space for > > future development. > > i don't perceive that this is at all the case. > > almost no space has been allocated, O(100) /35s. > > the current drafts have iana considerations asking that they only > allocate from 001/3. > > what am i missing here > > 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 > -------------------------------------------------------------------- --------------ms98F90C0496A69ADFA45F3515 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTQxODM3MzdaMCMGCSqGSIb3DQEJBDEWBBTOyv2vJwgiCVU1H120 l4f1fShTxDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gI0Lxa+eofFUfFV2YMIda9IP9lccVuyrIYKG//3RjrkLLP9zztby+VMqoTCPmnnh/9kWhXY1 +EAW88D4kXn9bkLybAvkXx2L27/jB6ONPx1VjjhIlYdIo4icXFFsZvP+N56fDki6HMCNXkXN thuRyvRyr+EPmiX18vAL1ZuS5PZP --------------ms98F90C0496A69ADFA45F3515-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 11:43:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EIhE7B002441 for ; Fri, 14 Sep 2001 11:43:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EIhDuT002440 for ipng-dist; Fri, 14 Sep 2001 11:43: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+Sun/8.12.0) with ESMTP id f8EIhA7B002433 for ; Fri, 14 Sep 2001 11:43:10 -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 LAA03225; Fri, 14 Sep 2001 11:43:30 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-108.research.att.com [135.207.10.108]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21749; Fri, 14 Sep 2001 11:43:29 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15hxvU-0003tY-00; Fri, 14 Sep 2001 14:42:56 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Conta Cc: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> <3BA24E65.3334740@txc.com> Message-Id: Date: Fri, 14 Sep 2001 14:42:56 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the specifications being more clear send text 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 Fri Sep 14 12:46:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EJkJ7B002614 for ; Fri, 14 Sep 2001 12:46:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EJkJ3R002613 for ipng-dist; Fri, 14 Sep 2001 12:46: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+Sun/8.12.0) with ESMTP id f8EJkF7B002606 for ; Fri, 14 Sep 2001 12:46: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 MAA18035; Fri, 14 Sep 2001 12:46:35 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03880; Fri, 14 Sep 2001 13:46:30 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id PAA03813; Fri, 14 Sep 2001 15:47:45 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id PAA02050; Fri, 14 Sep 2001 15:47:34 -0400 Message-ID: <3BA25ECB.84A401A5@txc.com> Date: Fri, 14 Sep 2001 15:47:23 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> <3BA24E65.3334740@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msDA6DE8215393E9208DD35AB3" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msDA6DE8215393E9208DD35AB3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK, since you've asked, here is an example -- please note that having a separate section which eliminates the confusion between "representation" and "partitioning" would IMHO add clarity: ---------- X.Y. Address Space Partitioning The IPv6 address space is partitioned to provide an adequate number of addresses for various types of communications, such as unicast, multicast, and/or anycast. The partitioning provides also an adequate number of addresses for experimental, and/or future use. Currently the following space is partitioned and assigned for: IPv6 unicast: 1/1024 (2**118 = 332306998946228968225951765070086000 addresses) of the total space is assigned for link-local communications 1/1024 (2**118 = 332306998946228968225951765070086000 addresses) of the total space is assigned for site-local communications 1/8 (2**125 = 4.2535295865117307932921825928971e+37 addresses) of the total space is assigned for global unicast communications note: anycast communications used unicast address space IPv6 multicast: 1/256 (2**120 = 1.3292279957849158729038070602803e+36 addresses) of the total space is assigned for multicast communications RFC 1888: 1/128 (2**121 = 2.6584559915698317458076141205607e+36 addresses) of the total space is assigned for RFC 1888 type communications This represents 1/8+7/512 of the total IPv6 address space. Unassigned: 6/8 + 57/512 (2.5521177519070384759753095557382e+38 + 3.788299787987010237775850121799e+37 of addresses) This is the remaining of the address space, which has not been assigned. Note: specifying real numbers along with fractions adds a good indication of the dimensions of the address space. -------- Randy Bush wrote: > > > I think the specifications being more clear > > send text > > randy --------------msDA6DE8215393E9208DD35AB3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTQxOTQ3MjVaMCMGCSqGSIb3DQEJBDEWBBRo+SfiP/m/rOGOMPYs jia72O18BTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gKGoDXg1mPDym6DlfzTCEh0yusB/xFkDC7h9vyEtNU5ffSy0P+OtnhvFvtkZmZMHWdayIICF 49i6gSt25761yLTzaLki5Cbcoog/sQsFaEtMZWzXLWfTr7UB2GggmbQ1VgbJSZOeDD9W1vd/ IBjPkN5Jrw3b4sUcJC2b4AUnlIsA --------------msDA6DE8215393E9208DD35AB3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 12:52:10 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EJqA7B002878 for ; Fri, 14 Sep 2001 12:52:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EJqAnk002877 for ipng-dist; Fri, 14 Sep 2001 12:52:10 -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+Sun/8.12.0) with ESMTP id f8EJq57B002870 for ; Fri, 14 Sep 2001 12:52:06 -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 MAA00814; Fri, 14 Sep 2001 12:52:26 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-108.research.att.com [135.207.10.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18772; Fri, 14 Sep 2001 13:53:10 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15hz09-0003x3-00; Fri, 14 Sep 2001 15:51:49 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Conta Cc: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> <3BA24E65.3334740@txc.com> <3BA25ECB.84A401A5@txc.com> Message-Id: Date: Fri, 14 Sep 2001 15:51:49 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Unassigned: > > 6/8 + 57/512 (2.5521177519070384759753095557382e+38 > + 3.788299787987010237775850121799e+37 > of addresses) > This is the remaining of the address space, which has not > been assigned. sorry, i should have been more specific. please send CORRECT text :-). that space is unicast space. we specifically don't want folk coding forwarding or routing algorithms treating it any differently than > IPv6 unicast: we've been to that movie, and even the popcorn sucked. took years to clean stuff up. 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 Fri Sep 14 13:36:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EKaI7B003279 for ; Fri, 14 Sep 2001 13:36:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EKaI1A003278 for ipng-dist; Fri, 14 Sep 2001 13:36:18 -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+Sun/8.12.0) with ESMTP id f8EKaE7B003271 for ; Fri, 14 Sep 2001 13:36:14 -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 NAA10262; Fri, 14 Sep 2001 13:36:35 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07660; Fri, 14 Sep 2001 13:36:35 -0700 (PDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id QAA04990; Fri, 14 Sep 2001 16:37:46 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id QAA04924; Fri, 14 Sep 2001 16:37:35 -0400 Message-ID: <3BA26A80.8B586582@txc.com> Date: Fri, 14 Sep 2001 16:37:20 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> <3BA24E65.3334740@txc.com> <3BA25ECB.84A401A5@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msADE227AB1DB636DFA629B0A1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msADE227AB1DB636DFA629B0A1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Bush wrote: > > > Unassigned: > > > > 6/8 + 57/512 (2.5521177519070384759753095557382e+38 > > + 3.788299787987010237775850121799e+37 > > of addresses) > > This is the remaining of the address space, which has not > > been assigned. > > sorry, i should have been more specific. please send CORRECT text :-). > > that space is unicast space. we specifically don't want folk coding > forwarding or routing algorithms treating it any differently than > So "unassigned" means really "assigned for unicast, but undefined yet type of addresses". That would certainly not represent accurately or encourage any future developments other than the one focused on unicast. How could we know now what the future communication models would be? Furthermore, I do not see the motivation behind such restriction. Could you elaborate on the exact reasons? --------------msADE227AB1DB636DFA629B0A1 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTQyMDM3MjRaMCMGCSqGSIb3DQEJBDEWBBTDbdxm42NmDaQ6W+L9 V2XH+0P6ZDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gLpTlbIKC6/S8nttuYNfuqc/yuCfm7mtcCTJafC8CiOC5UKzV5ctpdcMh9zloPHeOyRFHTyD V/uF/pOuiwy4DZtsMfOyuojwjI3AxhdJwIT3DKgY3TRjlNNcz457nLv1XAKp5h1xN8SonARy lguto+kLGZAO7/fnEy4NagD2V2M7 --------------msADE227AB1DB636DFA629B0A1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 13:50:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EKoh7B003319 for ; Fri, 14 Sep 2001 13:50:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EKoh4t003318 for ipng-dist; Fri, 14 Sep 2001 13:50:43 -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+Sun/8.12.0) with ESMTP id f8EKod7B003311 for ; Fri, 14 Sep 2001 13:50:39 -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 NAA00968; Fri, 14 Sep 2001 13:50:57 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-108.research.att.com [135.207.10.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18177; Fri, 14 Sep 2001 14:51:40 -0600 (MDT) Received: from randy by roam.psg.com with local (Exim 3.33 #1) id 15hzut-00041S-00; Fri, 14 Sep 2001 16:50:27 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Conta Cc: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> <3BA24E65.3334740@txc.com> <3BA25ECB.84A401A5@txc.com> <3BA26A80.8B586582@txc.com> Message-Id: Date: Fri, 14 Sep 2001 16:50:27 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So "unassigned" means really "assigned for unicast, but undefined yet > type of addresses". > > That would certainly not represent accurately or encourage any future > developments other than the one focused on unicast. How could we know > now what the future communication models would be? Furthermore, I do not > see the motivation behind such restriction. > > Could you elaborate on the exact reasons? because we remember implementations and protocols that had A, B, and C hard coded and how hard it was getting cidr deployed. we want to make it very clear that current/new implementations should treat it all as unicast. if someone comes up with some bright idea down the pike, then is the time to hack. but we should not set things up so we have to hack to achieve what we see as the most probably path today. make sense? 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 Fri Sep 14 14:05:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EL5G7B003356 for ; Fri, 14 Sep 2001 14:05:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EL5GFi003355 for ipng-dist; Fri, 14 Sep 2001 14: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+Sun/8.12.0) with ESMTP id f8EL5C7B003348 for ; Fri, 14 Sep 2001 14:05:12 -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 OAA04404; Fri, 14 Sep 2001 14:05:33 -0700 (PDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09702; Fri, 14 Sep 2001 14:05:32 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [192.168.1.107]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id RAA31122; Fri, 14 Sep 2001 17:05:32 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id RAA29800; Fri, 14 Sep 2001 17:05:30 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id RAA29442; Fri, 14 Sep 2001 17:02:41 -0400 Message-Id: <200109142102.RAA29442@rotala.raleigh.ibm.com> To: Brian E Carpenter cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-Reply-To: Message of "Fri, 07 Sep 2001 13:49:17 CDT." <3B9916AD.11C4FDB1@hursley.ibm.com> Date: Fri, 14 Sep 2001 17:02:40 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Well, I miswrote slightly - the fact is that an implementation has to > first check if the address is any of the non-global-unicast cases, and that > involves doing a sequence of matches which involve the bits > Formerly Known as the Format Prefix (not just 3 of them of course). The key here is that implementations need to check for a list of prefixes that they special case. None of them (at the present time) are just the first 3 bits. So they shouldn't check the format prefix per se. Having a format prefix doesn't actually help in the overall scheme. If at some point someone wants to reserve a swath of address space for some special/experimental purpose (e.g., 8+8, etc.), that can be done by simply reserving a specific prefix that is big enough to meet the need. Moreover, that prefix may be quite a bit smaller than a /3, which is what an FP is. So, IMO, actually removing the FP from the document is a reasonable approach. If there is no FP, implementations won't make the mistake of looking at just those bits and doing the wrong thing. [Note: whether the current text is adequately clear on all this is something I haven't checked. My comments are on the rational for not having an FP.] 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 Sep 14 14:20:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ELKD7B003397 for ; Fri, 14 Sep 2001 14:20:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8ELKDGk003396 for ipng-dist; Fri, 14 Sep 2001 14:20: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+Sun/8.12.0) with ESMTP id f8ELKA7B003389 for ; Fri, 14 Sep 2001 14:20:10 -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 OAA08458; Fri, 14 Sep 2001 14:20:31 -0700 (PDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23979; Fri, 14 Sep 2001 14:20:30 -0700 (PDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [192.168.1.107]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id RAA28766; Fri, 14 Sep 2001 17:19:05 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id RAA27678; Fri, 14 Sep 2001 17:20:01 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id RAA29521; Fri, 14 Sep 2001 17:17:11 -0400 Message-Id: <200109142117.RAA29521@rotala.raleigh.ibm.com> To: Alex Conta cc: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-Reply-To: Message of "Fri, 14 Sep 2001 11:36:28 EDT." <3BA223FC.4F368BFD@txc.com> Date: Fri, 14 Sep 2001 17:17:11 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > While I think an implementation does not have to explicitly be > concerned about Prefix Format bits, since the bits are automatically > included in a prefix, I am quite concerned about the fact that at > this moment the entire IPv6 space is allocated, with no > experimental, or reserved space for future development. "allocated" is probably the wrong word. "assigned (and in use)" is what I think is important. Once a swath of address space is assigned (and used) for some purpose, it's hard to take it back for some other use. The current ID defines some ranges of address for special purposes, but says the rest should be treated (from an implementation perspective) as global unicast. I.e., treat them all the same. If, at some future point, someone wants to experiment and needs a range of address that it will treat "differently", all that needs to happen is that it obtain a big enough range of addresses for its purpose. As long as there is such a range of addresses that is not in use by anyone, this isn't a problem. As Randy has pointed out, the IANA considerations section in the ID makes it clear that only 1/8th of the available space is being made available for usage and assignment. So we still have lots of space to use differently, should someone make the case that we need to. > Carving out such a space ahead of time, like in IPv4, worked well. It > provides the benefit that if people experiment with a number of > addresses, they know ahead of time, what they have available, and will > not conflict with global addresses, or other addresses, already > in use. Actually, reserving an experimental range in advance, is not the best way to do it. You might reserve too much or too little. Hard to tell in advance what the future will bring. The better approach is to assign address space for use in a way that allows one to put off for as long as possible making the decision on how big a range to reserve for one purpose vs. another. Leave things flexible for a future that is hard to predict. 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 Sep 14 15:55:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EMtj7B003674 for ; Fri, 14 Sep 2001 15:55:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EMtjcX003673 for ipng-dist; Fri, 14 Sep 2001 15:55:45 -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+Sun/8.12.0) with ESMTP id f8EMtf7B003666 for ; Fri, 14 Sep 2001 15:55:41 -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 PAA14752; Fri, 14 Sep 2001 15:56:01 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13357; Fri, 14 Sep 2001 16:55:56 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id SAA07404; Fri, 14 Sep 2001 18:57:10 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id SAA10501; Fri, 14 Sep 2001 18:57:07 -0400 Message-ID: <3BA28B2F.954CB7C8@txc.com> Date: Fri, 14 Sep 2001 18:56:47 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <200109142117.RAA29521@rotala.raleigh.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms610B00506665EA9EA44CAAD7" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms610B00506665EA9EA44CAAD7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Narten wrote: > [...] > The current ID defines some ranges of address for special purposes, > but says the rest should be treated (from an implementation > perspective) as global unicast. I.e., treat them all the same. > OK. Your clarification is useful, since this is really what I had in mind. Perhaps the text in the draft could be made more clear - something closer to yours. > [..] > As Randy has pointed out, the IANA considerations section in the ID > makes it clear that only 1/8th of the available space is being made > available for usage and assignment. So we still have lots of space to > use differently, should someone make the case that we need to. > Two comments relative to this - already made earlier. a. Since I missed the earlier opportunity, I am bringing this feedback now, sorry. I would have been happier if the clarification was up front, like having a section on address space partitioning, like I suggested in some text sent earlier, or some text at the beginning in the IANA section, rather than some text in a "foot-note". b. The IANA considerations text is in Appendix C, after 2 informational appendices. Shouldn't the section be "normative", and part of the main document, rather than an appendix ? > > Carving out such a space ahead of time, like in IPv4, worked well. It > > provides the benefit that if people experiment with a number of > > addresses, they know ahead of time, what they have available, and will > > not conflict with global addresses, or other addresses, already > > in use. > > Actually, reserving an experimental range in advance, is not the best > way to do it. You might reserve too much or too little. Hard to tell > in advance what the future will bring. I am not talking about a large chunk. A tiny space can always be extended, if someone needs bigger space, for a new thing, which seems more than just an experiment, or it can ask for a separate new assignment. Having that tiny space ahead of time, saves the time of going and asking for it, in particular for temporary experiments, kind of like what D, and E, where in IPv4.... The effort of getting an assignment should take place only if the assignment is (quasi-)permanent. This is my opinion, based on past and current experience. > [..] > Thomas Alex --------------ms610B00506665EA9EA44CAAD7 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTQyMjU2NDhaMCMGCSqGSIb3DQEJBDEWBBT7FnjgtvkOqDKQ8rY4 GdDowvrk3TBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gAXdjIwBu1QQsZk6u7ZbywEj6plIytE8EgOgRVIzEMvp6vsCGPqR9jwzHB8Jdo9p/Qq2bJD7 /+dfBz4/+KXZ6zzcwzyBr6pLLBJvUpc6xcgqrWF2Oi9lM+7sZvRo2OfvnkvqePjWvIkYP+He MsOKpdFqxlL89/us6lXbDO+Xsxej --------------ms610B00506665EA9EA44CAAD7-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 15:59:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8EMxR7B003698 for ; Fri, 14 Sep 2001 15:59:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8EMxRFs003697 for ipng-dist; Fri, 14 Sep 2001 15:59: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+Sun/8.12.0) with ESMTP id f8EMxN7B003690 for ; Fri, 14 Sep 2001 15:59:24 -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 PAA15630; Fri, 14 Sep 2001 15:59:44 -0700 (PDT) Received: from mailhub.txc.com (transfire.txc.com [208.5.237.254]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA15163; Fri, 14 Sep 2001 17:00:27 -0600 (MDT) Received: from jade.txc.com (jade.txc.com [198.138.97.40]) by mailhub.txc.com (8.9.3/8.9.3) with SMTP id TAA07452; Fri, 14 Sep 2001 19:00:54 -0400 Received: from txc.com by jade.txc.com (SMI-8.6/SMI-SVR4) id TAA10619; Fri, 14 Sep 2001 19:00:54 -0400 Message-ID: <3BA28C13.C4DED2C6@txc.com> Date: Fri, 14 Sep 2001 19:00:35 -0400 From: Alex Conta X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <3B9916AD.11C4FDB1@hursley.ibm.com> <3BA223FC.4F368BFD@txc.com> <3BA24E65.3334740@txc.com> <3BA25ECB.84A401A5@txc.com> <3BA26A80.8B586582@txc.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msC7B4781FDC1FC0790F1FE0F5" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------msC7B4781FDC1FC0790F1FE0F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Bush wrote: > > > > > Could you elaborate on the exact reasons? > > because we remember implementations and protocols that had A, B, and C hard > coded and how hard it was getting cidr deployed. > [...] Thanks. Yours and Thomas's were useful clarifications. --------------msC7B4781FDC1FC0790F1FE0F5 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKMQYJKoZIhvcNAQcCoIIKIjCCCh4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B70wggSHMIID8KADAgECAhBmfn1HDi4lGwF60JV5IuR7MA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAwMDkyNjAwMDAw MFoXDTAxMDkyNjIzNTk1OVowggELMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFsZXggQ29udGExHTAbBgkqhkiG9w0B CQEWDmFjb250YUB0eGMuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC+BilF+LEo x0rhxqMsHXVa+gyHyrH2EtFEzHpahyckngPWpr7Qs84/urQzbXrfENmUFceQwz0Vgy2pu4/h 6IdnwspvjPpN5TIsFb+zE4+3FnFfiBCjO/lLk4I55n7s6xGuHh6ndOm57diHpLYg5x/xVbLI 4UFfkNiF0zCHPd5qjQIDAQABo4IBJjCCASIwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CG SAGG+EUBBwEIMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEw EQYJYIZIAYb4QgEBBAQDAgeAMIGGBgpghkgBhvhFAQYDBHgWdmQ0NjUyYmQ2M2YyMDQ3MDI5 Mjk4NzYzYzlkMmYyNzUwNjljNzM1OWJlZDFiMDU5ZGE3NWJjNGJjOTcwMTc0N2RhNWQzZjIx NDFiZWFkYjJiZDJlODkyMTZhYjYyZjFkNDExNDk5Y2EzYmU0N2ZkZjNlYTQ1MGMwMwYDVR0f BCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNybDANBgkqhkiG 9w0BAQQFAAOBgQBrO9RNDzCcKmFVXb2puL1VbHA0VqjhaD4Gm10zfjihYsLx2XzTWdvd8tBR 29HcF4WYOaw4r3Kbp2rttSCIbei8OgDOCPZcsGZEvLYho0PsocJV4saVsPEWq8n0Xxoz5qkV rBHXl0X4CvFYvbdjZiPJs2Gs4DwTe3AFi9WhFDyiJDCCAy4wggKXoAMCAQICEQDSdi6NFAw9 fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0wODA1MTIyMzU5NTlaMIHMMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFG MEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJl Zi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlk dWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMIGfMA0GCSqGSIb3DQEBAQUA A4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqyb5xUv7zodyqdufBou5XZMUFweoFL uUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScKXbawNkIztW5UiE+HSr8Z2vkV6A+H thzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQIDAQABo3wwejARBglghkgBhvhCAQEE BAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUFBwIBFh93d3cudmVy aXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQIMAYBAf8CAQAwCwYDVR0PBAQDAgEG MA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GBAXEekmptL/bxndPKZDjcG5gMB4Zb hRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq+jPHvhnXU0zDvcjjF7WkSUJj7MKm Fw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvDzQWikK5uMYICPDCCAjgCAQEwgeEw gcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29y cC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENB IEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEGZ+fUcOLiUb AXrQlXki5HswCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMTA5MTQyMzAwMzVaMCMGCSqGSIb3DQEJBDEWBBTdxfnO6wv8HJ85FjgV s23mYhffLDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAH BgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASB gFmF5mWaMZpPVly0tu8sPDxwY5tNdzhzC0b/921vUABvFZKpjhgNYS0jVG1jHaNXGQONGTUa EeELXzccoBHNzoXehWeqQbsPVNm4ZLz/Y2SPGwMqnJv6uzZ+nRVaHt3roifqjjTo3x2g92Tw vgdkVnzSnBL4mdGjF4tBf3G1ke7r --------------msC7B4781FDC1FC0790F1FE0F5-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 16:56:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ENus7B003844 for ; Fri, 14 Sep 2001 16:56:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8ENurno003843 for ipng-dist; Fri, 14 Sep 2001 16:56: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+Sun/8.12.0) with ESMTP id f8ENuk7B003823 for ; Fri, 14 Sep 2001 16:56:46 -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 QAA28499 for ; Fri, 14 Sep 2001 16:54:46 -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 RAA04745 for ; Fri, 14 Sep 2001 17:55:30 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 1CD9A4B20; Sat, 15 Sep 2001 08:54:39 +0900 (JST) To: Randy Bush Cc: Alex Conta , Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com In-reply-to: randy's message of Fri, 14 Sep 2001 15:51:49 -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: W.G. Last Call on "IP Version 6 Addressing Architecture" From: itojun@iijlab.net Date: Sat, 15 Sep 2001 08:54:39 +0900 Message-ID: <6686.1000511679@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Unassigned: >> >> 6/8 + 57/512 (2.5521177519070384759753095557382e+38 >> + 3.788299787987010237775850121799e+37 >> of addresses) >> This is the remaining of the address space, which has not >> been assigned. for implementers, it needs to be known that the unassigned region is unicast addresses, not just "unassigned". otherwise, implemnters cannot implement the code to handle these "future allocation" addresses. in my understanding this is the main reason for the wording change between RFC and i-d. 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 Sep 14 17:51:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8F0pX7B004044 for ; Fri, 14 Sep 2001 17:51:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8F0pXg0004043 for ipng-dist; Fri, 14 Sep 2001 17: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8F0pT7B004036 for ; Fri, 14 Sep 2001 17:51: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 RAA07718 for ; Fri, 14 Sep 2001 17:51:51 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA02880 for ; Fri, 14 Sep 2001 17:51:51 -0700 (PDT) Received: from 157.54.9.108 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 Sep 2001 17:51:01 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 17:51:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 14 Sep 2001 17:51:00 -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.2966); Fri, 14 Sep 2001 17:50:22 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.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 "IP Version 6 Addressing Architecture" Date: Fri, 14 Sep 2001 17:50:22 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "IP Version 6 Addressing Architecture" Thread-Index: AcE9elEdU+hhFypFRIaMoabH0QSJyAABdTdw From: "Christian Huitema" To: , "Randy Bush" Cc: "Alex Conta" , "Brian E Carpenter" , "Erik Nordmark" , "Bob Hinden" , X-OriginalArrivalTime: 15 Sep 2001 00:50:22.0746 (UTC) FILETIME=[6679EFA0:01C13D80] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8F0pU7B004037 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> Unassigned: > >> > >> 6/8 + 57/512 (2.5521177519070384759753095557382e+38 > >> + > 3.788299787987010237775850121799e+37 > >> of addresses) > >> This is the remaining of the address space, which > has not > >> been assigned. > > for implementers, it needs to be known that the unassigned > region is > unicast addresses, not just "unassigned". > otherwise, implemnters cannot implement the code to handle these > "future allocation" addresses. in my understanding this is the > main reason for the wording change between RFC and i-d. Second that. We have to be able to decide thinks like "address scope" and "address type", in order to implement requirements such as "addresses used in this context must be global scope unicast addresses." If we want compatibility with future assignments, that should not be done by testing for 200::/3... -- 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 Sep 16 23:47:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8H6lf7B006228 for ; Sun, 16 Sep 2001 23:47:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8H6lfOd006227 for ipng-dist; Sun, 16 Sep 2001 23:47: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+Sun/8.12.0) with ESMTP id f8H6la7B006220 for ; Sun, 16 Sep 2001 23:47:38 -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 XAA10551 for ; Sun, 16 Sep 2001 23:47:58 -0700 (PDT) Received: from telecom.samsung.co.kr ([165.213.221.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA03552 for ; Mon, 17 Sep 2001 00:48:41 -0600 (MDT) Received: from cychong (a22416 [165.213.224.16]) by telecom.samsung.co.kr (8.11.6/8.11.6) with SMTP id f8H6lhP28698; Mon, 17 Sep 2001 15:47:43 +0900 (KST) Message-ID: <000501c13f45$856f1ef0$10e0d5a5@cychong> From: "Chae-yong Chong" To: , References: <6686.1000511679@itojun.org> Subject: Question about draft-ietf-ngtrans-introduction... Date: Mon, 17 Sep 2001 15:53:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f8H6lc7B006221 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi When I read a draft "An overview of the introduction of IPv6 in the internet" I got some ambigous statement in 4.1.3 4.1.3 Tunnel Broker ... IPv4 address requirements : 1 ... What does that "1" means? Does that mean Tunnel Broker's IPv4 address? In other section, there always some more description like "1 per host" or ">=1 per site" In my understanding that should be corrected like "1 per host". Chae-yong -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 01:43:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8H8hc7B006364 for ; Mon, 17 Sep 2001 01:43:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8H8hcTx006363 for ipng-dist; Mon, 17 Sep 2001 01:43:38 -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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8H8hX7B006356 for ; Mon, 17 Sep 2001 01:43:33 -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 f8H8hsr28534; Mon, 17 Sep 2001 10:43:55 +0200 (MET DST) Date: Mon, 17 Sep 2001 10:39:45 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: uni-based-mcast and malloc-ipv6-guide To: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu 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 some comments and questions on the related drafts. > draft-ietf-ipngwg-uni-based-mcast-02.txt It would be quite useful to outline a bit more of the problem that needs solving in the introduction. It would also be useful to have a comparision with IPv4 (either in the introduction or later in the document). Questions I'd like to see answered is whether there are approaches and protocols used for IPv4 multicast address allocation that is effectively replaced by the techniques in the draft i.e. whether the WGs believe that some mechanisms and protocols that do not need to be carried forward to IPv6. The first part of section 3 should presumably refer to and use the picture from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373. The description of the fields in section 3 should at a minimum describe the group ID field by having a reference to draft-ietf-malloc-ipv6-guide-03.txt I wonder if it also makes sense to carry some information from that document into this one; e.g. the fact that the high-order bit of the group ID must be zero for these types of addresses. Will the unicast prefix based addresses ever need to use the link-local prefix? If not it might make sense to explicitly ban that where it talks about scope in section 3. The last paragraph in section 3 is about lifetimes. I don't understand what the intended effect is of the statement since I don't know what the lifetime is of a multicast address. Is the intent that e.g. if the prefixes are advertised with a 1 day valid lifetime, that an implementation MUST NOT use multicast addresses derived from those prefixes in SDP advertisements that end beyond 1 day ahead? If the intent is to really be that strict the document definitely needs to be a lot more specific on this point. But I don't see a need to be that strict - all these multicast addresses are temporary - is there any real danger is for some applications "temporary" spans unicast prefix renumbering events? > draft-ietf-malloc-ipv6-guide-03.txt The name of the reference [NEW ARCH] confused me - I was sure it was addr-arch-v3. How about "UNICAST PREFIX" or [3] instead? Section 3 - bullet on SSM. This says that there is a 96 bit multicast prefix but the other drafts says it must be zero. Why not explicitly say zero here as well? Otherwise folks can be lead to believe they can create non-zero middle bits for SSM addresses. (If this change is done the second bullet would need to be rewritten since it refers to SSM.) Section 5 on randomness says: The group ID portion of the address is set using either a pseudo- random 32-bit number or a 32-bit number created using the guidelines in [RFC 1750]. Possible approaches to creating a pseudo-random number include using an MD5 message-digest [RFC 1321] or portions of an NTP [RFC 1305] timestamp. I think the second sentence should be dropped since it could easily be read as taking the MD5 digest of a constrant string, or the current year+month (high-order bits of timestamp), are good enough as random numbers. Thus the paragraph on high-order but set to '1' imply that the high-order bit should always be the same as the T flag in the address? If so it would make sense to explicitly state that. If not I'd like to understand the relationship between the two better. IANA considerations section seem to be incorrect on the last range. The intent as I understand it is not allow private use but that the range is reserved for use that conforms to this specification (i.e. random group IDs). Also, the IANA considerations seem to be missing the request that IANA establish a new registry for permanent group IDs (range 0x40000000-0x7fffffff) which is different than the existing registry for IPv6 multicast addresses. 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 Sep 17 04:32:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HBWq7B006507 for ; Mon, 17 Sep 2001 04:32:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HBWqm1006506 for ipng-dist; Mon, 17 Sep 2001 04:32:52 -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+Sun/8.12.0) with ESMTP id f8HBWk7B006499 for ; Mon, 17 Sep 2001 04:32: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 EAA12149 for ; Mon, 17 Sep 2001 04:33:04 -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 EAA07319 for ; Mon, 17 Sep 2001 04:33:03 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 538E14B20 for ; Mon, 17 Sep 2001 20:32:56 +0900 (JST) To: ipng Subject: flowlabel 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 From: itojun@iijlab.net Date: Mon, 17 Sep 2001 20:32:56 +0900 Message-ID: <849.1000726376@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, if someone could summarize the conclusion of the die-hard-only flowlabel discussion, I would love to hear that. (in my understanding it was"complete lack of consensus", am I correct?) Just curious as I'm feeling a bit of responsbility for draft-itojun-ipv6-flowlabel-api-01.txt. 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 Sep 17 07:11:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HEBo7B006667 for ; Mon, 17 Sep 2001 07:11:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HEBobo006666 for ipng-dist; Mon, 17 Sep 2001 07:11: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+Sun/8.12.0) with ESMTP id f8HEBj7B006659 for ; Mon, 17 Sep 2001 07:11: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 HAA02668 for ; Mon, 17 Sep 2001 07:12:02 -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 HAA09830 for ; Mon, 17 Sep 2001 07:11:58 -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 JAA125964 for ; Mon, 17 Sep 2001 09:09:33 -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.98) with ESMTP id f8HEBhA53940 for ; Mon, 17 Sep 2001 10:11:43 -0400 Importance: Normal Subject: RAW sockets and protocols To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Lori Napoli" Date: Mon, 17 Sep 2001 10:11:11 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/17/2001 10:11:43 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For RAW sockets, an application can use any procotol for IPv4. In IPv6, I imagine there are problems if a RAW application opens a socket and uses a known IPv6 extension header number as the protocol since now the IP layer will expect that next header field to be an extension header. Therefore, is it a restriction now that an IPv6 RAW application cannot use an known IPv6 extension header as the protocol on the socket call? 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 Mon Sep 17 08:41:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HFf07B006812 for ; Mon, 17 Sep 2001 08:41:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HFf0li006811 for ipng-dist; Mon, 17 Sep 2001 08:41: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+Sun/8.12.0) with ESMTP id f8HFet7B006804 for ; Mon, 17 Sep 2001 08:40: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 IAA15686 for ; Mon, 17 Sep 2001 08:41:13 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27277 for ; Mon, 17 Sep 2001 08:41:12 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA14722; Mon, 17 Sep 2001 16:41:10 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id QAA59298; Mon, 17 Sep 2001 16:41:10 +0100 Message-ID: <3BA618C8.7FDF5A6E@hursley.ibm.com> Date: Mon, 17 Sep 2001 10:37:44 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: itojun@iijlab.net CC: ipng Subject: Re: flowlabel References: <849.1000726376@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, I believe that Jarno, Alex and I (partly inspired by Christian) have some idea how to write a draft that would allow some progress. However, this will take some time. Personally, I am about to disappear into a logistics black hole due to my impending move to the IBM Zurich Lab, made worse by last week's disaster. I will get back to this in a few weeks. Brian itojun@iijlab.net wrote: > > So, if someone could summarize the conclusion of the die-hard-only > flowlabel discussion, I would love to hear that. (in my understanding > it was"complete lack of consensus", am I correct?) > > Just curious as I'm feeling a bit of responsbility for > draft-itojun-ipv6-flowlabel-api-01.txt. > > 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 Sep 17 09:19:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HGJD7B006909 for ; Mon, 17 Sep 2001 09:19:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HGJDbg006908 for ipng-dist; Mon, 17 Sep 2001 09:19: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+Sun/8.12.0) with ESMTP id f8HGJ97B006901 for ; Mon, 17 Sep 2001 09:19:09 -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 JAA28625 for ; Mon, 17 Sep 2001 09:19:28 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA19678 for ; Mon, 17 Sep 2001 09:19:26 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 09:18:44 -0700 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.2966); Mon, 17 Sep 2001 09:18:44 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 09:18:40 -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.2966); Mon, 17 Sep 2001 09:17:54 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 09:17:10 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB7D61@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/Vj6AdMGnYsMHTPuci1roawbvtwAPIQpQ From: "Dave Thaler" To: "Erik Nordmark" , , X-OriginalArrivalTime: 17 Sep 2001 16:17:54.0579 (UTC) FILETIME=[4E613E30:01C13F94] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HGJ97B006902 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, I'll let Brian respond to the editorial comments, but to quickly answer a few of your questions: > Will the unicast prefix based addresses ever need to use the link-local > prefix? Need? No, since it could only ever be used for link-local multicast groups, and for that scope they don't buy you anything. > If not it might make sense to explicitly ban that where it talks about > scope > in section 3. Doesn't matter to me. Technically it doesn't hurt anything to allow them. Whether it would be operationally clearer to allow or disallow them, I don't know. > The last paragraph in section 3 is about lifetimes. > I don't understand what the intended effect is of the statement > since I don't know what the lifetime is of a multicast address. See RFC 2908. > Is the intent that e.g. if the prefixes are advertised with a 1 day valid > lifetime, that an implementation MUST NOT use multicast addresses derived > from those prefixes in SDP advertisements that end beyond 1 day ahead? Yes. > If the intent is to really be that strict the document definitely needs > to be a lot more specific on this point. But I don't see a need to be > that strict - all these multicast addresses are temporary - is there > any real danger is for some applications "temporary" spans unicast > prefix renumbering events? Yes. The operational danger is confusion and failure to diagnose problems in a timely fashion. (Same as would happen today in IPv4 if people started using others' AS numbers in their multicast groups.) The performance danger is possible collisions (specifically when the group ID is IANA assigned or algorithmically generated) between the old prefix owner and the new prefix owner. -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 Mon Sep 17 11:20:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HIKe7B007033 for ; Mon, 17 Sep 2001 11:20:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HIKe7F007032 for ipng-dist; Mon, 17 Sep 2001 11:20: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+Sun/8.12.0) with ESMTP id f8HIKa7B007025 for ; Mon, 17 Sep 2001 11:20: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 LAA25600; Mon, 17 Sep 2001 11:20:54 -0700 (PDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09679; Mon, 17 Sep 2001 12:21:38 -0600 (MDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [192.168.1.108]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id OAA30238; Mon, 17 Sep 2001 14:20:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id OAA30750; Mon, 17 Sep 2001 14:20:49 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id OAA03736; Mon, 17 Sep 2001 14:17:21 -0400 Message-Id: <200109171817.OAA03736@rotala.raleigh.ibm.com> To: "Dave Thaler" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide In-Reply-To: Message of "Mon, 17 Sep 2001 09:17:10 PDT." <2E33960095B58E40A4D3345AB9F65EC102DB7D61@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 17 Sep 2001 14:17:21 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The last paragraph in section 3 is about lifetimes. > > I don't understand what the intended effect is of the statement > > since I don't know what the lifetime is of a multicast address. > See RFC 2908. 2908 seems to say mcast addresses have a start and end lifetime. That makes sense. What I think is potentially significantly different with the approach described in *this* document is that the lifetimes are much shorter. I.e., it is conceivable that unicast addresses will be advertised with prefixes of several days or a week in common cases. That doesn't mean the addresses will expire then, just that short unicast lifetimes are being advertised, just in case, it becomes necessary to deprecate the address relatively quickly. However, if multicast addresses derive their lifetimes from the same lifetime, there may be a mismatch in expectations. Seems to me that it might very well cause problems for multicast applications that request an address with a start and end time that don't match the advertised lifetimes of unicast addresses. I wonder if this point should to be discussed in the document explicitely. I.e., seems like this is a potential difference between IPv4 multicast and IPv6 multicast. We should be making such differences very clear to minimize confusion, if nothing else. Will the tying of mcast adddresses to unicast lifetimes put additional pressure on using longer unicast lifetimes? Is this a good thing? What are typical start and end times that folks use in IPv4 today? Do they match expectations for unicast lifetimes in IPv6? 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 Mon Sep 17 11:27:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HIRH7B007074 for ; Mon, 17 Sep 2001 11:27:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HIRHVh007073 for ipng-dist; Mon, 17 Sep 2001 11:27: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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HIRB7B007066 for ; Mon, 17 Sep 2001 11:27:12 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HIRIr28590; Mon, 17 Sep 2001 20:27:18 +0200 (MET DST) Date: Mon, 17 Sep 2001 20:23:07 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC102DB7D61@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 > See RFC 2908. At least that reference is missing from the document. But I see a mismatch between the draft and RFC 2908 since the latter seems to say that an application can request multicast addresses with a particular lifetime. With the uni-based addresses there can be no way for the application to request a lifetime. How can this be resolved? > > Is the intent that e.g. if the prefixes are advertised with a 1 day > valid > > lifetime, that an implementation MUST NOT use multicast addresses > derived > > from those prefixes in SDP advertisements that end beyond 1 day ahead? > > Yes. If that is indeed the WG consensus then this should be made very clear in the draft. 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 Sep 17 12:10:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HJAR7B007262 for ; Mon, 17 Sep 2001 12:10:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HJAR1u007261 for ipng-dist; Mon, 17 Sep 2001 12:10:27 -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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HJAL7B007254 for ; Mon, 17 Sep 2001 12:10:22 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HJAXr00489; Mon, 17 Sep 2001 21:10:34 +0200 (MET DST) Date: Mon, 17 Sep 2001 21:06:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RAW sockets and protocols To: Lori Napoli 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 > For RAW sockets, an application can use any procotol for IPv4. In IPv6, I > imagine there are problems if a RAW application opens a socket and uses a > known IPv6 extension header number as the protocol since now the IP layer > will expect that next header field to be an extension header. Therefore, > is it a restriction now that an IPv6 RAW application cannot use an known > IPv6 extension header as the protocol on the socket call? Good question. I suspect this is implementation dependent since the Advanced API is silent on the issue. What do different implementations do? My guess (from the structure of the code - I haven't run a test) is that Solaris will not return an error to the socket call, but that the socket will not receive any packets since the extension header processing in IP will take precendence. 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 Sep 17 12:26:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HJQm7B007304 for ; Mon, 17 Sep 2001 12:26:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HJQmTL007303 for ipng-dist; Mon, 17 Sep 2001 12:26: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+Sun/8.12.0) with ESMTP id f8HJQh7B007296 for ; Mon, 17 Sep 2001 12:26:44 -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 MAA19730 for ; Mon, 17 Sep 2001 12:27:02 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA03425 for ; Mon, 17 Sep 2001 13:26:54 -0600 (MDT) Received: from 157.54.9.104 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 12:26:28 -0700 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.2966); Mon, 17 Sep 2001 12:26:28 -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.2966); Mon, 17 Sep 2001 12:26:25 -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); Mon, 17 Sep 2001 12:25:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 12:25:13 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/plb2CbptxLTwSW22z9tK1HZw1wAB8OBA From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2001 19:25:43.0701 (UTC) FILETIME=[8B4CCC50:01C13FAE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HJQj7B007297 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, September 17, 2001 11:23 AM > > > See RFC 2908. > > At least that reference is missing from the document. > But I see a mismatch between the draft and RFC 2908 since the latter > seems to say that an application can request multicast addresses with > a particular lifetime. With the uni-based addresses there can be no > way for the application to request a lifetime. > How can this be resolved? What makes you think there isn't a way for the app to request a lifetime? RFC 2771 applies to all dynamic multicast addresses. -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 Mon Sep 17 12:37:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HJbi7B007327 for ; Mon, 17 Sep 2001 12:37:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HJbiLu007326 for ipng-dist; Mon, 17 Sep 2001 12:37:44 -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+Sun/8.12.0) with ESMTP id f8HJbb7B007319 for ; Mon, 17 Sep 2001 12:37: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 MAA22209 for ; Mon, 17 Sep 2001 12:37:55 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA04769 for ; Mon, 17 Sep 2001 12:37:54 -0700 (PDT) Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 12:35:44 -0700 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); Mon, 17 Sep 2001 12:35:44 -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); Mon, 17 Sep 2001 12:35:44 -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); Mon, 17 Sep 2001 12:34:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 12:34:06 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/pWy6KN2XSVbBTj+hQ+meoKxiQAACSh0Q From: "Dave Thaler" To: "Thomas Narten" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2001 19:34:59.0166 (UTC) FILETIME=[D66207E0:01C13FAF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HJbd7B007320 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Monday, September 17, 2001 11:17 AM > > > > The last paragraph in section 3 is about lifetimes. > > > I don't understand what the intended effect is of the statement > > > since I don't know what the lifetime is of a multicast address. > > > See RFC 2908. > > 2908 seems to say mcast addresses have a start and end lifetime. That > makes sense. What I think is potentially significantly different with > the approach described in *this* document is that the lifetimes are > much shorter. I.e., it is conceivable that unicast addresses will be > advertised with prefixes of several days or a week in common > cases. That doesn't mean the addresses will expire then, just that > short unicast lifetimes are being advertised, just in case, it becomes > necessary to deprecate the address relatively quickly. However, if > multicast addresses derive their lifetimes from the same lifetime, > there may be a mismatch in expectations. How so? One can renew multicast addresses. (Conceivably an implementation could support the ability to automatically renew multicast addresses as long as the unicast address stays valid.) If the multicast address is being advertised with say SAP, each SAP advertisements can contain the extended lifetime, just like RAs do for unicast prefixes. > Seems to me that it might very well cause problems for multicast > applications that request an address with a start and end time that > don't match the advertised lifetimes of unicast addresses. If so, the same problems exist with any SSM channel that an app uses. > I wonder if this point should to be discussed in the document > explicitely. I.e., seems like this is a potential difference between > IPv4 multicast and IPv6 multicast. We should be making such > differences very clear to minimize confusion, if nothing else. I don't think there's any difference between IPv4 and IPv6 multicast, can you elaborate? (By the way, you should see a uni-based-mcast draft for IPv4 sometime before next IETF.) > Will the tying of mcast adddresses to unicast lifetimes put additional > pressure on using longer unicast lifetimes? Is this a good thing? I don't know. > What are typical start and end times that folks use in IPv4 today? Anywhere from 1-hour duration, to maybe 6 months or so. > Do they match expectations for unicast lifetimes in IPv6? One option might be to make it a SHOULD NOT (for advertised multicast lifetime to exceed known unicast lifetime) with the note that after the unicast lifetime, there is no guarantee that packets will reach their destination. -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 Mon Sep 17 13:14:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKE17B007501 for ; Mon, 17 Sep 2001 13:14:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HKE19u007500 for ipng-dist; Mon, 17 Sep 2001 13:14: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+Sun/8.12.0) with ESMTP id f8HKDw7B007493 for ; Mon, 17 Sep 2001 13:13:58 -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 NAA29599; Mon, 17 Sep 2001 13:14:13 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21687; Mon, 17 Sep 2001 13:14:12 -0700 (PDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA14934; Mon, 17 Sep 2001 21:14:09 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id VAA22672; Mon, 17 Sep 2001 21:14:10 +0100 Message-ID: <3BA65723.E0F047C4@hursley.ibm.com> Date: Mon, 17 Sep 2001 15:03:47 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Thomas Narten CC: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" References: <200109142102.RAA29442@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: ... > Having a format prefix doesn't actually help in the overall scheme. If > at some point someone wants to reserve a swath of address space for > some special/experimental purpose (e.g., 8+8, etc.), that can be done > by simply reserving a specific prefix that is big enough to meet the > need. Moreover, that prefix may be quite a bit smaller than a /3, > which is what an FP is. Actually the former FP was clearly a variable length object. Anyway, I read you to mean that chopping out a large fraction of the global unicast space for son-of-8+8 is an option left open by this architecture. That's fine, as long as people realise that such addresses would contain mutable bits, with impact on checksum algorithms. 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 Mon Sep 17 13:15:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKFi7B007520 for ; Mon, 17 Sep 2001 13:15:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HKFi2W007519 for ipng-dist; Mon, 17 Sep 2001 13:15: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.Sun.COM (bebop.France.Sun.COM [129.157.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKFc7B007512 for ; Mon, 17 Sep 2001 13:15:38 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8HKFbr03608; Mon, 17 Sep 2001 22:15:41 +0200 (MET DST) Date: Mon, 17 Sep 2001 22:11:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E73A@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 > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > Sent: Monday, September 17, 2001 11:23 AM > > > > > See RFC 2908. > > > > At least that reference is missing from the document. > > But I see a mismatch between the draft and RFC 2908 since the latter > > seems to say that an application can request multicast addresses with > > a particular lifetime. With the uni-based addresses there can be no > > way for the application to request a lifetime. > > How can this be resolved? > > What makes you think there isn't a way for the app to request a > lifetime? > RFC 2771 applies to all dynamic multicast addresses. Huh? How does the application requesting a particular lifetime effect the lifetime that the routers use when advertising the unicast prefix? Are you envisioning some new protocol to inform the routers (and the system admin, ISP, RIR) that allocated the unicast prefix that it needs to stay around for long enough to satisfy the applications request? :-) So while there might be an abstract API that allows the application to ask, the scheme in uni-based-mcast doesn't seem to have the pieces so that the system can honor such a request; at least not with a strict interpretation of the relationship between the RFC 2462 notion of lifetime of the unicast prefix, and the presumed lifetime of the derived multicast' address. Hence my question whether the intent is to have such a strict relationship or not. 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 Sep 17 13:28:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKS57B007573 for ; Mon, 17 Sep 2001 13:28:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HKS58d007572 for ipng-dist; Mon, 17 Sep 2001 13:28: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+Sun/8.12.0) with ESMTP id f8HKS17B007565 for ; Mon, 17 Sep 2001 13:28:01 -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 NAA03918 for ; Mon, 17 Sep 2001 13:28:20 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA19665 for ; Mon, 17 Sep 2001 14:28:12 -0600 (MDT) Received: from 157.54.1.52 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 13:27:48 -0700 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.2966); Mon, 17 Sep 2001 13:27: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); Mon, 17 Sep 2001 13:27:48 -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); Mon, 17 Sep 2001 13:27:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 13:26:26 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/tYLxrZH0ZEwFREK1ekPev20lOwAACppw From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 17 Sep 2001 20:27:02.0677 (UTC) FILETIME=[1C23FC50:01C13FB7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HKS27B007566 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, September 17, 2001 1:11 PM > To: Dave Thaler > Cc: Erik Nordmark; ipng@sunroof.eng.sun.com; malloc@catarina.usc.edu > Subject: RE: uni-based-mcast and malloc-ipv6-guide > > > > -----Original Message----- > > > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > > Sent: Monday, September 17, 2001 11:23 AM > > > > > > > See RFC 2908. > > > > > > At least that reference is missing from the document. > > > But I see a mismatch between the draft and RFC 2908 since the latter > > > seems to say that an application can request multicast addresses with > > > a particular lifetime. With the uni-based addresses there can be no > > > way for the application to request a lifetime. > > > How can this be resolved? > > > > What makes you think there isn't a way for the app to request a > > lifetime? > > RFC 2771 applies to all dynamic multicast addresses. > > Huh? > > How does the application requesting a particular lifetime effect the > lifetime that the routers use when advertising the unicast prefix? It doesn't. In the abstract API, the application supplies a minimum and desired lifetime. If the app says [0, 6 months] and the host knows that the unicast prefix is valid for 1 week, it can tell the app it has it for one week (and the app can renew it at any time). > Are you envisioning some new protocol to inform the routers (and the > system > admin, ISP, RIR) that allocated the unicast prefix that it needs to > stay around for long enough to satisfy the applications request? :-) Gosh I hope not :) > So while there might be an abstract API that allows the application > to ask, the scheme in uni-based-mcast doesn't seem to have the pieces > so that the system can honor such a request; at least not with a strict > interpretation of the relationship between the RFC 2462 notion of lifetime > of the unicast prefix, and the presumed lifetime of the derived multicast' > address. If the app says [6 months, 6 months] then personally I would expect the host to fail the request if it only has a unicast prefix lifetime of 1 week. I think your question is really: should we allow such a host to grant a request for 6 months if it only has a unicast prefix lifetime of 1 week? In my previous email, if there is a need to allow this (and I'm not saying there is), then we'd have to just say it SHOULD NOT, and say that after the unicast lifetime, the multicast packets are not guaranteed to be routed. > Hence my question whether the intent is to have such a strict relationship > or not. I'd like to hear others opinions, but I think that is the authors' intent. -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 Mon Sep 17 13:43:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKhL7B007692 for ; Mon, 17 Sep 2001 13:43:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HKhLp4007691 for ipng-dist; Mon, 17 Sep 2001 13:43: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+Sun/8.12.0) with ESMTP id f8HKhH7B007684 for ; Mon, 17 Sep 2001 13:43:17 -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 NAA07258; Mon, 17 Sep 2001 13:43:36 -0700 (PDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01760; Mon, 17 Sep 2001 14:43:28 -0600 (MDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [192.168.1.109]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id QAA16122; Mon, 17 Sep 2001 16:42:31 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id QAA30780; Mon, 17 Sep 2001 16:43:34 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA04527; Mon, 17 Sep 2001 16:40:05 -0400 Message-Id: <200109172040.QAA04527@rotala.raleigh.ibm.com> To: Brian E Carpenter cc: Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-Reply-To: Message of "Mon, 17 Sep 2001 15:03:47 CDT." <3BA65723.E0F047C4@hursley.ibm.com> Date: Mon, 17 Sep 2001 16:40:05 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter writes: > Actually the former FP was clearly a variable length object. Anyway, > I read you to mean that chopping out a large fraction of the global > unicast space for son-of-8+8 is an option left open by this > architecture. Yes. If someone comes along and makes a case that some chunk of address space needs to be reserved for a specific purpose other than global unicast addresses, that request would be evaluated on its merits when it is made. > That's fine, as long as people realise that such addresses would > contain mutable bits, with impact on checksum algorithms. Perhaps. :-) I.e., any proposal to reserve some swath of address space for some new purpose would presumably also explain how the space will be used, how nodes implementing the new service interact with devices that don't understand the new usage (if they need to), etc. 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 Mon Sep 17 13:48:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKmU7B007717 for ; Mon, 17 Sep 2001 13:48:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HKmUcO007716 for ipng-dist; Mon, 17 Sep 2001 13:48: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+Sun/8.12.0) with ESMTP id f8HKmQ7B007709 for ; Mon, 17 Sep 2001 13:48: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 NAA11706; Mon, 17 Sep 2001 13:48:45 -0700 (PDT) Received: from extmail02m.raleigh.ibm.com (extmail02.raleigh.ibm.com [204.146.167.243]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07896; Mon, 17 Sep 2001 13:48:44 -0700 (PDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [192.168.1.109]) by extmail02m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id QAA24302; Mon, 17 Sep 2001 16:47:11 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id QAA29594; Mon, 17 Sep 2001 16:48:15 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA04559; Mon, 17 Sep 2001 16:44:45 -0400 Message-Id: <200109172044.QAA04559@rotala.raleigh.ibm.com> To: Alex Conta cc: Brian E Carpenter , Erik Nordmark , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" In-Reply-To: Message of "Fri, 14 Sep 2001 18:56:47 EDT." <3BA28B2F.954CB7C8@txc.com> Date: Mon, 17 Sep 2001 16:44:45 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > b. The IANA considerations text is in Appendix C, after 2 > informational appendices. Shouldn't the section be "normative", and > part of the main document, rather than an appendix ? I'm not sure I agree with this assessment. I.e., all of the text in the document is normative, unless there is a specific disclaimer. I agree that most documents seem to put the IANA considerations section as a section near the end of the document (rather than in an Appendix), but that doesn't mean that the section is non-normative. > I am not talking about a large chunk. A tiny space can always be > extended, Actually, it can't always. I.e., if the space needs to be extended in a way (for example) that aggregates, that only works if the adjacent space is still unallocated at the time the extension is needed. 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 Mon Sep 17 13:55:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HKt27B007771 for ; Mon, 17 Sep 2001 13:55:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HKt2il007770 for ipng-dist; Mon, 17 Sep 2001 13:55:02 -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+Sun/8.12.0) with ESMTP id f8HKsx7B007763 for ; Mon, 17 Sep 2001 13:54:59 -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 NAA14173; Mon, 17 Sep 2001 13:55:17 -0700 (PDT) Received: from extmail01m.raleigh.ibm.com (extmail01.raleigh.ibm.com [204.146.167.242]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05625; Mon, 17 Sep 2001 14:56:04 -0600 (MDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [192.168.1.109]) by extmail01m.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.3) with ESMTP id QAB30536; Mon, 17 Sep 2001 16:55:15 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.2) with ESMTP id QAA29218; Mon, 17 Sep 2001 16:55:14 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id QAA04604; Mon, 17 Sep 2001 16:51:44 -0400 Message-Id: <200109172051.QAA04604@rotala.raleigh.ibm.com> To: "Dave Thaler" cc: "Erik Nordmark" , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide In-Reply-To: Message of "Mon, 17 Sep 2001 12:34:06 PDT." <2E33960095B58E40A4D3345AB9F65EC10290E73B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Mon, 17 Sep 2001 16:51:44 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > How so? One can renew multicast addresses. (Conceivably an > implementation could support the ability to automatically renew > multicast addresses as long as the unicast address stays valid.) Suppose I want to get a multicast address so I can advertise a session (e.g., on a web page). I do this two weeks in advance of the event. I want the address to last one day only. The key point is that I will want to use the address staring two weeks from now. However, because unicast lifetimes are only a week, that's too far into the future to actually get the address (yet), so the address can't be obtained yet. This would seem like it might be a problem. Is it? (I don't know how this scenario fits with the way multicast is actually used in IPv4, so this really is a question.) 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 Mon Sep 17 14:21:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HLLo7B007943 for ; Mon, 17 Sep 2001 14:21:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HLLoDs007942 for ipng-dist; Mon, 17 Sep 2001 14:21: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+Sun/8.12.0) with ESMTP id f8HLLk7B007935 for ; Mon, 17 Sep 2001 14:21:47 -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 OAA17732 for ; Mon, 17 Sep 2001 14:22:04 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25197 for ; Mon, 17 Sep 2001 14:22:03 -0700 (PDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f8HLM3720279 for ; Mon, 17 Sep 2001 16:22:03 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f8HLM3B02137 for ; Mon, 17 Sep 2001 16:22:03 -0500 (CDT) Received: from sureshpc (busam50.berkeley.us.am.ericsson.se [138.85.159.200]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA15982 for ; Mon, 17 Sep 2001 16:22:00 -0500 (CDT) Message-ID: <001001c13fbe$a50ccc20$b2aea8c0@erilab.com> From: "Suresh Krishnan" To: References: Subject: Contradiction in RFC1883 Date: Mon, 17 Sep 2001 14:20:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I might be totally wrong in this but I see that there are two contradicting statements in RFC1883 for IPv6. Can somebody please explain Page 7 statement a: Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). statement b: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. I am sorry if this has already been raised as a question and answered. Thanks in advance, Suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 14:37:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HLbe7B008027 for ; Mon, 17 Sep 2001 14:37:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HLbdki008026 for ipng-dist; Mon, 17 Sep 2001 14:37: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+Sun/8.12.0) with ESMTP id f8HLba7B008019 for ; Mon, 17 Sep 2001 14:37:36 -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 OAA22175 for ; Mon, 17 Sep 2001 14:37:53 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA28853 for ; Mon, 17 Sep 2001 15:38:41 -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 f8HLbqx05338; Mon, 17 Sep 2001 14:37:52 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ABJ73100; Mon, 17 Sep 2001 14:37:51 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <001001c13fbe$a50ccc20$b2aea8c0@erilab.com> References: <001001c13fbe$a50ccc20$b2aea8c0@erilab.com> Date: Mon, 17 Sep 2001 14:37:54 -0700 To: "Suresh Krishnan" From: Steve Deering Subject: Re: Contradiction in RFC1883 Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Suresh, This is just an example of the Internet robustness guideline: "be conservative in what you send and liberal in what you receive". If you recognize statement (a) as applying to senders, and (b) as applying to receivers, you will see that they are not contradictory. Also, note the "should" (rather than "must") in statement (a). Steve At 2:20 PM -0700 9/17/01, Suresh Krishnan wrote: >Hi all, > I might be totally wrong in this but I see that there are two >contradicting statements in RFC1883 for IPv6. Can somebody please explain > >Page 7 > >statement a: > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > >statement b: > IPv6 nodes must accept and attempt to process extension headers in > any order and occurring any number of times in the same packet, > except for the Hop-by-Hop Options header which is restricted to > appear immediately after an IPv6 header only. > >I am sorry if this has already been raised as a question and answered. > >Thanks in advance, >Suresh > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Sep 17 14:41:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HLex7B008044 for ; Mon, 17 Sep 2001 14:40:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HLex5R008043 for ipng-dist; Mon, 17 Sep 2001 14:40: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+Sun/8.12.0) with ESMTP id f8HLet7B008036 for ; Mon, 17 Sep 2001 14:40: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 OAA27189 for ; Mon, 17 Sep 2001 14:41:12 -0700 (PDT) Received: from inet-vrs-05.redmond.corp.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA18235 for ; Mon, 17 Sep 2001 15:41:04 -0600 (MDT) Received: from 157.54.1.52 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 14:39:00 -0700 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.2966); Mon, 17 Sep 2001 14:39:00 -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); Mon, 17 Sep 2001 14:39:00 -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); Mon, 17 Sep 2001 14:38:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 14:38:15 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/uvvke8mpwGIFSsCzYpJ7oEVqjAABI6cA From: "Dave Thaler" To: "Thomas Narten" Cc: "Erik Nordmark" , , X-OriginalArrivalTime: 17 Sep 2001 21:38:15.0915 (UTC) FILETIME=[0F305BB0:01C13FC1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HLeu7B008037 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Monday, September 17, 2001 1:52 PM > > > How so? One can renew multicast addresses. (Conceivably an > > implementation could support the ability to automatically renew > > multicast addresses as long as the unicast address stays valid.) > > Suppose I want to get a multicast address so I can advertise a session > (e.g., on a web page). I do this two weeks in advance of the event. I > want the address to last one day only. The key point is that I will > want to use the address staring two weeks from now. > > However, because unicast lifetimes are only a week, that's too far > into the future to actually get the address (yet), so the address > can't be obtained yet. This would seem like it might be a problem. Is > it? (I don't know how this scenario fits with the way multicast is > actually used in IPv4, so this really is a question.) This is a good question, and in fact it's not multicast specific. Here's the unicast equivalent: You're advertising a unicast streaming session on a web page that will start in two weeks (and last one day). You use a URL with a literal unicast address in it. However, you don't know from your RA that your address will definitely be the same by then. Again, this would seem like it might be a problem. I think the same dangers and possible solutions exist for both unicast and multicast. Some solutions, with varying degrees of "goodness", might include: 1) Change the web page if the address changes, and hope people don't use an out-of-date web page. 2) Don't use address literals in the URL, and hope that people don't resolve the name to an address until close to the session starts. 3) Make the admin have knowledge somehow that the address will indeed be valid throughout the life of the session advertised. The point is that pretty much any solution you use for unicast can be used for multicast as well. -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 Mon Sep 17 14:42:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HLgN7B008061 for ; Mon, 17 Sep 2001 14:42:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HLgNNP008060 for ipng-dist; Mon, 17 Sep 2001 14:42:23 -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+Sun/8.12.0) with ESMTP id f8HLgJ7B008053 for ; Mon, 17 Sep 2001 14:42:20 -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 OAA25956 for ; Mon, 17 Sep 2001 14:42:37 -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 OAA11270 for ; Mon, 17 Sep 2001 14:42:34 -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 QAA97210 for ; Mon, 17 Sep 2001 16:40:06 -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.98) with ESMTP id f8HLgOA172710 for ; Mon, 17 Sep 2001 17:42:24 -0400 Importance: Normal Sensitivity: Subject: Re: Contradiction in RFC1883 To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Mon, 17 Sep 2001 17:42:33 -0400 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 09/17/2001 05:42:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This same contradiction is in RFC 2460 (section 4.1) which obsoletes RFC 1883. Hi all, I might be totally wrong in this but I see that there are two contradicting statements in RFC1883 for IPv6. Can somebody please explain Page 7 statement a: Each extension header should occur at most once, except for the Destination Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). statement b: IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. I am sorry if this has already been raised as a question and answered. Thanks in advance, Suresh -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 14:48:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HLmr7B008089 for ; Mon, 17 Sep 2001 14:48:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HLmqZu008088 for ipng-dist; Mon, 17 Sep 2001 14:48: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+Sun/8.12.0) with ESMTP id f8HLmm7B008081 for ; Mon, 17 Sep 2001 14:48: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 OAA29500 for ; Mon, 17 Sep 2001 14:49:06 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA24299 for ; Mon, 17 Sep 2001 15:48:58 -0600 (MDT) Received: from 157.54.7.67 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 14:48:41 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 14: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.2966); Mon, 17 Sep 2001 14:48:36 -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); Mon, 17 Sep 2001 14:47:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Contradiction in RFC1883 Date: Mon, 17 Sep 2001 14:46:25 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E73F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Contradiction in RFC1883 thread-index: AcE/wAlj3xRAoZm9TkiWzI8DAI298wAAh4Dg From: "Dave Thaler" To: "Suresh Krishnan" Cc: X-OriginalArrivalTime: 17 Sep 2001 21:47:50.0255 (UTC) FILETIME=[6585AFF0:01C13FC2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HLmn7B008082 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is no contradiction here. (a) is talking about what nodes SHOULD send. (b) is talking about what nodes MUST be able to receive. -Dave > -----Original Message----- > From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] > Sent: Monday, September 17, 2001 2:21 PM > To: ipng@sunroof.eng.sun.com > Subject: Contradiction in RFC1883 > > Hi all, > I might be totally wrong in this but I see that there are two > contradicting statements in RFC1883 for IPv6. Can somebody please explain > > Page 7 > > statement a: > Each extension header should occur at most once, except for the > Destination Options header which should occur at most twice (once > before a Routing header and once before the upper-layer header). > > statement b: > IPv6 nodes must accept and attempt to process extension headers in > any order and occurring any number of times in the same packet, > except for the Hop-by-Hop Options header which is restricted to > appear immediately after an IPv6 header only. > > I am sorry if this has already been raised as a question and answered. > > Thanks in advance, > Suresh > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 17 14:52:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HLq97B008139 for ; Mon, 17 Sep 2001 14:52:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HLq9mK008138 for ipng-dist; Mon, 17 Sep 2001 14:52: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+Sun/8.12.0) with ESMTP id f8HLq47B008131 for ; Mon, 17 Sep 2001 14:52: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 OAA28548 for ; Mon, 17 Sep 2001 14:52:22 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15779 for ; Mon, 17 Sep 2001 14:52:22 -0700 (PDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GJT00ACOU3A2Y@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Mon, 17 Sep 2001 16:52:22 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f8HLqLm13725; Mon, 17 Sep 2001 16:52:21 -0500 (CDT) Date: Mon, 17 Sep 2001 16:52:21 -0500 From: Matt Crawford Subject: Re: Contradiction in RFC1883 In-reply-to: "17 Sep 2001 14:20:55 PDT." <001001c13fbe$a50ccc20$b2aea8c0@erilab.com> To: Suresh Krishnan Cc: ipng@sunroof.eng.sun.com Message-id: <200109172152.f8HLqLm13725@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I might be totally wrong in this but I see that there are two > contradicting statements in RFC1883 for IPv6. Can somebody please explain The apparent discrepancy is reconciled by the robustness principle. 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. This applies not only to TCP - see RFC 1812. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 15:20:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMKR7B008287 for ; Mon, 17 Sep 2001 15:20:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HMKRZp008286 for ipng-dist; Mon, 17 Sep 2001 15:20: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+Sun/8.12.0) with ESMTP id f8HMKN7B008279 for ; Mon, 17 Sep 2001 15:20: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 PAA08398 for ; Mon, 17 Sep 2001 15:20:41 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA17795 for ; Mon, 17 Sep 2001 16:20:33 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 15:20:33 -0700 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); Mon, 17 Sep 2001 15:20:31 -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); Mon, 17 Sep 2001 15:20:30 -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, 17 Sep 2001 15:19:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: PPPoE & IPv6: packet too long? Date: Mon, 17 Sep 2001 15:19:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPPoE & IPv6: packet too long? Thread-Index: AcE/w0rr6bteEzY6QN20UnamJNdTtwAAsRbA From: "Christian Huitema" To: "Steve Deering" Cc: X-OriginalArrivalTime: 17 Sep 2001 22:19:48.0319 (UTC) FILETIME=[DCC706F0:01C13FC6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HMKO7B008280 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk According to RFC 2516, PPPoE, the Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. If PPPoE implementations actually negotiated an MRU size of 1492 bytes, we would not have an issue. However, many implementations of PPPoE servers only support an MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6. What should we do? -- 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 Mon Sep 17 15:39:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMdR7B008442 for ; Mon, 17 Sep 2001 15:39:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HMdRBv008441 for ipng-dist; Mon, 17 Sep 2001 15:39:27 -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+Sun/8.12.0) with ESMTP id f8HMdK7B008434 for ; Mon, 17 Sep 2001 15:39:20 -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 PAA07460 for ; Mon, 17 Sep 2001 15:39:38 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05894 for ; Mon, 17 Sep 2001 15:39:38 -0700 (PDT) Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1081665; Mon, 17 Sep 2001 18:32:34 -0400 Message-ID: <3BA67BAD.8EC01AC8@21rst-century.com> Date: Mon, 17 Sep 2001 18:39:41 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Thomas Narten CC: Dave Thaler , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: <200109172051.QAA04604@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > How so? One can renew multicast addresses. (Conceivably an > > implementation could support the ability to automatically renew > > multicast addresses as long as the unicast address stays valid.) > > Suppose I want to get a multicast address so I can advertise a session > (e.g., on a web page). I do this two weeks in advance of the event. I > want the address to last one day only. The key point is that I will > want to use the address staring two weeks from now. > > However, because unicast lifetimes are only a week, that's too far > into the future to actually get the address (yet), so the address > can't be obtained yet. This would seem like it might be a problem. Is > it? (I don't know how this scenario fits with the way multicast is > actually used in IPv4, so this really is a question.) > > Thomas In IPv4 I would say, use a GLOP address for this. (We'll rent you one if you don't have any.) Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 15:41:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMfY7B008473 for ; Mon, 17 Sep 2001 15:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HMfYvO008472 for ipng-dist; Mon, 17 Sep 2001 15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMfU7B008465 for ; Mon, 17 Sep 2001 15:41:30 -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 PAA10736 for ; Mon, 17 Sep 2001 15:41:48 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02140 for ; Mon, 17 Sep 2001 16:42:34 -0600 (MDT) Received: from sp15en17.hursley.ibm.com (sp15at17.hursley.ibm.com [9.20.45.103]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA07670; Mon, 17 Sep 2001 23:41:43 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id XAA23070; Mon, 17 Sep 2001 23:41:45 +0100 Message-ID: <3BA67845.84C4A521@hursley.ibm.com> Date: Mon, 17 Sep 2001 17:25:09 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr MIME-Version: 1.0 To: Matt Crawford CC: Suresh Krishnan , ipng@sunroof.eng.sun.com Subject: Re: Contradiction in RFC1883 References: <200109172152.f8HLqLm13725@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The general statement is in RFC 1958: > 3.9 Be strict when sending and tolerant when receiving. > Implementations must follow specifications precisely when sending to > the network, and tolerate faulty input from the network. When in > doubt, discard faulty input silently, without returning an error > message unless this is required by the specification. Brian Matt Crawford wrote: > > > I might be totally wrong in this but I see that there are two > > contradicting statements in RFC1883 for IPv6. Can somebody please explain > > The apparent discrepancy is reconciled by the robustness principle. > > 2.10. Robustness Principle > > TCP implementations will follow a general principle of robustness: be > conservative in what you do, be liberal in what you accept from > others. > > This applies not only to TCP - see RFC 1812. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 15:49:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMnu7B008525 for ; Mon, 17 Sep 2001 15:49:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HMnur8008524 for ipng-dist; Mon, 17 Sep 2001 15:49:56 -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+Sun/8.12.0) with ESMTP id f8HMnq7B008517 for ; Mon, 17 Sep 2001 15:49:52 -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 PAA15600 for ; Mon, 17 Sep 2001 15:50:10 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10213 for ; Mon, 17 Sep 2001 15:50:10 -0700 (PDT) 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 f8HMoAx00939; Mon, 17 Sep 2001 15:50:10 -0700 (PDT) Received: from [171.70.84.50] (deering-office-mac.cisco.com [171.70.84.50]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ABJ75474; Mon, 17 Sep 2001 15:50:09 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Mon, 17 Sep 2001 15:50:11 -0700 To: "Christian Huitema" From: Steve Deering Subject: Re: PPPoE & IPv6: packet too long? Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:19 PM -0700 9/17/01, Christian Huitema wrote: >According to RFC 2516, PPPoE, the Maximum-Receive-Unit (MRU) option MUST >NOT be negotiated to a larger size than 1492. If PPPoE implementations >actually negotiated an MRU size of 1492 bytes, we would not have an >issue. However, many implementations of PPPoE servers only support an >MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6. > >What should we do? Two choices: either get those implementations fixed, or decide on a below-IP-layer method for segmenting and reassembling IPv6 packets sent over such PPPoE links. Isn't there a PPP-based segmentation/ reassembly mechanism already defined (in the context of "PPP multilink" or something)? Such a mechanism would be useful to have for very low-speed links to allow small, higher-priority, jitter-sensitive packets (as determined by diffserv codepoints or intserv signalling) to be sent interleaved with lower-priority, full-size packets (the same rationale as for ATM's small cell size, but applied only where really needed, i.e., on very low-speed links). However, given that we are talking about PPP over *ethernet*, the very-low-speed issues do not arise and it seems a shame to cruft up the link with even more complexity and overhead, so maybe it's worth the effort to get the implementations fixed to negotiate an MRU >= 1280 -- I can't imagine what would prohibit that, given that the implementations must be able to cope with receiving ethernet packets with up to 1500 bytes of payload. (On the other hand, anyone advocating the use of PPPoE obviously doesn't care about complexity or overhead...) 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 Mon Sep 17 15:57:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMv77B008566 for ; Mon, 17 Sep 2001 15:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HMv6sv008565 for ipng-dist; Mon, 17 Sep 2001 15:57: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+Sun/8.12.0) with ESMTP id f8HMv37B008558 for ; Mon, 17 Sep 2001 15:57:03 -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 PAA14913 for ; Mon, 17 Sep 2001 15:57:21 -0700 (PDT) Received: from inet-imc-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12952 for ; Mon, 17 Sep 2001 15:57:21 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Sep 2001 15:57:20 -0700 Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 Sep 2001 15:57:20 -0700 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.2966); Mon, 17 Sep 2001 15:57:20 -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.2966); Mon, 17 Sep 2001 15:57:17 -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); Mon, 17 Sep 2001 15:56:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Mon, 17 Sep 2001 15:56:27 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E740@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcE/yZFX9xY/cakGScKkaHQIalQyPQAAcyOQ From: "Dave Thaler" To: , "Thomas Narten" Cc: "Erik Nordmark" , , X-OriginalArrivalTime: 17 Sep 2001 22:56:32.0586 (UTC) FILETIME=[FE9F7AA0:01C13FCB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8HMv37B008559 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Marshall Eubanks [mailto:tme@21rst-century.com] > Sent: Monday, September 17, 2001 3:40 PM > To: Thomas Narten > Cc: Dave Thaler; Erik Nordmark; ipng@sunroof.eng.sun.com; > malloc@catarina.usc.edu > Subject: Re: uni-based-mcast and malloc-ipv6-guide > > Thomas Narten wrote: > > > > How so? One can renew multicast addresses. (Conceivably an > > > implementation could support the ability to automatically renew > > > multicast addresses as long as the unicast address stays valid.) > > > > Suppose I want to get a multicast address so I can advertise a session > > (e.g., on a web page). I do this two weeks in advance of the event. I > > want the address to last one day only. The key point is that I will > > want to use the address staring two weeks from now. > > > > However, because unicast lifetimes are only a week, that's too far > > into the future to actually get the address (yet), so the address > > can't be obtained yet. This would seem like it might be a problem. Is > > it? (I don't know how this scenario fits with the way multicast is > > actually used in IPv4, so this really is a question.) > > > > Thomas > > In IPv4 I would say, use a GLOP address for this. (We'll rent you one if > you don't have any.) GLOP has exactly the same issue for end sites that don't own their own AS #. When you renumber, chances are it's because you changed your provider, in which case you can no longer use your old provider's GLOP space. Uni-based mcast addresses don't require end sites to have their own AS # (or any other non-aggregatable number). -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 Mon Sep 17 16:06:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HN6B7B008648 for ; Mon, 17 Sep 2001 16:06:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HN6BRh008647 for ipng-dist; Mon, 17 Sep 2001 16:06: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+Sun/8.12.0) with ESMTP id f8HN687B008640 for ; Mon, 17 Sep 2001 16:06:08 -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 QAA17575 for ; Mon, 17 Sep 2001 16:06:26 -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 QAA15218 for ; Mon, 17 Sep 2001 16:06:26 -0700 (PDT) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 15j7T4-0004ze-00; Mon, 17 Sep 2001 16:06:22 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Christian Huitema" Cc: "Steve Deering" , Subject: Re: PPPoE & IPv6: packet too long? References: Message-Id: Date: Mon, 17 Sep 2001 16:06:22 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > According to RFC 2516, PPPoE, the Maximum-Receive-Unit (MRU) option MUST > NOT be negotiated to a larger size than 1492. If PPPoE implementations > actually negotiated an MRU size of 1492 bytes, we would not have an > issue. However, many implementations of PPPoE servers only support an > MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6. > > What should we do? fix the code 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 Sep 17 16:10:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HNAq7B008740 for ; Mon, 17 Sep 2001 16:10:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8HNApnw008739 for ipng-dist; Mon, 17 Sep 2001 16:10: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+Sun/8.12.0) with ESMTP id f8HNAm7B008732 for ; Mon, 17 Sep 2001 16:10: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 QAA22561 for ; Mon, 17 Sep 2001 16:11:06 -0700 (PDT) Received: from multicasttech.com (lennon.multicasttech.com [63.105.122.7]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17308 for ; Mon, 17 Sep 2001 16:11:06 -0700 (PDT) Received: from [63.105.122.193] (account marshall_eubanks HELO 21rst-century.com) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 1081685; Mon, 17 Sep 2001 19:04:02 -0400 Message-ID: <3BA6830F.CDB5CABE@21rst-century.com> Date: Mon, 17 Sep 2001 19:11:11 -0400 From: Marshall Eubanks Reply-To: tme@21rst-century.com Organization: Multicast Technologies X-Mailer: Mozilla 4.7C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; I; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Dave Thaler CC: Thomas Narten , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: <2E33960095B58E40A4D3345AB9F65EC10290E740@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: > > -----Original Message----- > > From: Marshall Eubanks [mailto:tme@21rst-century.com] > > Sent: Monday, September 17, 2001 3:40 PM > > To: Thomas Narten > > Cc: Dave Thaler; Erik Nordmark; ipng@sunroof.eng.sun.com; > > malloc@catarina.usc.edu > > Subject: Re: uni-based-mcast and malloc-ipv6-guide > > > > Thomas Narten wrote: > > > > > > How so? One can renew multicast addresses. (Conceivably an > > > > implementation could support the ability to automatically renew > > > > multicast addresses as long as the unicast address stays valid.) > > > > > > Suppose I want to get a multicast address so I can advertise a > session > > > (e.g., on a web page). I do this two weeks in advance of the event. > I > > > want the address to last one day only. The key point is that I will > > > want to use the address staring two weeks from now. > > > > > > However, because unicast lifetimes are only a week, that's too far > > > into the future to actually get the address (yet), so the address > > > can't be obtained yet. This would seem like it might be a problem. > Is > > > it? (I don't know how this scenario fits with the way multicast is > > > actually used in IPv4, so this really is a question.) > > > > > > Thomas > > > > In IPv4 I would say, use a GLOP address for this. (We'll rent you one > if > > you don't have any.) > > GLOP has exactly the same issue for end sites that don't own > their own AS #. > > When you renumber, chances are it's because you changed your provider, > in which case you can no longer use your old provider's GLOP space. > > Uni-based mcast addresses don't require end sites to have their > own AS # (or any other non-aggregatable number). > > -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 > -------------------------------------------------------------------- Hi Dave; Yes, but he asked "the way multicast is actually used in IPv4". That's the answer to the question he asked, maybe not to others he should have asked. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 17 18:29:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I1Th7B009293 for ; Mon, 17 Sep 2001 18:29:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8I1Th1D009292 for ipng-dist; Mon, 17 Sep 2001 18:29:43 -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+Sun/8.12.0) with ESMTP id f8I1Td7B009285 for ; Mon, 17 Sep 2001 18:29:39 -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 SAA10882 for ; Mon, 17 Sep 2001 18:29:57 -0700 (PDT) Received: from brandenburg.cs.mu.OZ.AU ([202.12.73.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04606 for ; Mon, 17 Sep 2001 19:29:48 -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 f8I1Sis02819; Tue, 18 Sep 2001 08:28:44 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: "Steve Deering" , ipng@sunroof.eng.sun.com Subject: Re: PPPoE & IPv6: packet too long? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Sep 2001 08:28:44 +0700 Message-ID: <2817.1000776524@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 17 Sep 2001 15:19:41 -0700 From: "Christian Huitema" Message-ID: | What should we do? The rational solution is that when the PPPoE implementations are enhanced to support IPv6 (since it is PPP, it knows about address negotiation, and hence needs to be updated), then simultaneously update the implementation to be able to handle a more sensible MTU for IPv6 .. this has to be a much more trivial change than supporting IPv6 in the first place. But also, since any PPP can have almost any MTU configured into it, I would assume that IPv6 over PPP will be (or has already) defining some link level fragmentation scheme, as required for any link level for IPv6 with an MTU less than 1280. Since PPPoE is more or less just PPP, it should be able to use the same mechanisms, if it finds its link MTU happens to have been set < 1280. The only other option for IPv6 over PPP would be to define that the minimum MTU for a PPP link carrying IPv6 is 1280 - in which case PPPoE will just have to follow along. 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 Mon Sep 17 20:07:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I37o7B009414 for ; Mon, 17 Sep 2001 20:07:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8I37o7e009413 for ipng-dist; Mon, 17 Sep 2001 20:07: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+Sun/8.12.0) with ESMTP id f8I37k7B009406 for ; Mon, 17 Sep 2001 20:07:46 -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 UAA28635; Mon, 17 Sep 2001 20:08:04 -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 VAA15333; Mon, 17 Sep 2001 21:08:49 -0600 (MDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id MAA01209; Tue, 18 Sep 2001 12:08:48 +0900 (JST) Date: Tue, 18 Sep 2001 12:07:53 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: RAW sockets and protocols 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: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 17 Sep 2001 21:06:23 +0200 (CEST), >>>>> Erik Nordmark said: >> For RAW sockets, an application can use any procotol for IPv4. In IPv6, I >> imagine there are problems if a RAW application opens a socket and uses a >> known IPv6 extension header number as the protocol since now the IP layer >> will expect that next header field to be an extension header. Therefore, >> is it a restriction now that an IPv6 RAW application cannot use an known >> IPv6 extension header as the protocol on the socket call? > Good question. > I suspect this is implementation dependent since the Advanced API is > silent on the issue. I think so, too. > What do different implementations do? KAME (perhaps unintentionally) does not allow applications to specify a next header ID for an extension header as a socket protocol. The implementation has protocol switch structures for the extension header types with specifying NULL as the corresponding user request functions. As a result, the kernel routing for the socket(2) call fails, with the EPROTONOSUPPORT error, when the protocol value is one of the extension header types. I've checked this behavior with a tiny test program. If you're interested, you may be able to do the same test for your own implementation by: - grab the latest version at http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/advapitest/ - compile the "accept" command in the test kit. - execute "accept -P ipv6-opts" etc. (I don't know if the test kit is portable enough, though.) 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 Sep 18 00:33:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I7XU7B009744 for ; Tue, 18 Sep 2001 00:33:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8I7XUxk009743 for ipng-dist; Tue, 18 Sep 2001 00:33:30 -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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I7XP7B009736 for ; Tue, 18 Sep 2001 00:33:25 -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 f8I7Xdr03156; Tue, 18 Sep 2001 09:33:39 +0200 (MET DST) Date: Tue, 18 Sep 2001 09:29:29 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E73C@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 > If the app says [6 months, 6 months] then personally I would expect the > host to fail the request if it only has a unicast prefix lifetime of 1 > week. > I think your question is really: should we allow such a host to grant > a request for 6 months if it only has a unicast prefix lifetime of 1 > week? Bingo! The related question is: are there applications which would fail to function today if you applied the constraints imposed by this today i.e. the fact that no multicast addresses could be allocated by the API with an end time more than a week into the future? (For this excercise it would make sense to consider the IPv4 multicast applications as well as the IPv6 multicast applications that exist just to try to understand the scope of the applications dependency on multicast address lifetimes.) > In my previous email, if there is a need to allow this (and I'm not > saying > there is), then we'd have to just say it SHOULD NOT, and say that after > the unicast lifetime, the multicast packets are not guaranteed to be > routed. I fail to understand why routing might fail. Could you explain? I do understand that there is a different probability of allocating duplicate uni-based mcast addresses should the unicast prefix be assigned to another entity, but this doesn't lead to routing failing unless you are assuming that routing will do something it doesn't currently do. 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 Sep 18 00:45:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I7j07B009763 for ; Tue, 18 Sep 2001 00:45:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8I7j0t2009762 for ipng-dist; Tue, 18 Sep 2001 00:45:00 -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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I7is7B009755 for ; Tue, 18 Sep 2001 00:44:55 -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 f8I7iZr04011; Tue, 18 Sep 2001 09:44:35 +0200 (MET DST) Date: Tue, 18 Sep 2001 09:40:25 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Thomas Narten , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E73D@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 > This is a good question, and in fact it's not multicast specific. > Here's the unicast equivalent: > > You're advertising a unicast streaming session on a web page that > will start in two weeks (and last one day). You use a URL with > a literal unicast address in it. However, you don't know from > your RA that your address will definitely be the same by then. > Again, this would seem like it might be a problem. Yes, but for unicast there is a clear possibility of using a hostname instead of a literal IP address in such a case. In fact I suspect most unicast usage of this nature uses a hostname. Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on web pages, in SDP, etc and have the hosts do a DNS lookup to join the session?) Does the malloc architecture take into account using the DNS in such a way? Erik > I think the same dangers and possible solutions exist for both > unicast and multicast. Some solutions, with varying degrees of > "goodness", might include: > 1) Change the web page if the address changes, and hope people > don't use an out-of-date web page. > 2) Don't use address literals in the URL, and hope that people > don't resolve the name to an address until close to the > session starts. > 3) Make the admin have knowledge somehow that the address > will indeed be valid throughout the life of the session > advertised. > > The point is that pretty much any solution you use > for unicast can be used for multicast as well. > > -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 Sep 18 01:52:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I8q17B010088 for ; Tue, 18 Sep 2001 01:52:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8I8q1Jm010087 for ipng-dist; Tue, 18 Sep 2001 01: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8I8pu7B010080 for ; Tue, 18 Sep 2001 01:51:56 -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 f8I8q5r12478; Tue, 18 Sep 2001 10:52:05 +0200 (MET DST) Date: Tue, 18 Sep 2001 10:47:55 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RAW sockets and protocols To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Erik Nordmark , 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 > I've checked this behavior with a tiny test program. If you're > interested, you may be able to do the same test for your own > implementation by: > - grab the latest version at > http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/advapitest/ > - compile the "accept" command in the test kit. > - execute "accept -P ipv6-opts" etc. > (I don't know if the test kit is portable enough, though.) Not very portable. Once I wacked away the syntax problems (assuming sin6_len plus a bunch of stuff due to Solaris not having all of rfc2292bis) I realized that accept.c assumes that for SOCK_RAW ai_protocol is passed through from hints to the getaddrinfo result. The Solaris getaddrinfo doesn't do this. I don't know if this is a Solaris problem since I haven't check what the standards text for getaddrinfo() says about SOCK_RAW. In any case I verified that the socket call doesn't fail on Solaris for (PF_INET6, SOCK_RAW, exthdr number). 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 Sep 18 04:12:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IBC57B010184 for ; Tue, 18 Sep 2001 04:12:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8IBC44a010183 for ipng-dist; Tue, 18 Sep 2001 04:12:04 -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+Sun/8.12.0) with ESMTP id f8IBC07B010176 for ; Tue, 18 Sep 2001 04:12:00 -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 EAA16929; Tue, 18 Sep 2001 04:12:01 -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 EAA00763; Tue, 18 Sep 2001 04:11:58 -0700 (PDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fe97:3f1e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id UAA04875; Tue, 18 Sep 2001 20:12:45 +0900 (JST) Date: Tue, 18 Sep 2001 20:11:37 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: RAW sockets and protocols 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: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 18 Sep 2001 10:47:55 +0200 (CEST), >>>>> Erik Nordmark said: > Not very portable. > Once I wacked away the syntax problems (assuming sin6_len plus a > bunch of stuff due to Solaris not having all of rfc2292bis) > I realized that accept.c assumes that for SOCK_RAW ai_protocol is passed > through from hints to the getaddrinfo result. > The Solaris getaddrinfo doesn't do this. Okay, although I'm not sure if you still have an interest on the test kit, I modified the code as portable as possible according to your comments. Also, since at least two people tried to use the kit (the other one said so in a private message), I made a tar+gz ball of the kit at ftp://ftp.kame.net/pub/misc/advapitest.tgz for convenience. > I don't know if this is a Solaris > problem since I haven't check what the standards text for getaddrinfo() > says about SOCK_RAW. I've checked rfc2553bis-03. The spec seems ambiguous on this point... > In any case I verified that the socket call doesn't fail on Solaris for > (PF_INET6, SOCK_RAW, exthdr number). Hmm, so we have at least two different implementations. 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 Sep 18 07:00:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IE0D7B010397 for ; Tue, 18 Sep 2001 07:00:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8IE0DVe010396 for ipng-dist; Tue, 18 Sep 2001 07:00:13 -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+Sun/8.12.0) with ESMTP id f8IE087B010387 for ; Tue, 18 Sep 2001 07:00:08 -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 HAA07080 for ; Tue, 18 Sep 2001 07:00:09 -0700 (PDT) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13277 for ; Tue, 18 Sep 2001 07:00:08 -0700 (PDT) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GJV00I9A2W6ER@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Tue, 18 Sep 2001 09:00:06 -0500 (CDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id f8IE05m14678; Tue, 18 Sep 2001 09:00:05 -0500 (CDT) Date: Tue, 18 Sep 2001 09:00:04 -0500 From: Matt Crawford Subject: Re: PPPoE & IPv6: packet too long? In-reply-to: "17 Sep 2001 15:19:41 PDT." To: Christian Huitema Cc: Steve Deering , ipng@sunroof.eng.sun.com Message-id: <200109181400.f8IE05m14678@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > According to RFC 2516, PPPoE, the Maximum-Receive-Unit (MRU) option MUST > NOT be negotiated to a larger size than 1492. If PPPoE implementations > actually negotiated an MRU size of 1492 bytes, we would not have an > issue. However, many implementations of PPPoE servers only support an > MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6. > > What should we do? Require RFC1990 multilink capability. End of story. 1.2. Functional Description The method discussed here is similar to the multilink protocol described in ISO 7776 [4], but offers the additional ability to split and recombine packets, thereby reducing latency, and potentially increase the effective maximum receive unit (MRU). Furthermore, there is no requirement here for acknowledged-mode operation on the link layer, although that is optionally permitted. [...] The effective MRU for the logical-link entity is negotiated via an LCP option. It is irrelevant whether Network Control Protocol packets are encapsulated in multilink headers or not, or even over which link they are sent, once that link identifies itself as belonging to a multilink arrangement. [...] 5.1.1. Multilink MRRU LCP option Figure 4: Multilink MRRU LCP option 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 17 | Length = 4 | Max-Receive-Reconstructed-Unit| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The presence of this LCP option indicates that the system sending it implements the PPP Multilink Protocol. If not rejected, the system will construe all packets received on this link as being able to be processed by a common protocol machine with any other packets received from the same peer on any other link on which this option has been accepted. The Max-Receive-Reconstructed unit field is two octets, and specifies the maximum number of octets in the Information fields of reassembled packets. A system MUST be able to receive the full 1500 octet Information field of any reassembled PPP packet although it MAY attempt to negotiate a smaller, or larger value. The number 1500 here comes from the specification for the MRU LCP option in PPP; if this requirement is changed in a future version of RFC 1661, the same rules will apply here. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 08:18:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IFIx7B010638 for ; Tue, 18 Sep 2001 08:18:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8IFIwxd010637 for ipng-dist; Tue, 18 Sep 2001 08:18:58 -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.208.15]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IFIr7B010630 for ; Tue, 18 Sep 2001 08:18:54 -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 f8IFInr21084; Tue, 18 Sep 2001 17:18:49 +0200 (MET DST) Date: Tue, 18 Sep 2001 17:14:38 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: uni-based-mcast and malloc-ipv6-guide To: Brian Haberman Cc: Erik Nordmark , Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <3BA757E4.F845D000@americasm06.nt.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I fail to understand why routing might fail. Could you explain? > > I do understand that there is a different probability of allocating duplicate > > uni-based mcast addresses should the unicast prefix be assigned to another > > entity, but this doesn't lead to routing failing unless you are assuming > > that routing will do something it doesn't currently do. > > I think one possible example is with SSM. The first hop router > may receive an IGMPv3 join with an old prefix that has been > renumbered. It then tries to send the SPT Join to the wrong > network. That network doesn't exist and so the Join fails and > the multicast traffic never flows. Brian, I thought uni-based mcast addresses for SSM has an all zero prefix component. (That's what the uni-based draft says.) Are you referring to such a prefix or the IP source address? Clearly SSM, which explicitly identifies a group by the pair , is likely to barf when the IP source address is no longer valid for the sender. Depending on whether the document is correct or not about having a zero prefix in the SSM multicast destination, this may or may not be an issue for the actual multicast address. 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 Sep 18 09:38:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IGct7B010711 for ; Tue, 18 Sep 2001 09:38:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8IGctMo010710 for ipng-dist; Tue, 18 Sep 2001 09:38: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+Sun/8.12.0) with ESMTP id f8IGcq7B010703 for ; Tue, 18 Sep 2001 09:38:52 -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 JAA11576; Tue, 18 Sep 2001 09:38:54 -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 KAA14834; Tue, 18 Sep 2001 10:38:45 -0600 (MDT) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id f8IGckv03021; Tue, 18 Sep 2001 09:38:46 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id f8IGckZ14015; Tue, 18 Sep 2001 09:38:46 -0700 Message-Id: <200109181638.f8IGckZ14015@zed.isi.edu> Subject: Re: uni-based-mcast and malloc-ipv6-guide To: haberman@nortelnetworks.com Date: Tue, 18 Sep 2001 09:38:46 -0700 (PDT) Cc: Erik.Nordmark@eng.sun.com (Erik Nordmark), dthaler@windows.microsoft.com (Dave Thaler), narten@raleigh.ibm.com (Thomas Narten), ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: <3BA758F0.94940360@americasm06.nt.com> from "Brian Haberman" at Sep 18, 2001 10:23:44 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 once they are documented in RFC's they can be added. --bill (zone admin for mcast.net) % % Erik, % I would love to see more usage of DNS for multicast. There % are examples today of mcast addresses being registered in DNS. % Go to your favorite resolver and see what address you get back % when you query all-routers.mcast.net. % % I would have to go and check, but I don't recall discussion % of the use of DNS within the MALLOC Architecture. However, it % would seem rather easy to use DDNS to add MAPCAP allocated addresses % to the DNS. % % Brian % % Erik Nordmark wrote: % > % > > This is a good question, and in fact it's not multicast specific. % > > Here's the unicast equivalent: % > > % > > You're advertising a unicast streaming session on a web page that % > > will start in two weeks (and last one day). You use a URL with % > > a literal unicast address in it. However, you don't know from % > > your RA that your address will definitely be the same by then. % > > Again, this would seem like it might be a problem. % > % > Yes, but for unicast there is a clear possibility of using a hostname instead % > of a literal IP address in such a case. In fact I suspect most unicast % > usage of this nature uses a hostname. % > % > Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on % > web pages, in SDP, etc and have the hosts do a DNS lookup to join the % > session?) % > Does the malloc architecture take into account using the DNS in % > such a way? % > % > Erik % > % > > I think the same dangers and possible solutions exist for both % > > unicast and multicast. Some solutions, with varying degrees of % > > "goodness", might include: % > > 1) Change the web page if the address changes, and hope people % > > don't use an out-of-date web page. % > > 2) Don't use address literals in the URL, and hope that people % > > don't resolve the name to an address until close to the % > > session starts. % > > 3) Make the admin have knowledge somehow that the address % > > will indeed be valid throughout the life of the session % > > advertised. % > > % > > The point is that pretty much any solution you use % > > for unicast can be used for multicast as well. % > > % > > -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 % > -------------------------------------------------------------------- % -- --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 Sep 18 10:23:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IHNR7B010807 for ; Tue, 18 Sep 2001 10:23:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8IHNRPQ010806 for ipng-dist; Tue, 18 Sep 2001 10:23: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+Sun/8.12.0) with ESMTP id f8IHNN7B010799 for ; Tue, 18 Sep 2001 10:23: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 KAA19568 for ; Tue, 18 Sep 2001 10:23:26 -0700 (PDT) Received: from inet-imc-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14865 for ; Tue, 18 Sep 2001 10:23:25 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:23:25 -0700 Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 10:23:24 -0700 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.2966); Tue, 18 Sep 2001 10:23:24 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:23:24 -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.2966); Tue, 18 Sep 2001 10:22:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Tue, 18 Sep 2001 10:22:23 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E751@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFAFCr2cmAezWLMQX+ZH/mxZOcmtAAUjeJA From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 18 Sep 2001 17:22:38.0584 (UTC) FILETIME=[83D71F80:01C14066] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8IHNO7B010800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark asks: > I fail to understand why routing might fail. Could you explain? > I do understand that there is a different probability of allocating > duplicate > uni-based mcast addresses should the unicast prefix be assigned to another > entity, but this doesn't lead to routing failing unless you are assuming > that routing will do something it doesn't currently do. Just like providers do source ingress filtering, there might be something similar that providers would do here. (Maybe, maybe not.) -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 Sep 18 10:41:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IHfK7B010980 for ; Tue, 18 Sep 2001 10:41:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8IHfKMr010979 for ipng-dist; Tue, 18 Sep 2001 10:41:20 -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+Sun/8.12.0) with ESMTP id f8IHfG7B010972 for ; Tue, 18 Sep 2001 10:41:16 -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 KAA01053 for ; Tue, 18 Sep 2001 10:41:17 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA24909 for ; Tue, 18 Sep 2001 10:41:16 -0700 (PDT) Received: from 157.54.9.108 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 10:38:44 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 18 Sep 2001 10:38:43 -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); Tue, 18 Sep 2001 10:38:43 -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, 18 Sep 2001 10:37:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Tue, 18 Sep 2001 10:36:29 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E753@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFAX5Rkx4Mz1e80QWqZI4dzOT/o+wAB/+1g From: "Dave Thaler" To: "Brian Haberman" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 18 Sep 2001 17:37:56.0671 (UTC) FILETIME=[A71014F0:01C14068] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8IHfH7B010973 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Haberman wrote: > > It would be quite useful to outline a bit more of > > the problem that needs solving in the introduction. > > It would also be useful to have a comparision with IPv4 > > (either in the introduction or later in the document). > > Questions I'd like to see answered is whether there are > > approaches and protocols used for IPv4 multicast address allocation that > is > > effectively replaced by the techniques in the draft i.e. whether the > > WGs believe that some mechanisms and protocols that do not need to > > be carried forward to IPv6. > > Not a problem. There was a fair amount of discussion that never > made it into the document wrt what protocols were not being pulled > forward from v4. The overall goal is to avoid the need for any > inter-domain allocation protocol. Our approach basically will only > need, at most, MADCAP servers. Actually, for allocating uni-based mcast addresses, ZMAAP would be more appropriate than MADCAP, since one only has to coordinate within a subnet. (In fact, this was one of the motivations behind doing ZMAAP, since it doesn't require a server.) However, it does not obsolete MADCAP, which would still be used by the sort of people who like using DHCP for unicast address allocation, as well as in the scenario Brian mentions later in the email: > In addition, I could envision the use of this on large > switched LANs with a MADCAP server. -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 Sep 18 11:07:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8II7f7B011076 for ; Tue, 18 Sep 2001 11:07:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8II7fkU011075 for ipng-dist; Tue, 18 Sep 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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8II7b7B011068 for ; Tue, 18 Sep 2001 11:07:37 -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 LAA08629 for ; Tue, 18 Sep 2001 11:07:38 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA12485 for ; Tue, 18 Sep 2001 11:07:37 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 18 Sep 2001 11:06:49 -0700 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.2966); Tue, 18 Sep 2001 11:06:46 -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.2966); Tue, 18 Sep 2001 11:06:40 -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, 18 Sep 2001 11:05:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Tue, 18 Sep 2001 11:05:32 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E759@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFAFCr2cmAezWLMQX+ZH/mxZOcmtAAUjeJAAAF0mvA= From: "Dave Thaler" To: "Dave Thaler" , "Erik Nordmark" Cc: , X-OriginalArrivalTime: 18 Sep 2001 18:05:53.0379 (UTC) FILETIME=[8E756B30:01C1406C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8II7c7B011069 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Dave Thaler > Sent: Tuesday, September 18, 2001 10:22 AM > To: Erik Nordmark > Cc: ipng@sunroof.eng.sun.com; malloc@catarina.usc.edu > Subject: RE: uni-based-mcast and malloc-ipv6-guide > > Erik Nordmark asks: > > I fail to understand why routing might fail. Could you explain? > > I do understand that there is a different probability of allocating > > duplicate > > uni-based mcast addresses should the unicast prefix be assigned to > another > > entity, but this doesn't lead to routing failing unless you are > assuming > > that routing will do something it doesn't currently do. > > Just like providers do source ingress filtering, there might be > something similar that providers would do here. (Maybe, maybe not.) Another example would be if uni-based mcast prefixes are used with BGMP, or any other scheme, to locate the root (domain) of the multicast tree without doing anything different in BGP. If the domain loses its old unicast prefix, after which it's advertised by no one, then the derived multicast addresses would similarly be (intentionally) unusable inter-domain. -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 Sep 19 00:32:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8J7Ww7B012306 for ; Wed, 19 Sep 2001 00:32:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8J7Ww4s012305 for ipng-dist; Wed, 19 Sep 2001 00:32:58 -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+Sun/8.12.0) with ESMTP id f8J7Ws7B012298 for ; Wed, 19 Sep 2001 00:32:54 -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 AAA24455 for ; Wed, 19 Sep 2001 00:32:57 -0700 (PDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA02983 for ; Wed, 19 Sep 2001 01:33:43 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id AAA05954 for ; Wed, 19 Sep 2001 00:32:54 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id AAA18801 for ; Wed, 19 Sep 2001 00:32:52 -0700 (MST)] Received: from beast.arc.corp.mot.com (beast.arc.corp.mot.com [10.238.80.11]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id f8J7WoA03436 for ; Wed, 19 Sep 2001 17:32:51 +1000 (EST) Received: (from kwchin@localhost) by beast.arc.corp.mot.com (8.11.2/8.10.2) id f8J7Wor30827 for ipng@sunroof.eng.sun.com; Wed, 19 Sep 2001 17:32:50 +1000 From: Kwan-Wu Chin Message-Id: <200109190732.f8J7Wor30827@beast.arc.corp.mot.com> Subject: CFP, IPDPS-2002 Workshop on PDC Issues in Wireless Networks and Mobile Computing To: ipng@sunroof.eng.sun.com Date: Wed, 19 Sep 2001 17:32:50 +1000 (EST) 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 Dear Colleague, My sincere apologies if you received multiple copies of this CFP. Regards, Kwan-Wu ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CALL FOR PAPERS 2nd International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2002 WORKSHOPS Ft. Lauderdale Marina Marriott April 15-19, 2002 **************************************************************************** Program Co-Chairs Mohan Kumar, The University of Texas at Arlington, USA C S Raghavandra, University of Southern California, Los Angeles, USA ********************************************************* GENERAL CHAIR Sajal K Das, The University of Texas at Arlington, USA ----------------------------------------------------------- Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas, Computer Technology Institute, Patras, Greece =================================================== Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for this workshop. Accepted papers will be published in the proceedings (by IEEE CS Press) of the IPDPS workshops. Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Algorithms * Routing in ad hoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one of the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12-point size type on 8.5 x 11 inch pages. References, figures, tables, etc., may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; and (3) Phone/fax numbers. Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cse.uta.edu or raghu@usc.edu. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5x11 inch (US letter size) paper. IMPORTANT DATES: October 30, 2001 Workshop Paper Due December 10, 2001 Notification of Acceptance/Rejection January 15, 2002 Camera-Ready Paper Due URLs: http://www.ipdps.org http://ranger.uta.edu/~kumar/ipdpswpim.html ********************************************************* For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or C S Raghavendra All manuscripts will be reviewed. Manuscripts must be received by October 30, 2001. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be e-mailed by December 10, 2001. Camera-ready papers are due January 15, 2002. Proceedings will be available at the Conference. Workshop Program Co-Chairs Mohan Kumar Department of Computer Science and Engineering The University of Texas at Arlington Box 19015 Arlington, TX 76019-0015 Tel: 817-272-3610; Fax: 817-272-3784 E-mail: kumar@cse.uta.edu and C S Raghavendra Department of Electrical Engineering-Systems University of Southern California Los Angeles, CA 90089-2562 Tel: (213) 740-9133 Fax: (213) 740-4418 Email: raghu@usc.edu ++++++++++++++++++++++++++++++++++++++++ Technical Program Committee (Under Creation) ============================ Stefano Basagni, The University of Texas at Dallas, USA Maurizio Bonuccelli, University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA John Heidemann, USC/ISI, USA Ahmed Helmy, University of Southern California, USA Cristina Pinotti, University of Trento, Italy Paul Spirakis, Computer Technology Institute, Patras, Greece Mani Srivastava, University of California, Los Angeles, USA Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Albert Zomaya, University of Western Australia, Perth, Australia ================================================= Steering Committee (Under Creation) -------------------------------------- Victor Bahl, Microsoft, Seattle, USA Kalyan Basu, Nortel Networks, Richardson, USA Andrew Campbell, Columbia University, USA Imrich Chlamtac, The University of Texas at Dallas Sajal Das, The University of Texas at Arlington, USA ----------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 02:30:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8J9UC7B012501 for ; Wed, 19 Sep 2001 02:30:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8J9UCGV012500 for ipng-dist; Wed, 19 Sep 2001 02:30:12 -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+Sun/8.12.0) with ESMTP id f8J9U67B012493 for ; Wed, 19 Sep 2001 02:30:07 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8J9Tvr18191; Wed, 19 Sep 2001 11:29:57 +0200 (MET DST) Date: Wed, 19 Sep 2001 11:25:30 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E751@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 > Erik Nordmark asks: > > I fail to understand why routing might fail. Could you explain? > > I do understand that there is a different probability of allocating > > duplicate > > uni-based mcast addresses should the unicast prefix be assigned to > another > > entity, but this doesn't lead to routing failing unless you are > assuming > > that routing will do something it doesn't currently do. > > Just like providers do source ingress filtering, there might be > something similar that providers would do here. (Maybe, maybe not.) Dave, I'm trying to understand exactly what operational practises that you are suggesting and how they would effect the multicast "service". For SSM it is clear that providers might do filtering. But since uni-based mcast doesn't contain a prefix for SSM addresses the nature of filtering will be no different than with IPv4 SSM i.e. verify that the source address is in some access list for using the SSM address or something of that nature. Point is that uni-based-multicast doesn't change anything in this space. For non-SSM (I assume this is what Brian called "ASM") one could envision having checks that somehow compare the unicast prefix in the multicast address with the IP source address. But assuming that ASM really should provide a service where anybody can send, such checks seem quite determintal to the service. Thus if there ever will be reasons for providers or other entities to perform filtering on ASM packets it seems like they need the ability to have access lists with arbitrary IP source addresses associated with the group. Hence the unicast prefix in the group doesn't make filtering any simpler. So I don't understand what operational practise you are hinting at. What am I missing? 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 Sep 19 02:48:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8J9mb7B012564 for ; Wed, 19 Sep 2001 02:48:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8J9mbs3012563 for ipng-dist; Wed, 19 Sep 2001 02:48:37 -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+Sun/8.12.0) with ESMTP id f8J9mW7B012556 for ; Wed, 19 Sep 2001 02:48:32 -0700 (PDT) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id f8J9mNr19098; Wed, 19 Sep 2001 11:48:23 +0200 (MET DST) Date: Wed, 19 Sep 2001 11:44:08 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Dave Thaler , Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E759@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 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 f8J9mX7B012557 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Another example would be if uni-based mcast prefixes are used > with BGMP, or any other scheme, to locate the root (domain) of the > multicast tree without doing anything different in BGP. If the > domain loses its old unicast prefix, after which it's advertised > by no one, then the derived multicast addresses would similarly > be (intentionally) unusable inter-domain. Dave, If so it would be a fine thing to explicitly document this in the draft as a potential issue. One of my comments/questions in the first mail (which you passed to Brian as an editorial one) was the issue of what aspects of the IPv4 stuff we need and need not carry forward to IPv6. Clearly(?) the documents remove the need for MASC for IPv6. Is that all? Will uni-based have any effect on MBGP and BGMP? (I can't find an BGMP draft to even have a peek.) These questions might seem naïve to you, but I suspect there are implementors and operators that might have the same questions. 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 Sep 19 10:45:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8JHjt7B013178 for ; Wed, 19 Sep 2001 10:45:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8JHjtHM013177 for ipng-dist; Wed, 19 Sep 2001 10:45: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+Sun/8.12.0) with ESMTP id f8JHjp7B013167 for ; Wed, 19 Sep 2001 10:45:51 -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 KAA19543 for ; Wed, 19 Sep 2001 10:45:52 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA24525 for ; Wed, 19 Sep 2001 11:45:38 -0600 (MDT) Received: from 157.54.8.23 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Sep 2001 10:43:23 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 10:43:12 -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.2966); Wed, 19 Sep 2001 10:43:12 -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, 19 Sep 2001 10:43:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: uni-based-mcast and malloc-ipv6-guide Date: Wed, 19 Sep 2001 10:43:09 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E77B@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: uni-based-mcast and malloc-ipv6-guide thread-index: AcFA8ERRDh5Xb9OIRp2cfmMHB26/WwAQOWOw From: "Dave Thaler" To: "Erik Nordmark" Cc: , X-OriginalArrivalTime: 19 Sep 2001 17:43:10.0148 (UTC) FILETIME=[8C52A040:01C14132] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8JHjq7B013169 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Wednesday, September 19, 2001 2:44 AM > To: Dave Thaler > Cc: Dave Thaler; Erik Nordmark; ipng@sunroof.eng.sun.com; > malloc@catarina.usc.edu > Subject: RE: uni-based-mcast and malloc-ipv6-guide > > > > Another example would be if uni-based mcast prefixes are used > > with BGMP, or any other scheme, to locate the root (domain) of the > > multicast tree without doing anything different in BGP. If the > > domain loses its old unicast prefix, after which it's advertised > > by no one, then the derived multicast addresses would similarly > > be (intentionally) unusable inter-domain. > > Dave, > > If so it would be a fine thing to explicitly document this in the draft > as a potential issue. I don't think this document should mention BGMP or any other specific protocol. I think it's fine to state the issue generically (i.e. not guaranteed to be routed by all protocols). > One of my comments/questions in the first mail (which you passed to Brian > as an editorial one) was the issue of what aspects of the IPv4 stuff we > need and need not carry forward to IPv6. > > Clearly(?) the documents remove the need for MASC for IPv6. Is that all? > Will uni-based have any effect on MBGP and BGMP? > (I can't find an BGMP draft to even have a peek.) For this type of address, AAP is not really needed either. There is no effect on MBGP. The effect on BGMP is just that it makes it deployable without MASC or doing anything different with MBGP, and hence provides a much cleaner solution than MSDP does for IPv4. I agree that it would be helpful to add a paragraph discussing this in the draft. -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 Sep 19 13:01:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8JK167B013532 for ; Wed, 19 Sep 2001 13:01:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8JK16AF013531 for ipng-dist; Wed, 19 Sep 2001 13:01: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+Sun/8.12.0) with ESMTP id f8JK127B013524 for ; Wed, 19 Sep 2001 13:01:02 -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 NAA08553 for ; Wed, 19 Sep 2001 13:01:04 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA16750 for ; Wed, 19 Sep 2001 14:00:53 -0600 (MDT) Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 19 Sep 2001 12:58:56 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Sep 2001 12:58:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: comments about temp-addresses-v2-00 Date: Wed, 19 Sep 2001 12:58:41 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCD2@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments about temp-addresses-v2-00 Thread-Index: AcE5/hqrbg5EqA/4SAWpL08bgMerlgHRW0jA From: "Richard Draves" To: "JINMEI Tatuya / ????" , Cc: X-OriginalArrivalTime: 19 Sep 2001 19:58:42.0577 (UTC) FILETIME=[7BA0D010:01C14145] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8JK137B013525 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In section 3.3. Generating Temporary Addresses > > 1) Process the Prefix Information Option as defined in [ADDRCONF], > either creating a public address or adjusting the lifetimes of > existing addresses, both public and temporary. When > adjusting the > lifetime of an existing temporary address, there are > two cases to > consider: > (snip) > b) In many cases, the lifetime in a received option will extend > the lifetime of a public address. For example, a site might > advertise short lifetimes (on the order of hours or minutes) > that are effectively extended with each new RA. In > such cases, > the lifetimes of temporary addresses should be extended, > subject to the overall constraint that no temporary addresses > should ever remain "valid" or "preferred" for a time longer > than (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^I think this > should be just "TEMP_VALID_LIFETIME", because there is no > timing issue for regeneration on valid lifetimes. > > (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The > configuration variables TEMP_VALID_LIFETIME and > TEMP_PREFERRED_LIFETIME correspond to approximate target > lifetimes for temporary addresses. Yes. Section 3.3 step 3) has this correct. > In section 3.2.1, > > 4) Compare the generated identifier against a list of known values > that should not be used. Inappropriate values include those used > in reserved anycast addresses [RFC 2526], those used by ISATAP > [ISATAP], the value 0, and those already assigned to an > address on > the local device. ... > > I'm not sure what "the local device" exactly means. Is it > the "interface" on which a new identifier are being > generated, or is it the "whole node"? Our current > implementation takes the latter interpretation. > > In any case, probably due to this addition, Step 4) in section 3.3 was > simplified: > > 4) New temporary addresses are created by appending the interface's > current randomized interface identifier to the prefix that was > used to generate the corresponding public address. > > than the one in RFC3041: > > 4) New temporary addresses are created by appending the interface's > current randomized interface identifier to the prefix that was > used to generate the corresponding public address. If by chance > the new temporary address is the same as an address already > assigned to the interface, generate a new randomized interface > identifier and repeat this step. > > That is, the duplication check was omitted. But, > technically, this cannot be omitted, because there is a > time-lag between the generation of interface identifiers and > the generation of actual temporary addresses. > > If the draft regards this time-lag as practically negligible, > I think it's okay. But IMH it should mention the issue anyway. > > Our current implementation checks the duplication at the > generation of actual addresses as well as at the generation > of interface identifiers. In my implementation, I don't do any checks directly on the generated interface identifier. Instead when I create a temporary address, I check for known anycast addresses, collisions with existing addresses, etc. If there is a problem, then I generate a new interface identifier and repeat. This avoids any timing windows. This is not quite equivalent to what the draft specifies. For example suppose an interface A has an EUI-64 based interface identifier IDA and derived link-local address LIDA. Now interface B is using temporary addresses with global prefix P and happens to generate interface identifier IDA. Then my implementation will proceed to create a temporary address PIDA whereas the draft would prevent interface B from using IDA. Is there some reason that the more restrictive behavior specified in the draft is necessary? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 18:02:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K12R7B014536 for ; Wed, 19 Sep 2001 18:02:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8K12RbJ014535 for ipng-dist; Wed, 19 Sep 2001 18:02: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+Sun/8.12.0) with ESMTP id f8K12G7B014512; Wed, 19 Sep 2001 18:02:16 -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 SAA28376; Wed, 19 Sep 2001 18:02:18 -0700 (PDT) From: paalee@telenorisv.com Received: from fep2.mta.online.no (lionmta2.online.no [148.122.208.25]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09892; Wed, 19 Sep 2001 18:02:17 -0700 (PDT) Received: from [10.122.209.34] by fep2.mta.online.no (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20010920010215.TEWE392.fep2.mta.online.no@[10.122.209.34]>; Thu, 20 Sep 2001 03:02:15 +0200 To: G.Tsirtsis@flarion.com, gtsirt@hotmail.com, sltsao@itri.org.tw CC: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Fwd: [mobile-ip] IPv6 over Mobile IPv4 Date: Thu, 20 Sep 2001 3:02:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20010920010215.TEWE392.fep2.mta.online.no@[10.122.209.34]> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Sorry if you have received a duplicate of this message - I had some problems with my e-mail.) George and Charles, FYI, the Internet Draft http://search.ietf.org/internet-drafts/draft-mccann-mobileip-ipv6mipv4-00.txt was recently submitted and announced on the Mobile IP mailing list. While we are waiting for the security-issues of MIPv6 to be resolved, I find the proposed solution promising. It provides a mechanism for IPv6 mobility that also incorporates AAA functionality. In the long run, the proposed idea can be relevant for IPv4 to IPv6 transition. Their mechanism might be useful to your "Dual Stack Moving" efforts. It is definitely related to my own Dual Stack Mobile IP draft, which I plan to rewrite, simplify and adapt to their proposal. Earlier, we have talked about a framework for dual stack mobility. Perhaps their draft could be a good starting point for that discussion? -- Paal --------------------------------------------------------------------- >From: Pete McCann >Reply-To: mobile-ip@sunroof.eng.sun.com >To: mobile-ip@sunroof.eng.sun.com >CC: pcalhoun@diameter.org, tom.hiller@lucent.com >Subject: [mobile-ip] IPv6 over Mobile IPv4 >Date: Thu, 13 Sep 2001 17:39:15 -0500 > >Hi, > >We (Pat Calhoun, Tom Hiller, and myself) recently wrote a draft >describing a method for running IPv6 traffic while using Mobile IPv4 >signaling for mobility management and security. We submitted it today >to internet-drafts; you can find an advance copy at: > >http://www.diameter.org/draft-mccann-mobileip-ipv6mipv4-00.txt > >Basically, this could serve as an interim solution while we wait for >all of the Mobile IPv6 security work to converge. It would allow us >to use the existing Mobile IPv4 security model, including AAA, for >securing registration requests, while providing IPv6 service to >dual-stack mobile nodes. It may also help ease the overall transition >to IPv6 because it only requires IPv6 support in the MN, FA, HA, and >home network, while the network between the FA and HA could be a >legacy IPv4 cloud. > >The draft itself is fairly straightforward; we would appreciate >comments on the list and would like to see if there is interest in >making this a working group item. > >-Pete -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 21:25:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K4PB7B014859 for ; Wed, 19 Sep 2001 21:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8K4PBfH014858 for ipng-dist; Wed, 19 Sep 2001 21:25:11 -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+Sun/8.12.0) with ESMTP id f8K4P77B014851 for ; Wed, 19 Sep 2001 21:25:07 -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 VAA17969 for ; Wed, 19 Sep 2001 21:25:10 -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 VAA06438 for ; Wed, 19 Sep 2001 21:25:08 -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 f8K4Okf01580; Thu, 20 Sep 2001 11:24:47 +0700 (ICT) From: Robert Elz To: "Richard Draves" cc: ipng@sunroof.eng.sun.com Subject: Re: comments about temp-addresses-v2-00 In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FCD2@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FCD2@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Sep 2001 11:24:46 +0700 Message-ID: <1578.1000959886@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 19 Sep 2001 12:58:41 -0700 From: "Richard Draves" Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCD2@red-msg-06.redmond.corp.microsoft.com> | Is there some reason that the more restrictive behavior specified in the | draft is necessary? I was thinking about a related issue earlier today, before reading mail, and while I hadn't connected it to the temp-address draft (it wasn't related to temp addresses) my conclusion was the same as yours - assigning the same identifier to different links should be explicitly allowed, attempts to avoid it are just plain silly. So, I certainly can't think of a reason for that particular restriction. That is, your implementation, as described, seems like it is the way it should be done. For temp-address of course it doesn't really matter, Jinmei's implementation is fine too - since it is a random number being created, no-one can tell from outside whether that was done using 2 calls of the RNG, with the first rejected (for any reason the node likes), or using 1 call that happened to fluke upon a value that was acceptable. Only when the node starts running the DAD algorithm can the address selected be observed. 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 Sep 20 00:33:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K7XH7B014979 for ; Thu, 20 Sep 2001 00:33:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8K7XHY5014978 for ipng-dist; Thu, 20 Sep 2001 00:33:17 -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+Sun/8.12.0) with ESMTP id f8K7XE7B014971 for ; Thu, 20 Sep 2001 00:33:14 -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 AAA10840 for ; Thu, 20 Sep 2001 00:33:15 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20562 for ; Thu, 20 Sep 2001 00:33:15 -0700 (PDT) Received: from luster (infonet.ustc.edu.cn [202.38.75.11]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id QAA05365 for ; Thu, 20 Sep 2001 16:30:19 -0800 Message-ID: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn> From: "Wang Hui" To: Subject: Current network/Internet is so weak...in face of Nimda-like worms Date: Fri, 20 Sep 2002 15:31:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f8K7XE7B014972 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, folks here, Yesterday, our campus network was attacked by the Nimda worms, and the worm invoked tons of rubish network traffic as a result that our campus network got broken. No one can enjoy the Internet any longer. ALl the routers were overloaded, and no more bandwith was available at that time. >From this accident, we can see the weakness of our current network. But I wonder if in the next-generation network, we can avoid such kind of worm-attacking? Your advice? regards, Wang Hui -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 01:11:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K8Bh7B015066 for ; Thu, 20 Sep 2001 01:11:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8K8BgbS015065 for ipng-dist; Thu, 20 Sep 2001 01:11:42 -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+Sun/8.12.0) with ESMTP id f8K8Bb7B015058 for ; Thu, 20 Sep 2001 01:11:38 -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 f8K8BXg12513; Thu, 20 Sep 2001 10:11:33 +0200 (MET DST) Date: Thu, 20 Sep 2001 10:07:18 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: uni-based-mcast and malloc-ipv6-guide To: Dave Thaler Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: "Your message with ID" <2E33960095B58E40A4D3345AB9F65EC10290E77B@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 > I don't think this document should mention BGMP or any other specific > protocol. I think it's fine to state the issue generically (i.e. not > guaranteed to be routed by all protocols). OK. But given that I didn't understand the one sentence statement it seems like this explanation needs to be at least a paragraph if not longer. > For this type of address, AAP is not really needed either. > There is no effect on MBGP. > The effect on BGMP is just that it makes it deployable without MASC or > doing anything different with MBGP, and hence provides a much cleaner > solution than MSDP does for IPv4. > > I agree that it would be helpful to add a paragraph discussing this in > the draft. Great. 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 Thu Sep 20 02:41:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K9fJ7B015204 for ; Thu, 20 Sep 2001 02:41:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8K9fIN3015203 for ipng-dist; Thu, 20 Sep 2001 02:41:18 -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+Sun/8.12.0) with ESMTP id f8K9fF7B015196 for ; Thu, 20 Sep 2001 02:41:15 -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 CAA27687 for ; Thu, 20 Sep 2001 02:41:16 -0700 (PDT) Received: from isis.lip6.fr (isis.lip6.fr [132.227.60.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA20976 for ; Thu, 20 Sep 2001 03:42:05 -0600 (MDT) Received: from tibre.lip6.fr (tibre.lip6.fr [132.227.74.2]) by isis.lip6.fr (8.12.0.Beta19/jtpda-5.3.2+victor) with ESMTP id f8K90MeZ020438 ; Thu, 20 Sep 2001 11:00:22 +0200 X-pt: isis.lip6.fr Received: from lip6.fr (otos.lip6.fr [132.227.61.47]) by tibre.lip6.fr (8.11.3/8.11.3) with ESMTP id f8K90DW09154; Thu, 20 Sep 2001 11:00:14 +0200 (CEST) Message-ID: <3BA9B023.F43BDE71@lip6.fr> Date: Thu, 20 Sep 2001 11:00:20 +0200 From: Rolland Vida Organization: Laboratoire Lip6 X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr MIME-Version: 1.0 To: magma@innovationslab.net, idmr@cs.ucl.ac.uk, ipng@sunroof.eng.sun.com, ssm-interest@external.cisco.com, wg-multicast@internet2.edu Subject: MLDv2 implementation Content-Type: multipart/alternative; boundary="------------CEC8BFA98A27BF2765E316CA" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------CEC8BFA98A27BF2765E316CA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, We would like to announce the first implementation of the MLDv2(Multicast Listener Discovery version 2) protocol, jointly developed at LIP6 - Universite Pierre et Maris Curie, Paris and LSIIT - Universite Louis Pasteur, Strasbourg. The development was done on FreeBSD 4.3, using the integrated KAME code for IPv6. MLDv2 Host Implementation was done by Konstantin Kabassanov at LIP6. It is a kernel implementation based on Wilbert de Graaf's IGMPv3 Host Implementation for IPv4. MLDv2 Enabled PIM-SSM Router Implementation was done by Mickael Hoerdt at LSIIT. MLDv2 Router is not a kernel code, but implemented as a user process, fully integrated to PIM-SSM routing daemon. The MLDv2 Host implementation follows the MLDv2 Internet Draft (draft-vida-mld-v2-01.txt). The MLDv2 Router part is not fully compliant with the internet draft, as it fulfils Source Specific Multicast Routing requirements, limited to INCLUDE messages. All the information related to our MLDv2 Implementation can be found at: http://mldv2.lip6.fr. Please send comments, or report bugs to: - mldv2@lip6.fr (host part) - ssm@www-r2.u-strasbg.fr (router part) Best regards, LIP6 Team LSIIT Team Konstantin Kabassanov Mickael Hoerdt Rolland Vida Dominique Grad Luis Costa Jean-Jacques Pansiot Serge Fdida --------------CEC8BFA98A27BF2765E316CA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

We would like to announce the first implementation of the MLDv2(Multicast Listener Discovery version 2) protocol, jointly developed at LIP6 - Universite Pierre et Maris Curie, Paris and LSIIT - Universite Louis Pasteur, Strasbourg.

The development was done on FreeBSD 4.3, using the integrated KAME code for IPv6.

MLDv2 Host Implementation was done by Konstantin Kabassanov at LIP6. It is a kernel implementation based on Wilbert de Graaf's IGMPv3 Host Implementation for IPv4.

MLDv2 Enabled PIM-SSM Router Implementation was done by Mickael Hoerdt at LSIIT. MLDv2 Router is not a kernel code, but implemented as a user process, fully integrated to PIM-SSM routing daemon.

The MLDv2 Host implementation follows the MLDv2 Internet Draft (draft-vida-mld-v2-01.txt). The MLDv2 Router part is not fully compliant with the internet draft, as it fulfils Source Specific Multicast Routing requirements, limited to INCLUDE messages.

All the information related to our MLDv2 Implementation can be found at: http://mldv2.lip6.fr.
Please send comments, or report bugs to:
  - mldv2@lip6.fr (host part)
  - ssm@www-r2.u-strasbg.fr  (router part)

Best regards,

LIP6 Team                         LSIIT Team
   Konstantin Kabassanov            Mickael Hoerdt
   Rolland Vida                     Dominique Grad
   Luis Costa                       Jean-Jacques Pansiot
   Serge Fdida
  --------------CEC8BFA98A27BF2765E316CA-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 03:05:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KA5Z7B015254 for ; Thu, 20 Sep 2001 03:05:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KA5ZXp015253 for ipng-dist; Thu, 20 Sep 2001 03:05:35 -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+Sun/8.12.0) with ESMTP id f8KA5W7B015246 for ; Thu, 20 Sep 2001 03:05:32 -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 DAA24019 for ; Thu, 20 Sep 2001 03:05:32 -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 DAA04581 for ; Thu, 20 Sep 2001 03:05:30 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA24903; Thu, 20 Sep 2001 12:05:21 +0200 (MET DST) Date: Thu, 20 Sep 2001 12:05:21 +0200 From: Ignatios Souvatzis To: Wang Hui Cc: ipng@sunroof.eng.sun.com Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms Message-ID: <20010920120521.A24698@theory.cs.uni-bonn.de> References: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn>; from hwang@ustc.edu on Fri, Sep 20, 2002 at 03:31:12PM +0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 20, 2002 at 03:31:12PM +0800, Wang Hui wrote: > Hi, folks here, >=20 > Yesterday, our campus network was attacked by the Nimda worms, and the wo= rm invoked tons of rubish network traffic as a result that our campus netwo= rk got broken. No one can enjoy the Internet any longer. ALl the routers= were overloaded, and no more bandwith was available at that time.=20 >=20 > >From this accident, we can see the weakness of our current network. But= I wonder if in the next-generation network, we can avoid such kind of worm= -attacking? >=20 > Your advice? Avoid using programs that are designed to forward viruses. -is --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBO6m+bjCn4om+4LhpAQG9Iwf/UTuUbB2stfkb+3/vb7DM82B1+p1ehmlT IYzNLkpdPzdtrc0zyU9FvXkvbvGJkKrxXwNu95Mn+51se+IpAXaDnu6XdG281OW2 9fB6TrbrSPuUoCVdeypofAKcrRBg4lk7vDqvQsS8xVpKO+T5gr7i3hYHphV0cYde rssTIgkD2xOLfR1Eep2kXylP2uhnS9j3RrHc2VS0gJjmJvBDIm4LD1O9oP5+YeRV +HVUe+nDtljBNp8iXy21Skj3UnLMRVk4ZSO7o35rqvhI3fzu0AJwqCX7y6caDdR6 agyzL3Uqw5Y+X3laxFAlieAqsKkToTY26B/H7cQJK51MvJc7li6j+Q== =r+Sp -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 06:43:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KDh27B015378 for ; Thu, 20 Sep 2001 06:43:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KDh1uI015377 for ipng-dist; Thu, 20 Sep 2001 06:43: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+Sun/8.12.0) with ESMTP id f8KDgw7B015370 for ; Thu, 20 Sep 2001 06:42:58 -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 GAA03317 for ; Thu, 20 Sep 2001 06:42:59 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24704 for ; Thu, 20 Sep 2001 06:42:58 -0700 (PDT) Received: from luster (infonet.ustc.edu.cn [202.38.75.11]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id WAA09444; Thu, 20 Sep 2001 22:40:40 -0800 Message-ID: <005a01c260ab$734ff810$584ba8c0@infonet.ustc.edu.cn> From: "Wang Hui" To: "Matti Aarnio" Cc: References: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn> <20010920132716.H11046@mea-ext.zmailer.org> Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms Date: Fri, 20 Sep 2002 21:41:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f8KDgw7B015371 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Matti Aarnio" To: "Wang Hui" Sent: Thursday, September 20, 2001 6:27 PM Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms > On Fri, Sep 20, 2002 at 03:31:12PM +0800, Wang Hui wrote: > > From: "Wang Hui" > > To: > > Subject: Current network/Internet is so weak...in face of Nimda-like worms > > Date: Fri, 20 Sep 2002 15:31:12 +0800 > > Content-Type: text/plain; > > charset="gb2312" > > > > Hi, folks here, > > > > Yesterday, our campus network was attacked by the Nimda worms, and the > > worm invoked tons of rubish network traffic as a result that our campus > > network got broken. No one can enjoy the Internet any longer. ALl the > > routers were overloaded, and no more bandwith was available at that > > time. > > > > From this accident, we can see the weakness of our current network. > > But I wonder if in the next-generation network, we can avoid such > > kind of worm-attacking? > > No. Go sue Microsoft for deliberately making worm/virus > propagation platforms. > > Internet security is at the end-nodes, not in the network! So I think we are also in need of making the network itself safe. Why not make the transporting system more safe ? I think that simple network and complex end nodes will be a big risk in the new world. > > > Your advice? > > > > regards, > > Wang Hui > > /Matti Aarnio > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 07:21:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KELw7B015485 for ; Thu, 20 Sep 2001 07:21:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KELv91015484 for ipng-dist; Thu, 20 Sep 2001 07:21:57 -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+Sun/8.12.0) with ESMTP id f8KELs7B015477 for ; Thu, 20 Sep 2001 07:21: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 HAA02300 for ; Thu, 20 Sep 2001 07:21:54 -0700 (PDT) Received: from dillema.net (server.pasta.cs.uit.no [129.242.16.119]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03713 for ; Thu, 20 Sep 2001 07:21:52 -0700 (PDT) Received: (from dillema@localhost) by dillema.net (8.11.6/8.11.3) id f8KEKjN23142 for ipng@sunroof.eng.sun.com; Thu, 20 Sep 2001 16:20:45 +0200 (CEST) Date: Thu, 20 Sep 2001 16:20:45 +0200 From: Feico Dillema To: ipng@sunroof.eng.sun.com Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms Message-ID: <20010920162044.M452@pasta.cs.uit.no> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn> <20010920132716.H11046@mea-ext.zmailer.org> <005a01c260ab$734ff810$584ba8c0@infonet.ustc.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005a01c260ab$734ff810$584ba8c0@infonet.ustc.edu.cn>; from hwang@ustc.edu on Fri, Sep 20, 2002 at 09:41:34PM +0800 X-Operating-System: NetBSD drifter.dillema.net 1.5X NetBSD 1.5X (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, Sep 20, 2002 at 09:41:34PM +0800, Wang Hui wrote: > > > > From this accident, we can see the weakness of our current network. > > > But I wonder if in the next-generation network, we can avoid such > > > kind of worm-attacking? > > > > No. Go sue Microsoft for deliberately making worm/virus > > propagation platforms. > > > > Internet security is at the end-nodes, not in the network! > > So I think we are also in need of making the network itself safe. Of course, but it does not make a difference for worm/virus type of threats whether they are transported safely/securily or not. An encrypted virus/worm is still a virus/worm. > Why not make the transporting system more safe ? Against what precisely? Of course, network integrity is important but these worms/viruses operate at the application layer. So far, there is no such thing as a virus/worm IP packet. However you may open up for such if you make the network more complex/intelligent/active/whatever. > I think that simple network and complex end nodes will be a big risk in the new world. Sure, but that is not solved by making the network also complex. Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 07:25:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KEPn7B015502 for ; Thu, 20 Sep 2001 07:25:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KEPnZA015501 for ipng-dist; Thu, 20 Sep 2001 07: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KEPj7B015494 for ; Thu, 20 Sep 2001 07:25: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 HAA27907 for ; Thu, 20 Sep 2001 07:25:46 -0700 (PDT) Received: from raksha.wipro.com ([203.197.141.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28076 for ; Thu, 20 Sep 2001 08:25:33 -0600 (MDT) Received: from cdc2vwall.wipro.com (cdc2vwall.wipro.com [10.145.0.23]) by raksha.wipro.com (8.11.3/8.11.3) with SMTP id f8KENQI10996 for ; Thu, 20 Sep 2001 19:53:27 +0530 (IST) Received: from wipro.com ([10.145.2.199]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GJYTAE00.OC3; Thu, 20 Sep 2001 19:53:02 +0530 Message-ID: <3BA9FD84.3CFE9FB6@wipro.com> Date: Thu, 20 Sep 2001 20:00:28 +0530 From: "Vishwanathan K" X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wang Hui CC: Matti Aarnio , ipng@sunroof.eng.sun.com Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms References: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn> <20010920132716.H11046@mea-ext.zmailer.org> <005a01c260ab$734ff810$584ba8c0@infonet.ustc.edu.cn> Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > > Internet security is at the end-nodes, not in the network! > > So I think we are also in need of making the network itself safe. Why not make the transporting system more safe ? I think that simple network and complex end nodes will be a big risk in the new world. Security policies can also be applied to the hosts within the network. But ultimately, the gateways are responsible for security of its internal network. On a philosphical note,this mirrors the real world. The intelligence(defense) is responsible for the security of the country. > > > > > > > Your advice? > > > > > > regards, > > > Wang Hui > > > > /Matti Aarnio > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" ---------------------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. --------------------------------------------------------------------------------------------------------------------------------- --------------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 Thu Sep 20 07:42:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KEg37B015554 for ; Thu, 20 Sep 2001 07:42:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KEg30N015553 for ipng-dist; Thu, 20 Sep 2001 07:42: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+Sun/8.12.0) with ESMTP id f8KEg07B015546 for ; Thu, 20 Sep 2001 07:42:00 -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 HAA00348 for ; Thu, 20 Sep 2001 07:42:00 -0700 (PDT) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06133 for ; Thu, 20 Sep 2001 08:42:48 -0600 (MDT) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id KAA09396; Thu, 20 Sep 2001 10:41:46 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with ESMTP id KAA20936; Thu, 20 Sep 2001 10:41:34 -0400 (EDT) Date: Thu, 20 Sep 2001 10:41:34 -0400 (EDT) From: Greg Maxwell To: Vishwanathan K cc: Wang Hui , Matti Aarnio , Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms In-Reply-To: <3BA9FD84.3CFE9FB6@wipro.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 20 Sep 2001, Vishwanathan K wrote: > Security policies can also be applied to the hosts within the network. But ultimately, the gateways > are responsible for security of its internal network. Are are obviously from a different universe then the rest of us. In our universe we us an incredibly flexible protocol called IP that is smart enough to know that policy can only be truly effectively done on the end-node and thus does it on the end node. I don't know how you would expect a router to know that an application is requesting a file called README.EML much less that it contains malicious code and that IE5 will execute it without it's users knowledge, except as an after the fact clean-up measure initated by humans. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 07:55:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KEtE7B015665 for ; Thu, 20 Sep 2001 07:55:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KEtDD0015664 for ipng-dist; Thu, 20 Sep 2001 07:55: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+Sun/8.12.0) with ESMTP id f8KEtA7B015657 for ; Thu, 20 Sep 2001 07:55: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 HAA09069 for ; Thu, 20 Sep 2001 07:55:10 -0700 (PDT) Received: from raksha.wipro.com ([203.197.141.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29844 for ; Thu, 20 Sep 2001 07:55:08 -0700 (PDT) Received: from cdc2vwall.wipro.com (cdc2vwall.wipro.com [10.145.0.23]) by raksha.wipro.com (8.11.3/8.11.3) with SMTP id f8KEsPI11550 for ; Thu, 20 Sep 2001 20:24:25 +0530 (IST) Received: from wipro.com ([10.145.2.199]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GJYUQ100.UCL; Thu, 20 Sep 2001 20:24:01 +0530 Message-ID: <3BAA04C7.FB7408BE@wipro.com> Date: Thu, 20 Sep 2001 20:31:27 +0530 From: "Vishwanathan K" X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Greg Maxwell CC: Wang Hui , Matti Aarnio , ipng@sunroof.eng.sun.com Subject: Re: Current network/Internet is so weak...in face of Nimda-likeworms References: Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > Security policies can also be applied to the hosts within the network. But ultimately, the gateways > > are responsible for security of its internal network. obviously 'virus-control' was not being implied here !! I was referring to more of things like packet filtering, firewalling and IP security policies. which i agree have nothing to do with detecting malicious code. > Are are obviously from a different universe then the rest of us. In our > universe we us an incredibly flexible protocol called IP that is smart > enough to know that policy can only be truly effectively done on the > end-node and thus does it on the end node. > > I don't know how you would expect a router to know that an application is > requesting a file called README.EML much less that it contains malicious > code and that IE5 will execute it without it's users knowledge, except as > an after the fact clean-up measure initated by humans. --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" ---------------------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. --------------------------------------------------------------------------------------------------------------------------------- --------------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 Thu Sep 20 08:08:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KF8Z7B015720 for ; Thu, 20 Sep 2001 08:08:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KF8ZAa015719 for ipng-dist; Thu, 20 Sep 2001 08:08:35 -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+Sun/8.12.0) with ESMTP id f8KF8V7B015712 for ; Thu, 20 Sep 2001 08:08:31 -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 IAA05675 for ; Thu, 20 Sep 2001 08:08:32 -0700 (PDT) From: matthew.ford@bt.com Received: from cbibipnt05.hc.bt.com (saturn.bt.com [193.113.57.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15269 for ; Thu, 20 Sep 2001 08:08:31 -0700 (PDT) Received: by cbibipnt05.hc.bt.com with Internet Mail Service (5.5.2652.35) id ; Thu, 20 Sep 2001 16:08:24 +0100 Message-ID: To: vishwanathan.krish@wipro.com, gmaxwell@martin.fl.us Cc: hwang@ustc.edu, matti.aarnio@zmailer.org, ipng@sunroof.eng.sun.com Subject: RE: Current network/Internet is so weak...in face of Nimda-likewo rms Date: Thu, 20 Sep 2001 16:08:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please take this thread off ipng! Mat. > -----Original Message----- > From: Vishwanathan K [mailto:vishwanathan.krish@wipro.com] > Sent: 20 September 2001 16:01 > To: Greg Maxwell > Cc: Wang Hui; Matti Aarnio; ipng@sunroof.eng.sun.com > Subject: Re: Current network/Internet is so weak...in face of > Nimda-likeworms > > > > > > > Security policies can also be applied to the hosts within > the network. But ultimately, the gateways > > > are responsible for security of its internal network. > > obviously 'virus-control' was not being implied here !! > I was referring to more of things like packet filtering, > firewalling and IP security policies. which i > agree have nothing to do with detecting malicious code. > > > Are are obviously from a different universe then the rest > of us. In our > > universe we us an incredibly flexible protocol called IP > that is smart > > enough to know that policy can only be truly effectively done on the > > end-node and thus does it on the end node. > > > > I don't know how you would expect a router to know that an > application is > > requesting a file called README.EML much less that it > contains malicious > > code and that IE5 will execute it without it's users > knowledge, except as > > an after the fact clean-up measure initated by humans. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 14:30:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8KLU27B016789 for ; Thu, 20 Sep 2001 14:30:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8KLU2oJ016788 for ipng-dist; Thu, 20 Sep 2001 14:30: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+Sun/8.12.0) with ESMTP id f8KLTw7B016781 for ; Thu, 20 Sep 2001 14:29: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 OAA15542 for ; Thu, 20 Sep 2001 14:29:59 -0700 (PDT) Received: from bsdbox.org (bsdbox.org [66.114.64.95]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03993 for ; Thu, 20 Sep 2001 15:29:47 -0600 (MDT) Received: from localhost ([127.0.0.1] helo=bsdbox.org ident=lazy) by bsdbox.org with esmtp (Exim 3.30 #1) id 15kBOP-0001iJ-00 for ipng@sunroof.eng.sun.com; Thu, 20 Sep 2001 17:29:57 -0400 Message-ID: <3BAA5FD5.9172D4B4@bsdbox.org> Date: Thu, 20 Sep 2001 17:29:57 -0400 From: lazy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Current network/Internet is so weak...in face of Nimda-like worms References: <022801c26077$b2bfbc80$584ba8c0@infonet.ustc.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wang Hui wrote: > > Hi, folks here, > > Yesterday, our campus network was attacked by the Nimda worms, and the worm invoked tons of rubish network traffic as a result that our campus network got broken. No one can enjoy the Internet any longer. ALl the routers were overloaded, and no more bandwith was available at that time. Tell your users not to use Outlook, but some other mail client. Stop running WinNT servers - they have no advantage over to Unix solutions which tend to be much more secure, and preform better most times. Really, use better software and educate users on how to be more secure users. If you must use Windows try patching the OS and anti-virus software daily. > > >From this accident, we can see the weakness of our current network. But I wonder if in the next-generation network, we can avoid such kind of worm-attacking? Your network doesn't seem to really be the problem. The real problems seem to the the software machines on your network run. There's nothing that can be implented into IPng that can allow a simple blocking of worms, viruses, etc. Maybe they can introduce a 'I am malicious' flag for packets. But that would be a complete joke, since no one who actually wrote worms/etc. would use it. ;) > > Your advice? > > regards, > Wang Hui > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ..:: kill -9 `ps -U luser|grep sh|awk '{print $1}'` PGP: RSA 2048bit 0xB7673053 (keyserver.pgp.com) Web: http://packetjunkie.net http://bsdbox.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 19:13:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L2D47B017603 for ; Thu, 20 Sep 2001 19:13:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8L2D4dY017602 for ipng-dist; Thu, 20 Sep 2001 19:13:04 -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+Sun/8.12.0) with ESMTP id f8L2Cx7B017595 for ; Thu, 20 Sep 2001 19:12: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 TAA01223 for ; Thu, 20 Sep 2001 19:13:00 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA13608 for ; Thu, 20 Sep 2001 20:12:48 -0600 (MDT) Received: from luster (infonet.ustc.edu.cn [202.38.75.11]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id LAA23578; Fri, 21 Sep 2001 11:11:39 -0800 Message-ID: <010301c26114$629669a0$584ba8c0@infonet.ustc.edu.cn> From: "Wang Hui" To: , , Cc: , References: Subject: Re: Current network/Internet is so weak...in face of Nimda-likewo rms Date: Sat, 21 Sep 2002 10:12:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f8L2D07B017596 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the next-generation routes/gateways should take more responsibility. For example, routers, or gateways, to the network/Internet is what the policmen to the city high-way comunication system. The policmen should make the highway system fluent, and so do to the future routers. But the quesiton is how the router know what are 'bad' packets? ----- Original Message ----- From: To: ; Cc: ; ; Sent: Thursday, September 20, 2001 11:08 PM Subject: RE: Current network/Internet is so weak...in face of Nimda-likewo rms > Please take this thread off ipng! > > Mat. > > > -----Original Message----- > > From: Vishwanathan K [mailto:vishwanathan.krish@wipro.com] > > Sent: 20 September 2001 16:01 > > To: Greg Maxwell > > Cc: Wang Hui; Matti Aarnio; ipng@sunroof.eng.sun.com > > Subject: Re: Current network/Internet is so weak...in face of > > Nimda-likeworms > > > > > > > > > > > Security policies can also be applied to the hosts within > > the network. But ultimately, the gateways > > > > are responsible for security of its internal network. > > > > obviously 'virus-control' was not being implied here !! > > I was referring to more of things like packet filtering, > > firewalling and IP security policies. which i > > agree have nothing to do with detecting malicious code. > > > > > Are are obviously from a different universe then the rest > > of us. In our > > > universe we us an incredibly flexible protocol called IP > > that is smart > > > enough to know that policy can only be truly effectively done on the > > > end-node and thus does it on the end node. > > > > > > I don't know how you would expect a router to know that an > > application is > > > requesting a file called README.EML much less that it > > contains malicious > > > code and that IE5 will execute it without it's users > > knowledge, except as > > > an after the fact clean-up measure initated by humans. > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 00:47:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L7lT7B017829 for ; Fri, 21 Sep 2001 00:47:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8L7lTke017828 for ipng-dist; Fri, 21 Sep 2001 00:47: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+Sun/8.12.0) with ESMTP id f8L7lO7B017821 for ; Fri, 21 Sep 2001 00:47:25 -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 AAA27385 for ; Fri, 21 Sep 2001 00:47:27 -0700 (PDT) From: jarno.rajahalme@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03844 for ; Fri, 21 Sep 2001 00:47:25 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f8L7lt713529 for ; Fri, 21 Sep 2001 10:47:56 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 21 Sep 2001 10:47:24 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id <3MSWSJJJ>; Fri, 21 Sep 2001 10:47:24 +0300 Message-ID: <009CA59D1752DD448E07F8EB2F91175719801D@esebe004.NOE.Nokia.com> To: mat@cisco.com, kre@munnari.OZ.AU Cc: huitema@windows.microsoft.com, ipng@sunroof.eng.sun.com Subject: RE: refocusing: what about the flow label? Date: Fri, 21 Sep 2001 10:47:17 +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 Michael Thomas wrote: > > Robert Elz writes: > > That seems wrong to me. With a 20 bit field, and a PRNG value in the > > field, then there's room for a million different flows, all passing through > > a router, and all being uniquely matched by just the flow label (with > > address verification later). My guess is that a million is already too > > small, but it is also most probably not so far away from what's needed > > as to be unusable (to use the million we'd need rather more flows than > > that, because we know we'll get collisions, which is what saves such a > > small number). > > > > Your proposal reduces that to 64K flows. That I know is way too small. > > Er, the flow key is src/dst/flowlabel, right? That means it's > 64k per host pair which seems like plenty. > Unless the current RFC 2460 App.A semantics is changed, the flow key actually is src/flowlabel, quote: "A flow is uniquely identified by the combination of a source address and a non-zero flow label." Additionally, the routing behavior for each unique flow must be the same ("All packets belonging to the same flow must be sent with the same source address, destination address, and flow label..."), so the same flow label value cannot be used with different destination addresses by a given source. Obviously these rules do not apply to the flow label value 0, and must be relaxed for other well-known flows as well. Jarno -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 02:46:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L9kU7B018032 for ; Fri, 21 Sep 2001 02:46:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8L9kUL4018031 for ipng-dist; Fri, 21 Sep 2001 02: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8L9kQ7B018024 for ; Fri, 21 Sep 2001 02:46:26 -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 CAA18681 for ; Fri, 21 Sep 2001 02:46:28 -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 DAA22398 for ; Fri, 21 Sep 2001 03:46:07 -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 f8L9iqI02780; Fri, 21 Sep 2001 16:44:53 +0700 (ICT) From: Robert Elz To: jarno.rajahalme@nokia.com cc: mat@cisco.com, huitema@windows.microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: refocusing: what about the flow label? In-Reply-To: <009CA59D1752DD448E07F8EB2F91175719801D@esebe004.NOE.Nokia.com> References: <009CA59D1752DD448E07F8EB2F91175719801D@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Sep 2001 16:44:52 +0700 Message-ID: <2778.1001065492@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 21 Sep 2001 10:47:17 +0300 From: jarno.rajahalme@nokia.com Message-ID: <009CA59D1752DD448E07F8EB2F91175719801D@esebe004.NOE.Nokia.com> | "A flow is uniquely identified by the combination of a source | address and a non-zero flow label." | Obviously these rules do not apply to the flow label value 0, Yes, that's what it explicitly says. If the flow label is not non-zero (ie: is 0) then it isn't a flow - hence rules for flows can't be relevant. | and must be relaxed for other well-known flows as well. And that is the question that has been being debated... Right now I think we need to wait and see what Brian comes up with next. 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 Sep 21 08:43:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LFhZ7B018351 for ; Fri, 21 Sep 2001 08:43:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8LFhZP1018350 for ipng-dist; Fri, 21 Sep 2001 08:43:35 -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+Sun/8.12.0) with ESMTP id f8LFhV7B018343 for ; Fri, 21 Sep 2001 08:43: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 IAA03225 for ; Fri, 21 Sep 2001 08:43:29 -0700 (PDT) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09543 for ; Fri, 21 Sep 2001 09:43:18 -0600 (MDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f8LFhR903201 for ; Fri, 21 Sep 2001 11:43:28 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 21 Sep 2001 17:43:22 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB0D897C43@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ipng@sunroof.eng.sun.com Subject: FYI: draft-ietf-ops-rfc2851-update-04.txt being last called on mi bs mailing list Date: Fri, 21 Sep 2001 17:43:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to thank the IPv6MIB team and the editor(s) for the continued effort on this document. The editors/authors and I think it is ready to be considered for Proposed Standard in which case it will obsolete RFC2851. Pls review and send any Last Call comments to the mibs mailing list (mibs@ops.ietf.org) before October 1st. We'll have another 4-week IETF wide Last Call, so there is more opportunity to comment, but the sooner we get feedback (if any) the better. to subscribe to the mibs mailing list, send email to majordomo@ops.ietf.org in body: subscribe mibs Thanks, Bert Bert -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: vrijdag 21 september 2001 13:04 To: IETF-Announce; @loki.ietf.org@horh1.emsr.lucent.com Subject: I-D ACTION:draft-ietf-ops-rfc2851-update-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations & Management Open Area Working Group of the IETF. Title : Textual Conventions for Internet Network Addresses Author(s) : M. Daniele, B. Haberman, S. Routhier, J. Schoenwaelder Filename : draft-ietf-ops-rfc2851-update-04.txt Pages : 20 Date : 20-Sep-01 This MIB module defines textual conventions to represent commonly used Internet network layer addressing information. The intent is that these textual conventions will be imported and used in MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ops-rfc2851-update-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ops-rfc2851-update-04.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-ops-rfc2851-update-04.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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 09:06:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8LG6J7B018419 for ; Fri, 21 Sep 2001 09:06:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8LG6IHI018418 for ipng-dist; Fri, 21 Sep 2001 09:06: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+Sun/8.12.0) with ESMTP id f8LG6D7B018411 for ; Fri, 21 Sep 2001 09:06:13 -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 JAA12063 for ; Fri, 21 Sep 2001 09:06:12 -0700 (PDT) Received: from spmler2.mail.eds.com (spmler2.mail.eds.com [194.128.225.188]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06294 for ; Fri, 21 Sep 2001 09:06:11 -0700 (PDT) Received: from nnse.eds.com (nnse-3.eds.com [192.168.1.1]) by spmler2.mail.eds.com (8.11.1/8.11.1) with ESMTP id f8LG5cW16586; Fri, 21 Sep 2001 17:05:54 +0100 (BST) Received: from nnse.eds.com (localhost [127.0.0.1]) by nnse.eds.com (8.11.3/8.11.3) with ESMTP id f8LG5a510876; Fri, 21 Sep 2001 17:05:36 +0100 (BST) Received: from gbspm002.exemhub.exch.eds.com ([207.37.51.200]) by nnse.eds.com (8.11.3/8.11.3) with ESMTP id f8LG5ZA10862; Fri, 21 Sep 2001 17:05:35 +0100 (BST) Received: by GBSPM002 with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Sep 2001 17:05:33 +0100 Message-ID: From: "Leone, Guido" To: "'Wang Hui'" Cc: ipng@sunroof.eng.sun.com Subject: R: Current network/Internet is so weak...in face of Nimda-likewo rms Date: Fri, 21 Sep 2001 17:04:43 +0100 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 No, I preferred the policeman and the router doing their job: to make the system fluent and eventually stop someone or something by orders coming from the right authority. In both systems, to be 'bad' or not is an higher layer issue (civilization or OSI Ref. Mod.,...no difference) than the layer where the policeman and the router work and make their decisions and actions. -----Messaggio originale----- Da: Wang Hui [mailto:hwang@ustc.edu] Inviato: sabato 21 settembre 2002 4.13 A: matthew.ford@bt.com; vishwanathan.krish@wipro.com; gmaxwell@martin.fl.us Cc: matti.aarnio@zmailer.org; ipng@sunroof.eng.sun.com Oggetto: Re: Current network/Internet is so weak...in face of Nimda-likewo rms I think the next-generation routes/gateways should take more responsibility. For example, routers, or gateways, to the network/Internet is what the policmen to the city high-way comunication system. The policmen should make the highway system fluent, and so do to the future routers. But the quesiton is how the router know what are 'bad' packets? ----- Original Message ----- From: To: ; Cc: ; ; Sent: Thursday, September 20, 2001 11:08 PM Subject: RE: Current network/Internet is so weak...in face of Nimda-likewo rms > Please take this thread off ipng! > > Mat. > > > -----Original Message----- > > From: Vishwanathan K [mailto:vishwanathan.krish@wipro.com] > > Sent: 20 September 2001 16:01 > > To: Greg Maxwell > > Cc: Wang Hui; Matti Aarnio; ipng@sunroof.eng.sun.com > > Subject: Re: Current network/Internet is so weak...in face of > > Nimda-likeworms > > > > > > > > > > > Security policies can also be applied to the hosts within > > the network. But ultimately, the gateways > > > > are responsible for security of its internal network. > > > > obviously 'virus-control' was not being implied here !! > > I was referring to more of things like packet filtering, > > firewalling and IP security policies. which i > > agree have nothing to do with detecting malicious code. > > > > > Are are obviously from a different universe then the rest > > of us. In our > > > universe we us an incredibly flexible protocol called IP > > that is smart > > > enough to know that policy can only be truly effectively done on the > > > end-node and thus does it on the end node. > > > > > > I don't know how you would expect a router to know that an > > application is > > > requesting a file called README.EML much less that it > > contains malicious > > > code and that IE5 will execute it without it's users > > knowledge, except as > > > an after the fact clean-up measure initated by humans. > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Sep 24 16:39:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8ONdh7B024797 for ; Mon, 24 Sep 2001 16:39:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8ONdhnn024796 for ipng-dist; Mon, 24 Sep 2001 16:39:43 -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+Sun/8.12.0) with ESMTP id f8ONdd7B024789 for ; Mon, 24 Sep 2001 16:39:39 -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 QAA28238 for ; Mon, 24 Sep 2001 16:39:41 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24295 for ; Mon, 24 Sep 2001 16:39:40 -0700 (PDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 16:39:39 -0700 Received: from 157.54.1.52 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 24 Sep 2001 16:39:39 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 24 Sep 2001 16:39:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipngwg-default-addr-select-05.txt Date: Mon, 24 Sep 2001 16:39:38 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCEA@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipngwg-default-addr-select-05.txt Thread-Index: AcEkDqsFQSxxVvm4QXOCsjMy1OBgywhQbJMA From: "Richard Draves" To: "marcelo" Cc: X-OriginalArrivalTime: 24 Sep 2001 23:39:38.0936 (UTC) FILETIME=[2D196B80:01C14552] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8ONde7B024790 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Questions and comments about the default address selection mechanisms: > > 1- About scope and deprecated addresses in source address selection: > > Considering the way Rule 2 and rule 3 are specified, is it > possible that a deprecated address is selected rather than a > non-deprecated with bigger scope? For example suppose that > the destination address D has site local scope and the > outgoing interface has 2 addresses assigned: a site local > address SA which is deprecated and a global address SB which > is not deprecated. Applying rule 2 scope(SA) scope(SA)=scope(D) then rule 2 chooses SA. Wouldn?t be better > to choose SB in this case? My first comment is that this situation really shouldn't occur often in practice. Why does the host have a deprecated site-local address SA and does not have some other non-deprecated site-local address SC? And getaddrinfo is returning a site-local address to the application? Possibly the host's site is phasing out usage of site-local addresses and this is some race-condition in the phase-out, but more likely some configuration somewhere is broken. But putting that aside: I would argue that SA is the better choice, because I think choosing a correctly-scoped source address is more important than avoiding deprecated addresses. If SB is chosen, then when D goes to reply to SB, communication might be prevented because of the scope mismatch. Whereas if SA is chosen, then communication will succeed until such time as SA expires (if it expires). D, and all the routers in between, don't know that SA is deprecated. But scope mismatches can cause problems. (Eg in the past some implementations have refused to communicate with mismatched scope, or depending on routing vagaries communication from D to SB could result in a scope-exceeded ICMP error.) > 2- Final tie-breaker unspecified in source address selection. > > If the 8 proposed rules fail, "some unspecified tie-breaker > should be used". In order to obtain predictable behaviour > (specially considering that this is included in standard > track), wouldn?t be interesting to specify a final rule that > always select an address. (i.e. the smallest address or > something like this) I do not have a strong opinion about this. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 23:07:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P67w7B025120 for ; Mon, 24 Sep 2001 23:07:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8P67wjd025119 for ipng-dist; Mon, 24 Sep 2001 23:07: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+Sun/8.12.0) with ESMTP id f8P67s7B025112 for ; Mon, 24 Sep 2001 23:07:54 -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 XAA29739 for ; Mon, 24 Sep 2001 23:07:56 -0700 (PDT) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05931 for ; Tue, 25 Sep 2001 00:07:44 -0600 (MDT) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f8P67sK05896 for ; Tue, 25 Sep 2001 08:07:54 +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 f8P67rb26714 for ; Tue, 25 Sep 2001 09:07:53 +0300 (EET DST) Message-ID: <3BB01F39.F0F16454@lmf.ericsson.se> Date: Tue, 25 Sep 2001 09:07:53 +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: ipng@sunroof.eng.sun.com Subject: Cellular host requirements, 01 & next steps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I'd like to announce that we have produced a new version of the cellular host requirements draft. Before it makes to the official I-D directories you can access it at http://standards.ericsson.net/hesham/draft-manyfolks-ipv6-cellular-host-01.txt We appreciate all the input we've gotten on the draft, and have tried to take it all in account in this new version. Further input would also be much appreciated, so keep those comments coming! Also, I'd like to ask the groups' opinion on how to proceed with this work. On a technical level, I feel that most people seem to agree on the main issues though some work of course remains. However, in London we didn't actually decide what to do with this draft. Basically, we'd be interested in getting this work on Standards Track and get it finalized as soon as possible. There is an opportunity for IPv6 in a very large number of hosts, starting from the release 5 of 3GPP. I think we should seize that opportunity - and in a consistent, interoperable manner towards the rest of the IPv6 Internet. One way of helping this to happen is to have an RFC whose support can be required from the terminal devices. How can we get there in the best possible way? Can we get this as an official work item in the WG? Jari Arkko -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 24 23:26:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P6Qk7B025204 for ; Mon, 24 Sep 2001 23:26:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8P6QkbZ025203 for ipng-dist; Mon, 24 Sep 2001 23:26:46 -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+Sun/8.12.0) with ESMTP id f8P6Qf7B025196 for ; Mon, 24 Sep 2001 23:26:41 -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 XAA26776 for ; Mon, 24 Sep 2001 23:26:43 -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 AAA25727 for ; Tue, 25 Sep 2001 00:27:39 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 707A94B20 for ; Tue, 25 Sep 2001 15:26:33 +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: ICMPv6 type 0 From: itojun@iijlab.net Date: Tue, 25 Sep 2001 15:26:33 +0900 Message-ID: <23972.1001399193@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.iana.org/assignments/icmpv6-parameters ICMPv6 type 0 is still unassigned. does it make sense to mark it reserved, so that noone will use it? if so, how can we do it? (for ICMPv4 it was assigned to "echo reply") 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 Sep 24 23:38:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P6cr7B025373 for ; Mon, 24 Sep 2001 23:38:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8P6cri8025372 for ipng-dist; Mon, 24 Sep 2001 23: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P6cn7B025365 for ; Mon, 24 Sep 2001 23:38: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 XAA17309 for ; Mon, 24 Sep 2001 23:38:52 -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 XAA28730 for ; Mon, 24 Sep 2001 23:38:51 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id f8P6cCd08855; Tue, 25 Sep 2001 09:38:13 +0300 Date: Tue, 25 Sep 2001 09:38:12 +0300 (EEST) From: Pekka Savola To: Richard Draves cc: marcelo , Subject: RE: draft-ietf-ipngwg-default-addr-select-05.txt In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FCEA@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 24 Sep 2001, Richard Draves wrote: > But putting that aside: I would argue that SA is the better choice, > because I think choosing a correctly-scoped source address is more > important than avoiding deprecated addresses. If SB is chosen, then when > D goes to reply to SB, communication might be prevented because of the > scope mismatch. Whereas if SA is chosen, then communication will succeed > until such time as SA expires (if it expires). D, and all the routers in > between, don't know that SA is deprecated. But scope mismatches can > cause problems. (Eg in the past some implementations have refused to > communicate with mismatched scope, or depending on routing vagaries > communication from D to SB could result in a scope-exceeded ICMP error.) Am I missing something here, or are we changing the definition/expected use of 'deprecated address' here? Previously, I think, it was very clearly not to be used as a source address, to be phased out when connections using it die off. If we start re-using 'deprecated address' for new connections under certain scenarios, we may never actually manage to get rid of it. After all, deprecated usually _should_ be either refreshed or removed. If we keep using it anyway, _when_ it is absolutely removed, we're going to have bigger problems anyway. -- 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 Sep 25 01:46:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8P8kr7B025961 for ; Tue, 25 Sep 2001 01:46:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8P8kr4H025960 for ipng-dist; Tue, 25 Sep 2001 01:46: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+Sun/8.12.0) with ESMTP id f8P8kn7B025953 for ; Tue, 25 Sep 2001 01:46:49 -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 BAA02460 for ; Tue, 25 Sep 2001 01:46:51 -0700 (PDT) Received: from newexchange.domain.com ([202.106.106.102]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01515 for ; Tue, 25 Sep 2001 01:46:49 -0700 (PDT) Received: from liangxg ([202.106.106.126]) by newexchange.domain.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Sep 2001 16:38:35 +0800 Message-ID: <008601c1459e$a83af530$7dce12ac@MCSD.local> From: "Xingang Liang" To: Subject: Any ideas about IPv6 in wireless network such as UMTS? Date: Tue, 25 Sep 2001 16:47:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" 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 X-OriginalArrivalTime: 25 Sep 2001 08:38:35.0325 (UTC) FILETIME=[7716CED0:01C1459D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id f8P8ko7B025954 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi,My friends,how are you! I am doing some research about the benefits/challenges of IPv6 deployment in wireless network such as UMTS and encountered some problems: 1.I don't know why the IPv6 should be deployed in the wireless network. 2.I don't know what is the benefits of IPv6 when implementing in the wireless network. 3.I don't know what challenges we can face when implementing IPv6 in the wireless network? 4.What is the reason of convergence between wireless network and Internet? If you have time and interests,let's discuss about these! Sorry to bother you all and thank you for your patience! Best Regards Xingang Liang Standardization Department Mobile Communication R&D Center China Academy of Telecommunication Technology(CATT) No.40,Xueyuan Road Beijing,China 100083 Tel:+8610 62304422EXT225 Fax:+8610 62303127 Mailto:liangxg@catt.ac.cn -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 08:47:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PFlY7B026837 for ; Tue, 25 Sep 2001 08:47:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8PFlYEN026836 for ipng-dist; Tue, 25 Sep 2001 08:47:34 -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+Sun/8.12.0) with ESMTP id f8PFlU7B026829 for ; Tue, 25 Sep 2001 08:47:30 -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 IAA08948 for ; Tue, 25 Sep 2001 08:47:31 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA11663 for ; Tue, 25 Sep 2001 08:47:30 -0700 (PDT) Received: from 157.54.9.104 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Sep 2001 08:46:29 -0700 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, 25 Sep 2001 08:46:12 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Sep 2001 08:46:11 -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.2966); Tue, 25 Sep 2001 08:45:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Any ideas about IPv6 in wireless network such as UMTS? Date: Tue, 25 Sep 2001 08:45:43 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Any ideas about IPv6 in wireless network such as UMTS? Thread-Index: AcFFnydcuTKpwR/7TEyB+eJ/8epywwAOX56Q From: "Christian Huitema" To: "Xingang Liang" , X-OriginalArrivalTime: 25 Sep 2001 15:45:43.0808 (UTC) FILETIME=[22DAF800:01C145D9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8PFlU7B026830 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Xingang Liang [mailto:liangxg@catt.ac.cn] > Sent: Tuesday, September 25, 2001 1:47 AM > To: ipng@sunroof.eng.sun.com > Subject: Any ideas about IPv6 in wireless network such as UMTS? > > > Hi,My friends,how are you! > > I am doing some research about the benefits/challenges of > IPv6 deployment in wireless network such as UMTS and > encountered some problems: > > 1.I don't know why the IPv6 should be deployed in the > wireless network. > > 2.I don't know what is the benefits of IPv6 when implementing > in the wireless network. Check RFC 3002, "Overview of 2000 IAB Wireless Internetworking Workshop", for an answer to your 1st and 2nd questions. > 3.I don't know what challenges we can face when implementing > IPv6 in the wireless network? In a nutshell, agreeing on address allocation and mobile IPv6. > 4.What is the reason of convergence between wireless network > and Internet? Check the deployment of 802.11 networks, or the success of NTT Docomo. -- 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 Sep 25 21:43:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8Q4h57B029887 for ; Tue, 25 Sep 2001 21:43:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8Q4h5jM029886 for ipng-dist; Tue, 25 Sep 2001 21:43: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+Sun/8.12.0) with ESMTP id f8Q4h07B029876 for ; Tue, 25 Sep 2001 21:43: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 VAA28417 for ; Tue, 25 Sep 2001 21:43:03 -0700 (PDT) Received: from starfruit.itojun.org (kame202.kame.net [203.178.141.202]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA14828 for ; Tue, 25 Sep 2001 21:43:01 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id E28287BA for ; Wed, 26 Sep 2001 13:42:14 +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: draft-haberman-ipngwg-auto-prefix-01.txt From: Jun-ichiro itojun Hagino Date: Wed, 26 Sep 2001 13:42:14 +0900 Message-Id: <20010926044214.E28287BA@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk a couple of questions regarding to draft-haberman-ipngwg-auto-prefix-01. itojun 1. response type against renew request consider the following transaction. what will be the message type for the reply against renew request? reqestor -> delegator (multicast): icmp6 type = prefix request, icmp6 code = delegator query (0) delegator -> requestor: icmp6 type = prefix reply, icmp6 code = prefix delegator (0) requestor -> delegator: icmp6 type = prefix request, icmp6 code = initial request (1) delegator -> requestor: icmp6 type = prefix reply, icmp6 code = prefix delegated (4) (lifetime passes) requestor -> delegator: icmp6 type = prefix request, icmp6 code = renewal request (2) delegator -> requestor: icmp6 type = prefix reply, icmp6 code = ???? 2. authorization faiulure how does authorization fail when the protocol does not provide any authentication mechansisms? does it assume any ipsec assumptions, like "ipsec AH failure is visible to delegator daemon, and delegator can request AH"? 3. state machine apparently state machine has to be maintained by the implementation of the protocol. if there is a diagram of state machine (to understand what are the expected messages and what are not) it would help us understand the protocol much. maybe it is too much to ask. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 26 07:24:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QEOK7B001582 for ; Wed, 26 Sep 2001 07:24:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8QEOKbP001581 for ipng-dist; Wed, 26 Sep 2001 07:24: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+Sun/8.12.0) with ESMTP id f8QEOG7B001574 for ; Wed, 26 Sep 2001 07:24: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 HAA15652; Wed, 26 Sep 2001 07:24:17 -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 HAA23880; Wed, 26 Sep 2001 07:24:17 -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 HAA02122; Wed, 26 Sep 2001 07:24:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f8QEOGY32278; Wed, 26 Sep 2001 07:24:16 -0700 X-mProtect: Wed, 26 Sep 2001 07:24:16 -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 smtpdcNi34a; Wed, 26 Sep 2001 07:24:14 PDT Message-Id: <4.3.2.7.2.20010926071954.0224abc8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Sep 2001 07:23:11 -0700 To: Erik.Nordmark@eng.sun.com, narten@raleigh.ibm.com From: Bob Hinden Subject: Request to Advance "An analysis of IPv6 anycast" Cc: scoya@ietf.org, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : An analysis of IPv6 anycast Author(s) : J. Hagino et al. Filename : draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt Pages : 10 Date : 16-Jul-01 A working group last call for this document was completed on September 7, 2001. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 26 09:51:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QGpc7B002175 for ; Wed, 26 Sep 2001 09:51:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8QGpcFJ002174 for ipng-dist; Wed, 26 Sep 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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QGpY7B002167 for ; Wed, 26 Sep 2001 09:51:34 -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 JAA19693 for ; Wed, 26 Sep 2001 09:51:36 -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 JAA07220 for ; Wed, 26 Sep 2001 09:51:33 -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 LAA48410 for ; Wed, 26 Sep 2001 11:49:08 -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.97.1) with ESMTP id f8QGpRZ140000 for ; Wed, 26 Sep 2001 12:51:27 -0400 Importance: Normal Subject: IPv6 RAW packets To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Lori Napoli" Date: Wed, 26 Sep 2001 12:49:57 -0400 X-MIMETrack: Serialize by Router on D04MC300/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/26/2001 12:51:26 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just curious what other implementations are doing with RAW IPv6 packets. When you send the packet back up to the application are you including the IPv6 header and all the extension headers? Theoretically, an application that is performing ICMP ECHO/ECHOREPLIES doesn't need anything in the IPv6 header or extension header but obviously an application that is performing Neighbor Discovery would. If you are returning the IPv6 header and extension headers, then I imagine all the IPv6 RAW applications need to add code to handle all the extension headers since the IPv6 header doesn't have a field that gives the length of all the headers like IPv4. Right? 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 Wed Sep 26 10:58:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QHwY7B002558 for ; Wed, 26 Sep 2001 10:58:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8QHwY99002557 for ipng-dist; Wed, 26 Sep 2001 10:58:34 -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+Sun/8.12.0) with ESMTP id f8QHwU7B002550 for ; Wed, 26 Sep 2001 10:58:30 -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 KAA24668 for ; Wed, 26 Sep 2001 10:58:31 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05688 for ; Wed, 26 Sep 2001 11:59:27 -0600 (MDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id AEA044E83; Wed, 26 Sep 2001 13:58:28 -0400 (EDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 70D004DE2; Wed, 26 Sep 2001 13:58:28 -0400 (EDT) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 1AC8380D; Wed, 26 Sep 2001 12:58:28 -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 984EA9B8; Wed, 26 Sep 2001 12:58:27 -0500 (CDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000011507; Wed, 26 Sep 2001 13:58:26 -0400 (EDT) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/12Mar01-1127AM) id NAA0000044258; Wed, 26 Sep 2001 13:58:25 -0400 (EDT) Message-ID: <3BB2173F.F3F3EFD1@zk3.dec.com> Date: Wed, 26 Sep 2001 13:58:23 -0400 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 X5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Lori Napoli Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 RAW packets References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lori Compaq's implementation returns back just raw data asked for unless IP_HDRINCL was set. The app may set Advanced API options to get any extension headers it wants. If IP_HDRINCL is set, the entire header chain is returned. -vlad Lori Napoli wrote: > > Just curious what other implementations are doing with RAW IPv6 packets. > When you send the packet back up to the application are you including the > IPv6 header and all the extension headers? Theoretically, an application > that is performing ICMP ECHO/ECHOREPLIES doesn't need anything in the IPv6 > header or extension header but obviously an application that is performing > Neighbor Discovery would. If you are returning the IPv6 header and > extension headers, then I imagine all the IPv6 RAW applications need to add > code to handle all the extension headers since the IPv6 header doesn't have > a field that gives the length of all the headers like IPv4. Right? > > 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 > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Sep 26 10:59:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8QHxB7B002574 for ; Wed, 26 Sep 2001 10:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8QHxAEL002573 for ipng-dist; Wed, 26 Sep 2001 10:59:10 -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+Sun/8.12.0) with ESMTP id f8QHx67B002566 for ; Wed, 26 Sep 2001 10:59:06 -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 KAA25016 for ; Wed, 26 Sep 2001 10:59:07 -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 KAA02192 for ; Wed, 26 Sep 2001 10:59:05 -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 MAB182478 for ; Wed, 26 Sep 2001 12:56:43 -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.97.1) with ESMTP id f8QHx2Z131530 for ; Wed, 26 Sep 2001 13:59:03 -0400 Subject: Re: IPv6 RAW packets To: "Lori Napoli" Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Wed, 26 Sep 2001 13:58:48 -0400 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.6 |December 14, 2000) at 09/26/2001 01:59:02 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wednesday, 09/26/2001 at 12:49 AST, Lori Napoli/Raleigh/IBM@IBMUS wrote: > Just curious what other implementations are doing with RAW IPv6 packets. > When you send the packet back up to the application are you including the > IPv6 header and all the extension headers? Theoretically, an application > that is performing ICMP ECHO/ECHOREPLIES doesn't need anything in the IPv6 > header or extension header but obviously an application that is performing > Neighbor Discovery would. If you are returning the IPv6 header and > extension headers, then I imagine all the IPv6 RAW applications need to add > code to handle all the extension headers since the IPv6 header doesn't have > a field that gives the length of all the headers like IPv4. Right? A quick look at RFC2292, as well as the now-expired *bis version, indicates that neither the IPv6 header nor the extension headers are made available to applications in their raw format (i.e., as part of the packet data). Instead, the relevant information is made available using ancillary data objects. Applications can control which ancillary data objects they receive using socket options and/or ancillary data. The relevant text describing this is in Section 3 of both documents. 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 Sep 27 03:53:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RArO7B007396 for ; Thu, 27 Sep 2001 03:53:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RArORo007395 for ipng-dist; Thu, 27 Sep 2001 03:53: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+Sun/8.12.0) with ESMTP id f8RArK7B007388 for ; Thu, 27 Sep 2001 03:53:20 -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 DAA26415 for ; Thu, 27 Sep 2001 03:53:21 -0700 (PDT) Received: from smtp5.cluster.oleane.net (smtp5.cluster.oleane.net [195.25.12.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00659 for ; Thu, 27 Sep 2001 04:54:16 -0600 (MDT) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp5.cluster.oleane.net with SMTP id f8RArFm61343 for ; Thu, 27 Sep 2001 12:53:15 +0200 (CEST) Message-ID: <005501c14744$030cc000$0201a8c0@oleane.com> Reply-To: "Michel Gosse" From: "Michel Gosse" To: Subject: Two major IPv6 events in France next 19-23 November Date: Thu, 27 Sep 2001 13:03:16 +0200 Organization: Upper Side Conferences MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01C14754.C63A0280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0052_01C14754.C63A0280 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ETSI and Upper Side are pleased to announce two major IPv6 events which = will be held in parallel at Paris and Cannes-France on 19-23 November. ETSI will handle in Cannes the 2nd IPv6 interoperability event. Details and registration are available at : = http://www.etsi.org/plugtests/News/news.htm Upper Side will organize the " Deploying IPv6 " conference, endorsed by = the IPv6 Forum, in Paris from 20 to 23rd November. Details and registration are available at : = http://www.upperside.fr/ipv6/deployipv6intro.htm Traveling between the two cities may be managed, if requested, by Upper = Side. Please contact Iben Mortensen at : iben@upperside.fr tel : 33 1 53 46 63 80 ------=_NextPart_000_0052_01C14754.C63A0280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ; Thu, 27 Sep 2001 11:15:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RIF7dS020551 for ipng-dist; Thu, 27 Sep 2001 11:15:07 -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+Sun/8.12.0) with ESMTP id f8RIF47B020544 for ; Thu, 27 Sep 2001 11:15:04 -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 LAA19881 for ; Thu, 27 Sep 2001 11:15:04 -0700 (PDT) Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07027 for ; Thu, 27 Sep 2001 12:15:56 -0600 (MDT) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8RI6Gs01803; Thu, 27 Sep 2001 14:06:20 -0400 Message-Id: <200109271806.f8RI6Gs01803@hygro.adsl.duke.edu> To: "Brian Haberman" , Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt In-Reply-To: Message from "Thu, 27 Sep 2001 13:19:58 EDT." <200109271719.f8RHJwW01344@hygro.adsl.duke.edu> Date: Thu, 27 Sep 2001 14:06:15 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten writes: > > So, since I am the common denominator between the two drafts, I must > > claim responsibility. The SSM overview draft should state that > > FF3x::/32 is the SSM range for IPv6. > Either I still don't get it, or this isn't true either. Only if plen > == 0 is the address an SSM one. So you can't say that ff3x::/32 is the > SSM range, because the plen field is in the last octet of that range. I clearly didn't get it above; I agree that FF3x::/32 would be the SSM range. 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 Thu Sep 27 14:50:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RLoo7B021562 for ; Thu, 27 Sep 2001 14:50:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RLooh2021561 for ipng-dist; Thu, 27 Sep 2001 14:50: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+Sun/8.12.0) with ESMTP id f8RLol7B021554 for ; Thu, 27 Sep 2001 14:50:47 -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 OAA13316 for ; Thu, 27 Sep 2001 14:50:48 -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 PAA11614 for ; Thu, 27 Sep 2001 15:51: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 OAA18774; Thu, 27 Sep 2001 14:50:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f8RLojG27269; Thu, 27 Sep 2001 14:50:45 -0700 X-mProtect: Thu, 27 Sep 2001 14:50:45 -0700 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd7bIzm5; Thu, 27 Sep 2001 14:50:43 PDT Message-ID: <3BB39F34.1410DDA2@iprg.nokia.com> Date: Thu, 27 Sep 2001 14:50:44 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Michel Gosse CC: ipng@sunroof.eng.sun.com Subject: Re: Two major IPv6 events in France next 19-23 November References: <005501c14744$030cc000$0201a8c0@oleane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Michel Gosse wrote: > > ETSI and Upper Side are pleased to announce two major IPv6 events whats there on your website? it managed to crash Netscape 4.7 on FreeBSD 3.4. it crashed Netscape on Windows 98 and IE 5.0 on Windows 98. never seen it happen with any other website!! Vijay > which will be held in parallel at Paris and Cannes-France on 19-23 > November. > > ETSI will handle in Cannes the 2nd IPv6 interoperability event. > > Details and registration are available at : > http://www.etsi.org/plugtests/News/news.htm > > Upper Side will organize the " Deploying IPv6 " conference, endorsed > by the IPv6 Forum, in Paris from 20 to 23rd November. > > Details and registration are available at : > http://www.upperside.fr/ipv6/deployipv6intro.htm > > Traveling between the two cities may be managed, if requested, by > Upper Side. Please contact Iben Mortensen at : > > iben@upperside.fr > > tel : 33 1 53 46 63 80 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 16:57:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RNv77B021907 for ; Thu, 27 Sep 2001 16:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RNv6MM021906 for ipng-dist; Thu, 27 Sep 2001 16:57:06 -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+Sun/8.12.0) with ESMTP id f8RNv47B021899 for ; Thu, 27 Sep 2001 16:57:04 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNsX601240 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:54:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87JaCIQ028180 for ; Fri, 7 Sep 2001 12:36:13 -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 MAA21039 for ; Fri, 7 Sep 2001 12:36:24 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20872 for ; Fri, 7 Sep 2001 12:36:24 -0700 (PDT) Received: from 157.54.9.108 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Sep 2001 12:36:14 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Sep 2001 12:36:12 -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.2966); Fri, 7 Sep 2001 12:36:12 -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, 7 Sep 2001 12:35:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.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 "IP Version 6 Addressing Architecture" Date: Fri, 7 Sep 2001 12:35:40 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: W.G. Last Call on "IP Version 6 Addressing Architecture" Thread-Index: AcE3z/sQSi+b/DTCRsS951VN9hHeZgAA01uA From: "Christian Huitema" To: "Brian E Carpenter" , "Erik Nordmark" Cc: "Bob Hinden" , X-OriginalArrivalTime: 07 Sep 2001 19:35:41.0049 (UTC) FILETIME=[47375E90:01C137D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f87JaEIQ028181 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Yes, we have in some cases to test whether the address is "global in scope" or not; such tests are mandated for example in the behavior of Shipworm routers. This points us to section 2.4 of the addressing spec, which reads: The type of an IPv6 address is identified by the high-order bits of the address, as follows: Address type Binary prefix IPv6 notation Section ------------ ------------- ------------- ------- Unspecified 00...0 (128 bits) ::/128 2.5.2 Loopback 00...1 (128 bits) ::1/128 2.5.3 Multicast 11111111 FF00::/8 2.7 Link-local unicast 1111111010 FE80::/10 2.5.6 Site-local unicast 1111111011 FEC0::/10 2.5.6 Global unicast (everything else) So, when I implement the test, I am going to check whether the address matches ::/127, FF00::/8, or FF80/9, and if yes recognize a non local scope. What I should specifically not do is check whether the address matches 2000::/3, and if not recognize a non local scope! In short, looking for an inexistent format prefix would drive a programming error. -- Christian Huitema > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Friday, September 07, 2001 11:49 AM > To: Erik Nordmark > Cc: Bob Hinden; ipng@sunroof.eng.sun.com > Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" > > Well, I miswrote slightly - the fact is that an implementation has to > first check if the address is any of the non-global-unicast cases, and > that > involves doing a sequence of matches which involve the bits > Formerly Known as the Format Prefix (not just 3 of them of course). > I think the new text makes this harder to understand. It doesn't > change > what implementors should do. > > Feel free to ignore my comment if nobody else has the same reaction. > > Brian > > Erik Nordmark wrote: > > > > > I also think that abolishing the term "format prefix" is > obfuscation. The > > > fact is that the leading bits of an address *are* a format prefix > and > > > implementors *will* look at those bits before processing an > address. Why > > > obscure that fact? > > > > Brian, > > It is exactly this that we want to avoid - implementors thinking > that they > > need to inspect the first 3 bits of the addresses. > > There is no need to do this and we need to reduce the probability > that > > implementors hard-code any knowledge of any leading 3 bit > combinations > > since it will make it harder to use the other 15/16th of the address > space > > in the future. > > > > 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 -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 27 16:57:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RNva7B021917 for ; Thu, 27 Sep 2001 16:57:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RNvaJN021916 for ipng-dist; Thu, 27 Sep 2001 16:57:36 -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+Sun/8.12.0) with ESMTP id f8RNvX7B021909 for ; Thu, 27 Sep 2001 16:57:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNt2m01270 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:55:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0.Gamma1+Sun/8.12.0.Gamma1) with ESMTP id f87LV4IQ028371 for ; Fri, 7 Sep 2001 14:31:04 -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 OAA16505 for ; Fri, 7 Sep 2001 14:31:18 -0700 (PDT) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA16283 for ; Fri, 7 Sep 2001 15:31:14 -0600 (MDT) Received: from hpinrput.cup.hp.com (hpinrput.cup.hp.com [15.13.108.67]) by palrel10.hp.com (Postfix) with ESMTP id EA0B61F52C for ; Fri, 7 Sep 2001 14:31:16 -0700 (PDT) Received: from hpncdsn.cup.hp.com (snara@hpncdsn.cup.hp.com [15.13.106.150]) by hpinrput.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) with ESMTP id OAA12470 for ; Fri, 7 Sep 2001 14:10:22 -0700 (PDT) Date: Fri, 7 Sep 2001 14:31:25 -0700 (PDT) From: Srinivasan Narasimhan To: Subject: Question on new MIBs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Are the new drafts that update IP, TCP and UDP MIBs going to obselete the existing IPv6 MIB RFCs 2465 (IP), 2452 (TCP) and 2454 (UDP)? Thanx a lot in advance for the replies. Cheers, Cheenu. 1-408-447-4289 TN-447-4289 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 16:58:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RNw07B021937 for ; Thu, 27 Sep 2001 16:58:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RNw0DF021933 for ipng-dist; Thu, 27 Sep 2001 16:58:00 -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+Sun/8.12.0) with ESMTP id f8RNvv7B021926 for ; Thu, 27 Sep 2001 16:57:57 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNtQ001300 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:55:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8AIGg49002088 for ; Mon, 10 Sep 2001 11:16:42 -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 LAA21792 for ; Mon, 10 Sep 2001 11:16:55 -0700 (PDT) Received: from uniwest2.it.west.unispherenetworks.com ([65.194.140.146]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25455 for ; Mon, 10 Sep 2001 12:17:32 -0600 (MDT) Received: by uniwest2.it.west.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Sep 2001 14:14:58 -0400 Received: from fkastenholzpc.unispherenetworks.com (dhcp120-188.dhcp.west.unispherenetworks.com [10.10.120.188]) by uniwest1.redstonecom.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P5AJLZ1F; Mon, 10 Sep 2001 14:16:47 -0400 From: "Kastenholz, Frank" To: Christian Huitema , Michael Thomas , Robert Elz Cc: ipng Message-Id: <5.0.2.1.2.20010910140554.027133b0@uniwest1> X-Sender: fkastenholz@uniwest1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 10 Sep 2001 14:14:04 -0400 Subject: RE: refocusing: what about the flow label? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:38 AM 9/7/01 -0700, Christian Huitema wrote: >In fact, one of the points that were made clear in the debate is that >the router manufacturers will never "just trust the host", i.e. just >trust that the "flow label" is sufficiently random and sufficiently >unique that they could use it without looking at the addresses. Then, >even if the flow was unique, we should note that even 20 bits would be >two small to be practical: the birthday paradox would kick in as soon as >the router processes 1,024 flows, which is not a very large number; you >would need some kind of tie-breaking logic, which means that you would >have at a minimum to process the source address. So, it is much safer to >assume that the primary classification will be based on the address >pair, and that the label is just a differentiator for packets that carry >the same address pair and require specific treatment; Mike points out >one possible solution; there are certainly others; hashing 256 bits of >source-destination should not require an inordinate number of gates in a >VLSI. Christian, It's not the gates to calculate the hash key that's the issue. The problem is that hashing has a whole pile of memory access issues surrounding the possibility of collisions. First, it requires keeping a linked-list (or the like) of "flow descriptors" in the memory. This list has to be readable by the ASIC, but it also is written by the CPU as new flows are added and old ones deleted. This leads to the the classic multiple-accessor problems. Locking and write-snooping and so on are all doable -- but they add complexity that is very hard to verify and leads to less-robust designs. Second, since we can not know how many different flows will map to a given hash bucket. This means that the number of memory-accesses-per-packet is indeterminate. This is bad -- the memory system can not be well designed, so the packet rate can not be determined (which means that buffer sizes can not be determined, system performance can not be characterized, and so on) Frank Kastenholz -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 16:58:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RNwo7B021958 for ; Thu, 27 Sep 2001 16:58:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RNwn6o021957 for ipng-dist; Thu, 27 Sep 2001 16:58:49 -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+Sun/8.12.0) with ESMTP id f8RNwl7B021950 for ; Thu, 27 Sep 2001 16:58:47 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNuFD01330 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:56:15 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8HMKV7B008289 for ; Mon, 17 Sep 2001 15:20: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 PAA08418; Mon, 17 Sep 2001 15:20:48 -0700 (PDT) Received: from southstation.m5p.com (dsl-209-162-215-52.easystreet.com [209.162.215.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20045; Mon, 17 Sep 2001 16:21:31 -0600 (MDT) Received: (from george@localhost) by southstation.m5p.com (8.11.4/8.11.4) id f8HMKgX47450; Mon, 17 Sep 2001 15:20:42 -0700 (PDT) Date: Mon, 17 Sep 2001 15:20:42 -0700 (PDT) From: George Mitchell Message-Id: <200109172220.f8HMKgX47450@southstation.m5p.com> To: dthaler@windows.microsoft.com, narten@raleigh.ibm.com Subject: RE: uni-based-mcast and malloc-ipv6-guide Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10290E73D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Suppose I want to get a multicast address so I can advertise a session > > (e.g., on a web page). I do this two weeks in advance of the event. I > > want the address to last one day only. The key point is that I will > > want to use the address staring two weeks from now. > > > > However, because unicast lifetimes are only a week, that's too far > > into the future to actually get the address (yet), so the address > > can't be obtained yet. This would seem like it might be a problem. Is > > it? (I don't know how this scenario fits with the way multicast is > > actually used in IPv4, so this really is a question.) > > This is a good question, and in fact it's not multicast specific. > Here's the unicast equivalent: Unless I'm missing something really obvious, shouldn't you both simply be advertising a domain name? Put the address into DNS when the time comes and everybody will be happy. -- George Mitchell -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 16:59:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RNxN7B021987 for ; Thu, 27 Sep 2001 16:59:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RNxNHM021986 for ipng-dist; Thu, 27 Sep 2001 16:59: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+Sun/8.12.0) with ESMTP id f8RNxL7B021979 for ; Thu, 27 Sep 2001 16:59:21 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNunL01360 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:56:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IE1V7B010406 for ; Tue, 18 Sep 2001 07:01:31 -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 HAA08562 for ; Tue, 18 Sep 2001 07:01:32 -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 IAA29517 for ; Tue, 18 Sep 2001 08:01:23 -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 f8IE12p28218 for ; Tue, 18 Sep 2001 10:01:02 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:01:17 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBXMB9KF; Tue, 18 Sep 2001 10:01:16 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2A; Tue, 18 Sep 2001 10:01:15 -0400 Message-ID: <3BA753AD.70F2E912@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:01:17 -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: Erik Nordmark CC: ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Apologies for the delay in responding. It took me a little while to get back to the States from Stockholm. Responses are in-line... Erik Nordmark wrote: > > I have some comments and questions on the related drafts. > > > draft-ietf-ipngwg-uni-based-mcast-02.txt > > It would be quite useful to outline a bit more of > the problem that needs solving in the introduction. > It would also be useful to have a comparision with IPv4 > (either in the introduction or later in the document). > Questions I'd like to see answered is whether there are > approaches and protocols used for IPv4 multicast address allocation that is > effectively replaced by the techniques in the draft i.e. whether the > WGs believe that some mechanisms and protocols that do not need to > be carried forward to IPv6. Not a problem. There was a fair amount of discussion that never made it into the document wrt what protocols were not being pulled forward from v4. The overall goal is to avoid the need for any inter-domain allocation protocol. Our approach basically will only need, at most, MADCAP servers. > > The first part of section 3 should presumably refer to and use the picture > from draft-ietf-ipnwg-addr-arch-v3 instead of RFC 2373. OK. > > The description of the fields in section 3 should at a minimum describe > the group ID field by having a reference to draft-ietf-malloc-ipv6-guide-03.txt > I wonder if it also makes sense to carry some information from that document > into this one; e.g. the fact that the high-order bit of the group ID must be > zero for these types of addresses. Some of the information in draft-ietf-malloc-ipv6-guide-03.txt was pulled from this doc and moved. I was trying to separate the protocol aspects from the operational aspects. However, the bit-setting may be better off in this document. Any other text you think might belong in other locations/documents? > > Will the unicast prefix based addresses ever need to use the link-local prefix? > If not it might make sense to explicitly ban that where it talks about scope > in section 3. Dave answered this already, but let me add something. The following text is in section 3: The scope of the unicast-prefix based multicast address MUST NOT exceed the scope of the unicast prefix embedded in the multicast address. This text was actually put in specifically to address the use of the link-local prefix. As Dave said, using it doesn't buy you anything, but allowing it makes the work of allocation servers easier since they don't have to prohibit particular scopes on the prefixes. In addition, I could envision the use of this on large switched LANs with a MADCAP server. > > The last paragraph in section 3 is about lifetimes. > I don't understand what the intended effect is of the statement > since I don't know what the lifetime is of a multicast address. > Is the intent that e.g. if the prefixes are advertised with a 1 day valid > lifetime, that an implementation MUST NOT use multicast addresses derived > from those prefixes in SDP advertisements that end beyond 1 day ahead? > If the intent is to really be that strict the document definitely needs > to be a lot more specific on this point. But I don't see a need to be > that strict - all these multicast addresses are temporary - is there > any real danger is for some applications "temporary" spans unicast > prefix renumbering events? I will defer comment for another response since it seems that there has been alot of discussion on this point while I was gone. > > > draft-ietf-malloc-ipv6-guide-03.txt > > The name of the reference [NEW ARCH] confused me - I was sure it > was addr-arch-v3. How about "UNICAST PREFIX" or [3] instead? Ah, a legacy reference. I can change this without any problems. It was a carryover from the original -00 document where Dave and I had proposed breaking the multicast address architecture out of RFC 2373. > > Section 3 - bullet on SSM. This says that there is a 96 bit multicast > prefix but the other drafts says it must be zero. Why not explicitly say zero > here as well? Otherwise folks can be lead to believe they can create non-zero > middle bits for SSM addresses. > (If this change is done the second bullet would need to be rewritten since > it refers to SSM.) I was referring to the fact that the first 96 bits of the address are generated using the specifications in the other draft. The 32-bit group ID is then generated using the techniques in this draft. Given the restrictions in RFC 2373 and its follow-up, all multicast addresses are composed of a 96-bit prefix and a 32-bit group-ID. > > Section 5 on randomness says: > The group ID portion of the address is set using either a pseudo- > random 32-bit number or a 32-bit number created using the guidelines > in [RFC 1750]. Possible approaches to creating a pseudo-random > number include using an MD5 message-digest [RFC 1321] or portions of > an NTP [RFC 1305] timestamp. > I think the second sentence should be dropped since it could easily be > read as taking the MD5 digest of a constrant string, or > the current year+month (high-order bits of timestamp), are good enough as > random numbers. I can drop that sentence. It was added because I had several comments asking for suggestions on creating these random numbers. But, the reference to RFC 1750 should be enough. > > Thus the paragraph on high-order but set to '1' imply that the > high-order bit should always be the same as the T flag in the address? > If so it would make sense to explicitly state that. > If not I'd like to understand the relationship between the two better. Ah, good point. The high-order bit does reflect the setting of the T bit. I can add text to elaborate on that. > > IANA considerations section seem to be incorrect on the last range. > The intent as I understand it is not allow private use but that > the range is reserved for use that conforms to this specification (i.e. > random group IDs). Good catch. The last range is for dynamic allocation use. > > Also, the IANA considerations seem to be missing the request that IANA > establish a new registry for permanent group IDs (range 0x40000000-0x7fffffff) > which is different than the existing registry for IPv6 multicast addresses. I will try and bolster that section a little to spell it out in more concrete terms. Thanks, 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 Thu Sep 27 16:59:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RNxi7B022005 for ; Thu, 27 Sep 2001 16:59:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8RNxh48022002 for ipng-dist; Thu, 27 Sep 2001 16:59:43 -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+Sun/8.12.0) with ESMTP id f8RNxe7B021993 for ; Thu, 27 Sep 2001 16:59:40 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNv8Z01390 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:57:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IE597B010456 for ; Tue, 18 Sep 2001 07:05:09 -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 HAA08498 for ; Tue, 18 Sep 2001 07:05:09 -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 IAA02272 for ; Tue, 18 Sep 2001 08:05:01 -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 f8IE4ep28868 for ; Tue, 18 Sep 2001 10:04:40 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:04:46 -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 SXTX1C0P; Tue, 18 Sep 2001 10:04:41 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2C; Tue, 18 Sep 2001 10:04:42 -0400 Message-ID: <3BA7547C.892C094D@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:04: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: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: > > > See RFC 2908. > > At least that reference is missing from the document. > But I see a mismatch between the draft and RFC 2908 since the latter > seems to say that an application can request multicast addresses with > a particular lifetime. With the uni-based addresses there can be no > way for the application to request a lifetime. > How can this be resolved? Well, the first thing is to actually reference 2908 in the doc. :) I will make sure that 2908 is part of a section describing the changes between v4 and v6 mcast allocation. 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 Thu Sep 27 17:00:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S0097B022046 for ; Thu, 27 Sep 2001 17:00:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S008Yg022045 for ipng-dist; Thu, 27 Sep 2001 17:00:08 -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+Sun/8.12.0) with ESMTP id f8S0057B022038 for ; Thu, 27 Sep 2001 17:00:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNvXk01420 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:57:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IEBM7B010476 for ; Tue, 18 Sep 2001 07:11:22 -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 HAA09947 for ; Tue, 18 Sep 2001 07:11:22 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19368 for ; Tue, 18 Sep 2001 07:11:21 -0700 (PDT) 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 f8IEAqp00075 for ; Tue, 18 Sep 2001 10:10:52 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:11: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 SXTX1C08; Tue, 18 Sep 2001 10:11:05 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2H; Tue, 18 Sep 2001 10:11:06 -0400 Message-ID: <3BA755FC.EFA35E33@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:11:09 -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: Dave Thaler CC: Erik Nordmark , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: <2E33960095B58E40A4D3345AB9F65EC10290E73C@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, Dave Thaler wrote: > > How does the application requesting a particular lifetime effect the > > lifetime that the routers use when advertising the unicast prefix? > > It doesn't. > In the abstract API, the application supplies a minimum and desired > lifetime. If the app says [0, 6 months] and the host knows that > the unicast prefix is valid for 1 week, it can tell the app it has > it for one week (and the app can renew it at any time). That was my intent. It fits the existing v4 mcast allocation architecture. A host may request an address for ANY particular lifetime, but there are no guarantees that the requested lifetime can be honored. > > > Are you envisioning some new protocol to inform the routers (and the > > system > > admin, ISP, RIR) that allocated the unicast prefix that it needs to > > stay around for long enough to satisfy the applications request? :-) > > Gosh I hope not :) Agreed! I am trying to reduce the number of protocols. > > > So while there might be an abstract API that allows the application > > to ask, the scheme in uni-based-mcast doesn't seem to have the pieces > > so that the system can honor such a request; at least not with a > strict > > interpretation of the relationship between the RFC 2462 notion of > lifetime > > of the unicast prefix, and the presumed lifetime of the derived > multicast' > > address. > > If the app says [6 months, 6 months] then personally I would expect the > host to fail the request if it only has a unicast prefix lifetime of 1 > week. > I think your question is really: should we allow such a host to grant > a request for 6 months if it only has a unicast prefix lifetime of 1 > week? > > In my previous email, if there is a need to allow this (and I'm not > saying > there is), then we'd have to just say it SHOULD NOT, and say that after > the unicast lifetime, the multicast packets are not guaranteed to be > routed. I have no problems changin the text to SHOULD NOT. > > > Hence my question whether the intent is to have such a strict > relationship > > or not. > > I'd like to hear others opinions, but I think that is the authors' > intent. It was my intent. IF we are going to try and eliminate the multi- layered allocation architecture, there needs to be some controlling mechanism and the only one I could find was the unicast prefix in the RAs. 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 Thu Sep 27 17:00:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S00Q7B022066 for ; Thu, 27 Sep 2001 17:00:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S00P13022065 for ipng-dist; Thu, 27 Sep 2001 17:00:25 -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+Sun/8.12.0) with ESMTP id f8S00N7B022058 for ; Thu, 27 Sep 2001 17:00:23 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNvpL01450 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:57:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IEJW7B010504 for ; Tue, 18 Sep 2001 07:19:32 -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 HAA02770 for ; Tue, 18 Sep 2001 07:19:33 -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 IAA13089 for ; Tue, 18 Sep 2001 08:19:24 -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 f8IEIrp01307 for ; Tue, 18 Sep 2001 10:18:53 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 10:19:14 -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 SXTX1DAL; Tue, 18 Sep 2001 10:19:13 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2P; Tue, 18 Sep 2001 10:19:13 -0400 Message-ID: <3BA757E4.F845D000@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:19:16 -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: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: > > > If the app says [6 months, 6 months] then personally I would expect the > > host to fail the request if it only has a unicast prefix lifetime of 1 > > week. > > I think your question is really: should we allow such a host to grant > > a request for 6 months if it only has a unicast prefix lifetime of 1 > > week? > > Bingo! > > The related question is: are there applications which would fail to function > today if you applied the constraints imposed by this today i.e. the > fact that no multicast addresses could be allocated by the API > with an end time more than a week into the future? > (For this excercise it would make sense to consider the IPv4 multicast > applications as well as the IPv6 multicast applications that exist just > to try to understand the scope of the applications dependency on multicast > address lifetimes.) As I said in an earlier response, this is not a v6 specific issue. Applications/stacks/nodes/etc. using MAPCAP in v4 will have to deal with the aspect of mcast address leases not filling their initial lifetime requests. Maybe someone with more operational experience than me with MAPCAP allocated addresses will describe how they deal with lease renewal and advertisement issues. I don't see usage of dynamically allocated addresses being requested weeks in advance for one day use. I could be wrong, but I haven't seen any behave in that manner. > > > In my previous email, if there is a need to allow this (and I'm not > > saying > > there is), then we'd have to just say it SHOULD NOT, and say that after > > the unicast lifetime, the multicast packets are not guaranteed to be > > routed. > > I fail to understand why routing might fail. Could you explain? > I do understand that there is a different probability of allocating duplicate > uni-based mcast addresses should the unicast prefix be assigned to another > entity, but this doesn't lead to routing failing unless you are assuming > that routing will do something it doesn't currently do. I think one possible example is with SSM. The first hop router may receive an IGMPv3 join with an old prefix that has been renumbered. It then tries to send the SPT Join to the wrong network. That network doesn't exist and so the Join fails and the multicast traffic never flows. 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 Thu Sep 27 17:00:46 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S00j7B022094 for ; Thu, 27 Sep 2001 17:00:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S00jHr022092 for ipng-dist; Thu, 27 Sep 2001 17:00:45 -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+Sun/8.12.0) with ESMTP id f8S00f7B022078 for ; Thu, 27 Sep 2001 17:00:41 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNw9V01480 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:58:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IEO37B010515 for ; Tue, 18 Sep 2001 07:24: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 HAA06032 for ; Tue, 18 Sep 2001 07:24:04 -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 IAA24496 for ; Tue, 18 Sep 2001 08:24:50 -0600 (MDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8IENYp01976 for ; Tue, 18 Sep 2001 10:23:34 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 18 Sep 2001 10:23:45 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBXMCBPK; Tue, 18 Sep 2001 10:23:44 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SB2T; Tue, 18 Sep 2001 10:23:42 -0400 Message-ID: <3BA758F0.94940360@americasm06.nt.com> Date: Tue, 18 Sep 2001 10:23: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: Erik Nordmark CC: Dave Thaler , Thomas Narten , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, I would love to see more usage of DNS for multicast. There are examples today of mcast addresses being registered in DNS. Go to your favorite resolver and see what address you get back when you query all-routers.mcast.net. I would have to go and check, but I don't recall discussion of the use of DNS within the MALLOC Architecture. However, it would seem rather easy to use DDNS to add MAPCAP allocated addresses to the DNS. Brian Erik Nordmark wrote: > > > This is a good question, and in fact it's not multicast specific. > > Here's the unicast equivalent: > > > > You're advertising a unicast streaming session on a web page that > > will start in two weeks (and last one day). You use a URL with > > a literal unicast address in it. However, you don't know from > > your RA that your address will definitely be the same by then. > > Again, this would seem like it might be a problem. > > Yes, but for unicast there is a clear possibility of using a hostname instead > of a literal IP address in such a case. In fact I suspect most unicast > usage of this nature uses a hostname. > > Is such a mechanism possible to use for multicast? (i.e. advertise a FQDN on > web pages, in SDP, etc and have the hosts do a DNS lookup to join the > session?) > Does the malloc architecture take into account using the DNS in > such a way? > > Erik > > > I think the same dangers and possible solutions exist for both > > unicast and multicast. Some solutions, with varying degrees of > > "goodness", might include: > > 1) Change the web page if the address changes, and hope people > > don't use an out-of-date web page. > > 2) Don't use address literals in the URL, and hope that people > > don't resolve the name to an address until close to the > > session starts. > > 3) Make the admin have knowledge somehow that the address > > will indeed be valid throughout the life of the session > > advertised. > > > > The point is that pretty much any solution you use > > for unicast can be used for multicast as well. > > > > -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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 17:01:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S0197B022128 for ; Thu, 27 Sep 2001 17:01:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S0188T022125 for ipng-dist; Thu, 27 Sep 2001 17:01:08 -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+Sun/8.12.0) with ESMTP id f8S0157B022116 for ; Thu, 27 Sep 2001 17:01:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNwXA01512 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:58:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IFT37B010659 for ; Tue, 18 Sep 2001 08:29:03 -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 IAA24862 for ; Tue, 18 Sep 2001 08:29:04 -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 JAA01826 for ; Tue, 18 Sep 2001 09:29:51 -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 f8IFSYp12502 for ; Tue, 18 Sep 2001 11:28:34 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com; Tue, 18 Sep 2001 11:28:30 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBXMCKXR; Tue, 18 Sep 2001 11:28:30 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SBL2; Tue, 18 Sep 2001 11:28:28 -0400 Message-ID: <3BA7681E.8F41CFEA@americasm06.nt.com> Date: Tue, 18 Sep 2001 11:28:30 -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: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: > > > > I fail to understand why routing might fail. Could you explain? > > > I do understand that there is a different probability of allocating duplicate > > > uni-based mcast addresses should the unicast prefix be assigned to another > > > entity, but this doesn't lead to routing failing unless you are assuming > > > that routing will do something it doesn't currently do. > > > > I think one possible example is with SSM. The first hop router > > may receive an IGMPv3 join with an old prefix that has been > > renumbered. It then tries to send the SPT Join to the wrong > > network. That network doesn't exist and so the Join fails and > > the multicast traffic never flows. > > Brian, > > I thought uni-based mcast addresses for SSM has an all zero prefix component. > (That's what the uni-based draft says.) > Are you referring to such a prefix or the IP source address? Argh. I was trying to use a simple example, which doesn't make the point. You are correct about the zero prefix. > > Clearly SSM, which explicitly identifies a group by the pair address, Multicast destination>, is likely to barf when the IP source address > is no longer valid for the sender. > Depending on whether the document is correct or not about having a zero > prefix in the SSM multicast destination, this may or may not be > an issue for the actual multicast address. OK, I have had a little time to think about some of these comments. The lifetime of the mcast address allocation may still have an affect on the routing. Since mcast forwarding is based on an state, due to RPF checks, as long as G is not changed by the application sending the data, forwarding should work. Except for the fact that if G changes due to a prefix lifetime expiration, S may/will change as well. This holds true for SSM or ASM. If S is not the one who requested G from the MADCAP server, then it will be arbitrary as to whether or not S will change when G changes due to a lifetime expiration. 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 Thu Sep 27 17:01:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S01m7B022178 for ; Thu, 27 Sep 2001 17:01:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S01lNf022177 for ipng-dist; Thu, 27 Sep 2001 17:01:47 -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+Sun/8.12.0) with ESMTP id f8S01i7B022165 for ; Thu, 27 Sep 2001 17:01:44 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8RNxCS01542 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 16:59:12 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8IIib7B011162 for ; Tue, 18 Sep 2001 11:44:37 -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 LAA16786 for ; Tue, 18 Sep 2001 11:44:39 -0700 (PDT) Received: from fridge.docomo-usa.com ([216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05703 for ; Tue, 18 Sep 2001 11:44:38 -0700 (PDT) Received: from mobilebeatles (dhcp26.docomo-usa.com [172.21.96.26]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f8IImgu01104 for ; Tue, 18 Sep 2001 11:48:42 -0700 (PDT) Message-ID: <001501c14073$17afd2e0$1a6015ac@docomousa.com> From: "Youngjune Lee Gwon" To: "ipng" Subject: KAME IPv6 Router Date: Tue, 18 Sep 2001 11:52:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Hi, I'm trying to build IPv6 router using kame implementation, using BSD running PCs. Are there special instructions that I should have noted of? Does the kame v6 software package distinguish between routing module and a v6 node module, etc.? Thank you in advance, ================================================= Youngjune Gwon DoCoMo Communications Laboratories USA ================================================= -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 17:02:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S02Z7B022255 for ; Thu, 27 Sep 2001 17:02:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S02Yvh022254 for ipng-dist; Thu, 27 Sep 2001 17:02:34 -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+Sun/8.12.0) with ESMTP id f8S02W7B022242 for ; Thu, 27 Sep 2001 17:02:32 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8S000501573 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 17:00:00 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8JC4x7B012766 for ; Wed, 19 Sep 2001 05:04:59 -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 FAA24346 for ; Wed, 19 Sep 2001 05:05:00 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA06740 for ; Wed, 19 Sep 2001 05:04:56 -0700 (PDT) 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 f8JC4Qp17571 for ; Wed, 19 Sep 2001 08:04:26 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Wed, 19 Sep 2001 08:04:33 -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 SXTX1118; Wed, 19 Sep 2001 08:04:33 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SBWZ; Wed, 19 Sep 2001 08:04:33 -0400 Message-ID: <3BA889D3.34849A17@americasm06.nt.com> Date: Wed, 19 Sep 2001 08:04:35 -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: Erik Nordmark CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: uni-based-mcast and malloc-ipv6-guide References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Erik Nordmark wrote: > One of my comments/questions in the first mail (which you passed to Brian > as an editorial one) was the issue of what aspects of the IPv4 stuff we > need and need not carry forward to IPv6. > > Clearly(?) the documents remove the need for MASC for IPv6. Is that all? > Will uni-based have any effect on MBGP and BGMP? > (I can't find an BGMP draft to even have a peek.) The text in the draft will be changed to point out how uni-based mcast removes the need for inter-domain mcast allocation protocols. From my point of view, I don't see them really affecting MBGP or BGMP. From some discussions I have had with Dave, uni-based mcast MAY help make BGMP simpler... > > These questions might seem naïve to you, but I suspect there are implementors > and operators that might have the same questions. No argument there. I am trying to find some time this week to make some updates to these docs so that we can keep them moving. 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 Thu Sep 27 17:03:06 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S0367B022324 for ; Thu, 27 Sep 2001 17:03:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S035cK022322 for ipng-dist; Thu, 27 Sep 2001 17:03:05 -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+Sun/8.12.0) with ESMTP id f8S0317B022301 for ; Thu, 27 Sep 2001 17:03:01 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8S00Tt01603 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 17:00:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8K0hs7B014414; Wed, 19 Sep 2001 17:43:54 -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 RAA24888; Wed, 19 Sep 2001 17:43:56 -0700 (PDT) From: tisv@telenorisv.com Received: from fep2.mta.online.no (challenger-s.online.no [148.122.208.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03706; Wed, 19 Sep 2001 17:43:55 -0700 (PDT) Received: from [10.122.209.35] by fep2.mta.online.no (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20010920004352.TEBX392.fep2.mta.online.no@[10.122.209.35]>; Thu, 20 Sep 2001 02:43:52 +0200 To: G.Tsirtsis@flarion.com, gtsirt@hotmail.com, sltsao@itri.org.tw CC: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: Fwd: [mobile-ip] IPv6 over Mobile IPv4 Date: Thu, 20 Sep 2001 2:44:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20010920004352.TEBX392.fep2.mta.online.no@[10.122.209.35]> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk George and Charles, FYI, the Internet Draft http://search.ietf.org/internet-drafts/draft-mccann-mobileip-ipv6mipv4-00.txt was recently submitted and announced on the Mobile IP mailing list. While we are waiting for the security-issues of MIPv6 to be resolved, I find the proposed solution promising. It provides a mechanism for IPv6 mobility that also incorporates AAA functionality. In the long run, the proposed idea can be relevant for IPv4 to IPv6 transition. Their mechanism might be useful to your "Dual Stack Moving" efforts. It is definitely related to my own Dual Stack Mobile IP draft, which I plan to rewrite, simplify and adapt to their proposal. Earlier, we have talked about a framework for dual stack mobility. Perhaps their draft could be a good starting point for that discussion? -- Paal --------------------------------------------------------------------- From: Pete McCann >Reply-To: mobile-ip@sunroof.eng.sun.com >To: mobile-ip@sunroof.eng.sun.com >CC: pcalhoun@diameter.org, tom.hiller@lucent.com >Subject: [mobile-ip] IPv6 over Mobile IPv4 >Date: Thu, 13 Sep 2001 17:39:15 -0500 > >Hi, > >We (Pat Calhoun, Tom Hiller, and myself) recently wrote a draft >describing a method for running IPv6 traffic while using Mobile IPv4 >signaling for mobility management and security. We submitted it today >to internet-drafts; you can find an advance copy at: > >http://www.diameter.org/draft-mccann-mobileip-ipv6mipv4-00.txt > >Basically, this could serve as an interim solution while we wait for >all of the Mobile IPv6 security work to converge. It would allow us >to use the existing Mobile IPv4 security model, including AAA, for >securing registration requests, while providing IPv6 service to >dual-stack mobile nodes. It may also help ease the overall transition >to IPv6 because it only requires IPv6 support in the MN, FA, HA, and >home network, while the network between the FA and HA could be a >legacy IPv4 cloud. > >The draft itself is fairly straightforward; we would appreciate >comments on the list and would like to see if there is interest in >making this a working group item. > >-Pete -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 17:08:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S08q7B022701 for ; Thu, 27 Sep 2001 17:08:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S08p04022700 for ipng-dist; Thu, 27 Sep 2001 17:08:51 -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+Sun/8.12.0) with ESMTP id f8S08m7B022692 for ; Thu, 27 Sep 2001 17:08: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 RAA10416 for ; Thu, 27 Sep 2001 17:08:51 -0700 (PDT) Received: from bsdbox.org (bsdbox.org [66.114.64.95]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10695 for ; Thu, 27 Sep 2001 17:08:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=bsdbox.org ident=lazy) by bsdbox.org with esmtp (Exim 3.30 #1) id 15mlCh-0004sX-00; Thu, 27 Sep 2001 20:08:31 -0400 Message-ID: <3BB3BF7E.236A080@bsdbox.org> Date: Thu, 27 Sep 2001 20:08:30 -0400 From: lazy X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.0.38 i386) X-Accept-Language: en MIME-Version: 1.0 To: Youngjune Lee Gwon CC: ipng@sunroof.eng.sun.com Subject: Re: KAME IPv6 Router References: <001501c14073$17afd2e0$1a6015ac@docomousa.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Take a look at the NetBSD Documentation IPv6 page: http://www.netbsd.org/Documentation/network/ipv6/ http://www.hs247.com/ should also be pretty useful. // lazy Youngjune Lee Gwon wrote: > > Hi, > > I'm trying to build IPv6 router using kame implementation, using BSD running > PCs. Are there special instructions that I should have noted of? > > Does the kame v6 software package distinguish between routing module and a > v6 node module, etc.? > > Thank you in advance, > ================================================= > Youngjune Gwon > DoCoMo Communications Laboratories USA > ================================================= > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ..:: Too many people... Too few neurons. PGP: RSA 2048bit 0xB7673053 (keyserver.pgp.com) Web: http://packetjunkie.net http://bsdbox.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 17:09:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S09X7B022721 for ; Thu, 27 Sep 2001 17:09:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S09XjR022720 for ipng-dist; Thu, 27 Sep 2001 17:09: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+Sun/8.12.0) with ESMTP id f8S09V7B022713 for ; Thu, 27 Sep 2001 17:09:31 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8S06x201633 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 17:06:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8PLgn7B028653 for ; Tue, 25 Sep 2001 14:42: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 OAA08258 for ; Tue, 25 Sep 2001 14:42:50 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA08163 for ; Tue, 25 Sep 2001 15:42:39 -0600 (MDT) Received: from 157.54.9.104 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Sep 2001 14:42:08 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 25 Sep 2001 14:42:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipngwg-default-addr-select-05.txt Date: Tue, 25 Sep 2001 14:41:36 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCF3@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipngwg-default-addr-select-05.txt Thread-Index: AcFFjMX83dnEeBqwSHKbr9+5UzH49AAYwBvQ From: "Richard Draves" To: "Pekka Savola" Cc: "marcelo" , X-OriginalArrivalTime: 25 Sep 2001 21:42:06.0762 (UTC) FILETIME=[EC16D0A0:01C1460A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8PLgn7B028654 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Am I missing something here, or are we changing the > definition/expected use of 'deprecated address' here? > Previously, I think, it was very clearly not to be used as a > source address, to be phased out when connections using it die off. No, this is not a change. Using a deprecated source address is clearly discouraged. It's one of the high priority rules in source address selection. As I said earlier, in normal operation you should have available a preferred address of the correct scope. If for some reason one is not available (probably indicating a configuration error in the site), then the host much choose the lesser of two evils (using a deprecated address or using an address of mismatched scope). Does anyone else think that the order of these two rules should be reversed, so that choosing a non-deprecated source address is more important than choosing a source address of the appropriate scope? Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 17:11:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8S0B47B022783 for ; Thu, 27 Sep 2001 17:11:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8S0B4Hn022782 for ipng-dist; Thu, 27 Sep 2001 17:11:04 -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+Sun/8.12.0) with ESMTP id f8S0B07B022775 for ; Thu, 27 Sep 2001 17:11:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id f8S08Sh01663 for ipng@sunroof.eng.sun.com; Thu, 27 Sep 2001 17:08:28 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8RH8O7B017724 for ; Thu, 27 Sep 2001 10:08: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 KAA14772 for ; Thu, 27 Sep 2001 10:08:26 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26799 for ; Thu, 27 Sep 2001 10:08:24 -0700 (PDT) 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 f8RH7pp26470 for ; Thu, 27 Sep 2001 13:07:52 -0400 (EDT) Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com; Thu, 27 Sep 2001 13:08: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 TTSTRS68; Thu, 27 Sep 2001 13:08:01 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87S1WG; Thu, 27 Sep 2001 13:08:01 -0400 Message-ID: <3BB35CFA.DB63556@americasm06.nt.com> Date: Thu, 27 Sep 2001 13:08:10 -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: Thomas Narten CC: Dave Thaler , ipng@sunroof.eng.sun.com, malloc@catarina.usc.edu Subject: Re: draft-ietf-ipngwg-uni-based-mcast-03.txt References: <200109271655.f8RGtYj02937@hygro.adsl.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > > > If plen = 0, then isn't the "network prefix" portion 0 bits long? > > That would be one interpretation. Another possibly would be that the > network prefix should have special meaning, other than looking at the > first plen bits. I guess I'm asking if it would make sense to do so, > for (say) debugging purposes. The problem is that SSM requires all 128-bits to represent the source. So, it seems simpler to indicate in some manner that the destination multicast address is SSM and refer to the source address to determine the "owner". > > > The SSM range should be FF3x::/12 (and this is mentioned in the SSM > > overview doc today). > > draft-holbrook-ssm-arch-02.txt talks about reserving ff3x and ff2x for > SSM. I believe that this draft is in the process of being revised prior to a last call. > > draft-ietf-ssm-overview-01.txt says: > > > Source-Specific Multicast (SSM) : This is the multicast service model > > defined in [SSM-ARCH]. An IP datagram is transmitted by a source S to > > an SSM destination address G, and receivers can receive this datagram > > by subscribing to channel (S,G). SSM is derived from EXPRESS [EXPRESS] > > and supports one-to-many multicast.The address range 232/8 has been > > assigned by IANA [IANA-ALLOC] for SSM service in IPv4. For IPv6, the > > range FF3x::/12 is defined for SSM services [SSM-IPV6]. > > But that range also covers the address that are defined in this > document, including non-SSM addresses! (And it doesn't cover the plen > field that defines whether the address is SSM or not!!) So things do > not seem to be in sync. So, since I am the common denominator between the two drafts, I must claim responsibility. The SSM overview draft should state that FF3x::/32 is the SSM range for IPv6. 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 Fri Sep 28 03:13:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SADr7B025547 for ; Fri, 28 Sep 2001 03:13:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SADrSB025546 for ipng-dist; Fri, 28 Sep 2001 03:13: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+Sun/8.12.0) with ESMTP id f8SADn7B025539 for ; Fri, 28 Sep 2001 03:13:49 -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 DAA24957 for ; Fri, 28 Sep 2001 03:13:50 -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 EAA11942 for ; Fri, 28 Sep 2001 04:14: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 f8SACLp02086; Fri, 28 Sep 2001 17:12:21 +0700 (ICT) From: Robert Elz To: "Richard Draves" cc: "Pekka Savola" , "marcelo" , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-default-addr-select-05.txt In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA80355FCF3@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA80355FCF3@red-msg-06.redmond.corp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Sep 2001 17:12:21 +0700 Message-ID: <2084.1001671941@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 25 Sep 2001 14:41:36 -0700 From: "Richard Draves" Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FCF3@red-msg-06.redmond.corp.microsoft.com> | Does anyone else think that the order of these two rules should be | reversed, so that choosing a non-deprecated source address is more | important than choosing a source address of the appropriate scope? For the case where the deprecated address is of smaller scope than the preferred one, yes, I think that would be the right way. On the other hand, I see the chances of deprecated link local or site local addresses ever being seen as almost too remote to worry about. I suppose the one possibility is for internal site subnet renumbering (so old site local addresses are deprecated) or a desire to phase out use of site local (or an admin screwp or something.) In that instance using a global address instead of the deprecated site local seems like a clear win. It is the case where the preferred address is of smaller scope than the deprecated one which is of real interest .. to analyse that I think we need to enumerate the ways we can see where we might get into that state, and then see which of those, if any, is actually a state where the order actually matters much, and then just how important that is. The ones I can imagine (please, contribute more) are... (I will use "global" just to avoid having to say "the address with the wider scope - the same would apply to a deprecated site local with a "preferred" link local, which is really a pretty silly concept) A The admin screwup - eg: a global address is deprecated when it wasn't meant to be. B global addresses are being phased out on a link (nodes to be restricted to intra site communications only), so all the global addresses are deprecated before being removed C Address adverts based upon availability of connectivity to the relevant provider, and no links are currently functioning, so all ISP based addresses (globals) are deprecated, until a new ISP link starts working (or restarts working). (Yes, this assumes functionality that doesn't currently exist that I know of). more?? The third case (C) is not very interesting, which address is used probably doesn't matter - only on-site communications are possible, and either address would do for that. For B, using the site local (the preferred) address over the deprecated address seems like the clear winner - that is going to have to happen soon anyway, the only question is just when the line in the sand is drawn (when the addresses went deprecated, or when they're finally withdrawn). Here, the original idea of deprecated addresses being only to permit existing connections time to gracefully close (or somehow switch to new addresses), seems to fit. Prefer the preferred address, whatever scope. For A, it is harder - to keep things functioning, using the deprecated address is the obvious answer, that way the error can be corrected, and the address returned to being preferred, and no-one really even notices, everything just keeps working. So, preferring the address of the appropriate scope seems like the winner there. But if that's what's done, will the error actually be noticed? Or would it be better to provoke investigation by causing some new communications to fail (outgoing ones, all the incoming stuff will just keep on working, as would anything where site local addresses would work)? If that would be a better outcome, then preferring the preferred address (whatever scope) seems like a better choice. Are there other ways that we might get into the situation where the order of those rules might make a difference? Given the above, I'm tempted to switch the order, though my gut feeling is that the current order is better. Weird... 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 Sep 28 05:58:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SCwm7B025678 for ; Fri, 28 Sep 2001 05:58:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SCwlZr025677 for ipng-dist; Fri, 28 Sep 2001 05:58:47 -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+Sun/8.12.0) with ESMTP id f8SCwh7B025670 for ; Fri, 28 Sep 2001 05:58:43 -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 FAA07450 for ; Fri, 28 Sep 2001 05:58:42 -0700 (PDT) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26918 for ; Fri, 28 Sep 2001 05:58:41 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56]) by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f8SCwBp28230 for ; Fri, 28 Sep 2001 08:58:11 -0400 (EDT) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Fri, 28 Sep 2001 08:58:18 -0400 Received: from zbl6c000.corpeast.baynetworks.com ([132.245.205.50]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TK5WYHTP; Fri, 28 Sep 2001 08:58:12 -0400 Received: from americasm06.nt.com (deathvalley.us.nortel.com [47.141.98.23]) by zbl6c000.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RS87SFAB; Fri, 28 Sep 2001 08:58:10 -0400 Message-ID: <3BB473E5.12F0791B@americasm06.nt.com> Date: Fri, 28 Sep 2001 08:58:13 -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: Srinivasan Narasimhan CC: ipng@sunroof.eng.sun.com Subject: Re: Question on new MIBs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, that is the intent. The new MIBs will be IP version independent. Brian Srinivasan Narasimhan wrote: > > Hi, > > Are the new drafts that update IP, TCP and UDP MIBs going to > obselete the existing IPv6 MIB RFCs 2465 (IP), 2452 (TCP) and > 2454 (UDP)? Thanx a lot in advance for the replies. > > Cheers, > > Cheenu. > 1-408-447-4289 > TN-447-4289 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 28 08:53:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SFr07B026370 for ; Fri, 28 Sep 2001 08:53:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SFr08d026369 for ipng-dist; Fri, 28 Sep 2001 08:53:00 -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+Sun/8.12.0) with ESMTP id f8SFqu7B026362 for ; Fri, 28 Sep 2001 08:52:56 -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 IAA28532 for ; Fri, 28 Sep 2001 08:52:59 -0700 (PDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA17639 for ; Fri, 28 Sep 2001 09:52:47 -0600 (MDT) Received: from 157.54.8.23 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 28 Sep 2001 08:51:47 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Sep 2001 08:51:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipngwg-default-addr-select-05.txt Date: Fri, 28 Sep 2001 08:51:46 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA80355FD02@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipngwg-default-addr-select-05.txt Thread-Index: AcFIBh4K7VRNJVKCRKmCZbt4IpLKkgALVtdA From: "Richard Draves" To: "Robert Elz" Cc: "Pekka Savola" , "marcelo" , X-OriginalArrivalTime: 28 Sep 2001 15:51:46.0779 (UTC) FILETIME=[7A7132B0:01C14835] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8SFqv7B026363 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A The admin screwup - eg: a global address is deprecated when it > wasn't meant to be. > > B global addresses are being phased out on a link (nodes to be > restricted to intra site communications only), so all the global > addresses are deprecated before being removed > > C Address adverts based upon availability of connectivity to the > relevant provider, and no links are currently functioning, so > all ISP based addresses (globals) are deprecated, until > a new ISP > link starts working (or restarts working). (Yes, this assumes > functionality that doesn't currently exist that I know of). > > more?? > > The third case (C) is not very interesting, which address is > used probably doesn't matter - only on-site communications > are possible, and either address would do for that. Yes, although it may affect the ICMP error that will be returned. If the host selects a preferred site-local address or link-local address, then it will probably get back an scope-exceeded destination-unreachable error, whereas if it selects one of its deprecated global addresses then it will probably get a no-route destination-unreachable. I think the latter is more useful in this situation. > For B, using the site local (the preferred) address over the > deprecated address seems like the clear winner - that is > going to have to happen soon anyway, the only question is > just when the line in the sand is drawn (when the addresses > went deprecated, or when they're finally withdrawn). Here, > the original idea of deprecated addresses being only to > permit existing connections time to gracefully close (or > somehow switch to new > addresses), seems to fit. Prefer the preferred address, > whatever scope. The question in B is, why is the host trying to send to a global address if the administrator is phasing out the use of global addresses? Perhaps the admin first introduces site-local addressing across the site (if it's not already in place), then later deprecates global addresses inside the site, and this causes hosts to remove their global addresses from the DNS. But there is a window in which DNS caches still return global addresses for other hosts within the site whereas the host's own global address is already deprecated. The global addresses should not be made invalid until the DNS caches are all cleared, so choosing the global source address should work. In fact, the destination address ordering will cause the site-local destination to be tried before the global destination so this case shouldn't happen. > For A, it is harder - to keep things functioning, using the > deprecated address is the obvious answer, that way the error > can be corrected, and the address returned to being > preferred, and no-one really even notices, > everything just keeps working. So, preferring the address > of the appropriate > scope seems like the winner there. But if that's what's > done, will the > error actually be noticed? Or would it be better to provoke > investigation > by causing some new communications to fail (outgoing ones, > all the incoming stuff will just keep on working, as would > anything where site local addresses > would work)? If that would be a better outcome, then preferring the > preferred address (whatever scope) seems like a better choice. Well, I think it's better to maintain communication. :-) An implementation could log an error when it chooses a deprecated source address so that admins will notice. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 09:04:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SG4h7B026506 for ; Fri, 28 Sep 2001 09:04:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SG4hQB026505 for ipng-dist; Fri, 28 Sep 2001 09:04:43 -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+Sun/8.12.0) with ESMTP id f8SG4e7B026498 for ; Fri, 28 Sep 2001 09:04:40 -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 JAA05393 for ; Fri, 28 Sep 2001 09:04:42 -0700 (PDT) Received: from nukeserv.atinucleus.com (atimail.atinucleus.com [208.239.168.2]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA21943 for ; Fri, 28 Sep 2001 09:04:41 -0700 (PDT) Message-ID: <004a01c14837$168216f0$26a8efd0@atinucleus.com> Reply-To: "Tammy Leino" From: "Tammy Leino" To: Subject: RFC 2710 Date: Fri, 28 Sep 2001 11:03:16 -0500 Organization: ati MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C1480D.2CEE8B50" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C1480D.2CEE8B50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In regards to MLD, should a node transmit an unsolicited report for a = multicast address of link-local scope? If so, why? Thank you for your time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tammy Leino Software Engineer Accelerated Technology, Inc. 720 Oak Circle Drive E., Mobile, AL 36609 (251) 661-5770v (251) 661-5788f (800) GOT-NUKE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Nucleus. All You NEED in an RTOS. Royalty Free." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------=_NextPart_000_0047_01C1480D.2CEE8B50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In regards to MLD, should a node = transmit an=20 unsolicited report for a multicast address of link-local scope?  If = so,=20 why?
 
Thank you for your time.
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tammy=20 Leino
Software Engineer
Accelerated Technology, Inc.
720 Oak = Circle=20 Drive E., Mobile, AL  36609
(251) 661-5770v  (251) = 661-5788f =20 (800)=20 GOT-NUKE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~
"Nucleus. =20 All You NEED in an RTOS.  Royalty=20 Free."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------=_NextPart_000_0047_01C1480D.2CEE8B50-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 09:20:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SGKx7B026732 for ; Fri, 28 Sep 2001 09:20:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SGKxTA026731 for ipng-dist; Fri, 28 Sep 2001 09:20: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+Sun/8.12.0) with ESMTP id f8SGKu7B026724 for ; Fri, 28 Sep 2001 09:20: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 JAA19443 for ; Fri, 28 Sep 2001 09:20:58 -0700 (PDT) Received: from nukeserv.atinucleus.com (atimail.atinucleus.com [208.239.168.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id KAA01252 for ; Fri, 28 Sep 2001 10:21:56 -0600 (MDT) Message-ID: <008301c14839$5bc61b10$26a8efd0@atinucleus.com> Reply-To: "Tammy Leino" From: "Tammy Leino" To: Subject: Microsoft Windows 2000 IPv6 implementation Date: Fri, 28 Sep 2001 11:19:32 -0500 Organization: ati MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01C1480F.7241F8C0" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0080_01C1480F.7241F8C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anyone used the Win 2000 implementation of IPv6? I am using it (and = a BSD machine) to test against my embedded implementation of IPv6, and I = am getting strange behavior from the Win 2000 machine. For example, it = does not respond to my Neighbor Solicitations, but it accepts my = Neighbor Advertisements in response to its Neighbor Solicitations, and = every so often it sends a flood of Router Advertisements. If you have used it and noticed the same problems (or other problems), = do you know of any work-arounds? Thank you for any feedback. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tammy Leino Software Engineer Accelerated Technology, Inc. 720 Oak Circle Drive E., Mobile, AL 36609 (251) 661-5770v (251) 661-5788f (800) GOT-NUKE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Nucleus. All You NEED in an RTOS. Royalty Free." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------=_NextPart_000_0080_01C1480F.7241F8C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Has anyone used the Win 2000 = implementation of=20 IPv6?  I am using it (and a BSD machine) to test against my = embedded=20 implementation of IPv6, and I am getting strange behavior from the = Win 2000=20 machine.  For example, it does not respond to my Neighbor = Solicitations,=20 but it accepts my Neighbor Advertisements in response to its Neighbor=20 Solicitations, and every so often it sends a flood of Router=20 Advertisements.
 
If you have used it and noticed the = same problems=20 (or other problems), do you know of any work-arounds?
 
Thank you for any = feedback.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tammy=20 Leino
Software Engineer
Accelerated Technology, Inc.
720 Oak = Circle=20 Drive E., Mobile, AL  36609
(251) 661-5770v  (251) = 661-5788f =20 (800)=20 GOT-NUKE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~
"Nucleus. =20 All You NEED in an RTOS.  Royalty=20 Free."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------=_NextPart_000_0080_01C1480F.7241F8C0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 28 10:18:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SHIg7B026867 for ; Fri, 28 Sep 2001 10:18:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SHIgfO026866 for ipng-dist; Fri, 28 Sep 2001 10:18:42 -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+Sun/8.12.0) with ESMTP id f8SHIc7B026859 for ; Fri, 28 Sep 2001 10:18:38 -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 KAA25191 for ; Fri, 28 Sep 2001 10:18:36 -0700 (PDT) Received: from inet-vrs-02.redmond.corp.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA04465 for ; Fri, 28 Sep 2001 11:18:25 -0600 (MDT) Received: from 157.54.8.23 by inet-vrs-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 28 Sep 2001 10:16:38 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Sep 2001 10:16:37 -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.2966); Fri, 28 Sep 2001 10:16:28 -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.3651); Fri, 28 Sep 2001 10:14:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: RFC 2710 Date: Fri, 28 Sep 2001 10:14:40 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10290E866@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 2710 thread-index: AcFIN8yLERtXcEmzS3qvqSPw9xwDrQACQ5sw From: "Dave Thaler" To: "Tammy Leino" , X-OriginalArrivalTime: 28 Sep 2001 17:14:40.0667 (UTC) FILETIME=[0F1C46B0:01C14841] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id f8SHId7B026860 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tammy Leino [mailto:tleino@atinucleus.com] writes: > In regards to MLD, should a node transmit an unsolicited report for a > multicast address of link-local scope?  If so, why? Yes, except for the link-scoped all-hosts group. One reason is so switches can see which segments have members and not have to flood. -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 Sep 28 13:03:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0) with ESMTP id f8SK3s7B027771 for ; Fri, 28 Sep 2001 13:03:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.0+Sun/8.12.0/Submit) id f8SK3smP027770 for ipng-dist; Fri, 28 Sep 2001 13:03: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+Sun/8.12.0) with ESMTP id f8SK3o7B027763 for ; Fri, 28 Sep 2001 13:03: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 NAA07638 for ; Fri, 28 Sep 2001 13:03:53 -0700 (PDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA26282 for ; Fri, 28 Sep 2001 13:03:53 -0700 (PDT) Received: from 157.54.7.67 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 28 Sep 2001 13:03:40 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 28 Sep 2001 13:03:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: Microsoft Windows 2000 IPv6 implementation Date: Fri, 28 Sep 2001 13:03:24 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8024EFA9E@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Microsoft Windows 2000 IPv6 implementation Thread-Index: AcFIOml9HSqOzU6qRUe7cCDgrUQcvQAHUWXw From: "Richard Draves" To: "Tammy Leino" Cc: X-OriginalArrivalTime: 28 Sep 2001 20:03:24.0771 (UTC) FILETIME=[A18BF330:01C14858] 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_001_01C14858.A166E155" ------_=_NextPart_001_01C14858.A166E155 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable First, msripv6-users@list.research.microsoft.com is a better place for questions about the Microsoft implementation. =20 We haven't received any other reports like this. Most likely your Neighbor Solicitations are malformed in some subtle way. I don't understand the "flood of Router Advertisements" - the Win2k machine won't even send RAs unless you've configured it to be a router. =20 Rich -----Original Message----- From: Tammy Leino [mailto:tleino@atinucleus.com]=20 Sent: Friday, September 28, 2001 9:20 AM To: ipng@sunroof.eng.sun.com Subject: Microsoft Windows 2000 IPv6 implementation Has anyone used the Win 2000 implementation of IPv6? I am using it (and a BSD machine) to test against my embedded implementation of IPv6, and I am getting strange behavior from the Win 2000 machine. For example, it does not respond to my Neighbor Solicitations, but it accepts my Neighbor Advertisements in response to its Neighbor Solicitations, and every so often it sends a flood of Router Advertisements. =20 If you have used it and noticed the same problems (or other problems), do you know of any work-arounds? =20 Thank you for any feedback. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tammy Leino Software Engineer Accelerated Technology, Inc. 720 Oak Circle Drive E., Mobile, AL 36609 (251) 661-5770v (251) 661-5788f (800) GOT-NUKE ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Nucleus. All You NEED in an RTOS. Royalty Free." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------_=_NextPart_001_01C14858.A166E155 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
First,=20 msripv6-users@l= ist.research.microsoft.com=20 is a better place for questions about the Microsoft=20 implementation.
 
We=20 haven't received any other reports like this. Most likely your Neighbor=20 Solicitations are malformed in some subtle way. I don't understand the = "flood of=20 Router Advertisements" - the Win2k machine won't even send RAs unless = you've=20 configured it to be a router.
 
Rich
-----Original Message-----
From: = Tammy Leino=20 [mailto:tleino@atinucleus.com]
Sent: Friday, September 28, = 2001=20 9:20 AM
To: ipng@sunroof.eng.sun.com
Subject: = Microsoft=20 Windows 2000 IPv6 implementation

Has anyone used the Win 2000 = implementation of=20 IPv6?  I am using it (and a BSD machine) to test against my = embedded=20 implementation of IPv6, and I am getting strange behavior from = the Win=20 2000 machine.  For example, it does not respond to my Neighbor=20 Solicitations, but it accepts my Neighbor Advertisements in response = to its=20 Neighbor Solicitations, and every so often it sends a flood of Router=20 Advertisements.
 
If you have used it and noticed the = same problems=20 (or other problems), do you know of any work-arounds?
 
Thank you for any = feedback.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tammy=20 Leino
Software Engineer
Accelerated Technology, Inc.
720 Oak = Circle=20 Drive E., Mobile, AL  36609
(251) 661-5770v  (251)=20 661-5788f  (800)=20 = GOT-NUKE
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~
"Nucleus. =20 All You NEED in an RTOS.  Royalty=20 = Free."
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------_=_NextPart_001_01C14858.A166E155-- --------------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 Sun Sep 30 09:13:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id f8UGD2ML000751 for ; Sun, 30 Sep 2001 09:13:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id f8UGD2vF000750 for ipng-dist; Sun, 30 Sep 2001 09:13: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.1+Sun/8.12.1) with ESMTP id f8UGCxML000743 for ; Sun, 30 Sep 2001 09:12:59 -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 JAA14363 for ; Sun, 30 Sep 2001 09:13:00 -0700 (PDT) Received: from LKLDDC01.GARGANTUAN.COM (145bus8.tampabay.rr.com [24.94.145.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26342 for ; Sun, 30 Sep 2001 10:13:59 -0600 (MDT) Received: by LKLDDC01.GARGANTUAN.COM with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Sep 2001 12:12:53 -0400 Message-ID: <1DA741CA6767A144BAA4F10012536C27A8C2@LKLDDC01.GARGANTUAN.COM> From: "Oliver, Michael W." To: ipng@sunroof.eng.sun.com, 6bone@isi.edu, users@ipv6.org Subject: FreeBSD_4.4 + ipfilter_3.4.20 + IPv6 = headache... Date: Sun, 30 Sep 2001 12:12:48 -0400 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 I realize that this may be somewhat off topic, but please hear me out. I have been spending the past few days trying to build a FreeBSD 4.4 STABLE firewall, using the included ipfilter 3.4.20 port, that supports IPv6 filtering. I have been completely unsuccessful up to now. I have also bypassed the port and downloaded 3.4.20 from ftp://coombs.anu.edu.au/ and, following the instructions from a Zama pdf (ftp://www.zamanetworks.com/pub/knowledgebase/techdocs/Implementing%20an%20I Pv6%20and%20IPv4%20IPF%20firewall%20on%20FreeBSD%204.2.pdf), tried to compile. Now, I know that the Zama pdf instructions are for ipfilter 3.4.16, but that version isn't available anymore. Anyway, the patch fails when I try to apply it.... Has anyone tried this setup yet? I have posted this to the FreeBSD newsgroups, but I figured that I would send it here also since this may be too 'out there' for the newsgroups. Thanks in advance! --------------- |* * * *|~~~~~~~| | * * * |~~~~~~~| Michael Oliver, CCNP oliver.michael@gargantuan.com |* * * *|~~~~~~~| |~~~~~~~~~~~~~~~| http://michael.gargantuan.com/ |~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~| God bless America and all of her patriots. |~~~~~~~~~~~~~~~| --------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------