From owner-v6ops@ops.ietf.org Wed Jan 04 04:05:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu4aH-0006Zm-Mq for v6ops-archive@megatron.ietf.org; Wed, 04 Jan 2006 04:05:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29989 for ; Wed, 4 Jan 2006 04:04:13 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu4V0-000Gc9-0I for v6ops-data@psg.com; Wed, 04 Jan 2006 09:00:02 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu4Uz-000GbJ-9J for v6ops@ops.ietf.org; Wed, 04 Jan 2006 09:00:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: IPv6 Security Overview Date: Wed, 4 Jan 2006 00:59:59 -0800 Message-ID: Thread-Topic: IPv6 Security Overview Thread-Index: AcYRDgSeIIeMJVJMTTWuGK9bZIe2pg== From: "Vishwas Manral" To: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I went through the "IPv6 security overview" draft. It looked good. I had the following minor comments on section 2 of the draft: - 1. Section 2.1.1 - "Routing headers can be used to evade access controls based on destination addresses." One more problem with Routing Header is it can cause packets to loop. Assume a case where we have a loop of addresses in the Routing header, destination A and B. Thus 1 packet sent by a malicious router is amplified. I think a simple check at a firewall could be to see that the routing header does not contain the same address more then once, just as we have a check for the multicast address. 2. Also regarding the point you have made "Routing headers can be used to evade access controls based on destination addresses." I think the access control should look at the Final Destination and not the destination address when a routing header is present. 3. Another thing about routing header is we may not want to process the header (type 0) in the fast path (hardware) and the packet would generally be sent for slow-path processing (software) thus overwhelming the software. 3. Manipulation of "Traffic class" or "Flow Label" field by an intermediate device by changing the values so that a packet can get better service can cause legitimate flows not traversing the intermediate device to be effected(of course if a malicious router is on-path it can affect the traffic). This means that off-path routers can affect traffic. Also because AH does not protect the field it is easy to manipulate (mutable).=20 It would have helped if the flow label field was not mutable(and hence protected by AH) as it is anyway dependent on the source address. 4. Section 2.1.4 - RFC2473 does not specify that we need to check the tunnel source address is legitimate or not. This can cause any ND packet to be sent tunneled from multiple hops away, thus making the "Hop Limit" check not so useful. Below I am attaching a part of the private discussion I had with Pekka and a few others. " > I agree RFC4213 states that, but does it not imply only for=20 > IPv6-in-IPv4 and not for IPv6-in-IPv6. Is there a more general check=20 > for the same I am missing? Correct, RFC2473 which specifies v6-in-v6 tunnels did not specify this (yet) as a requirement. Hosts aren't vulnerable until they have at least one v6-in-v6 tunnel set up though." Using SEND resolves the issue anyway. 5. I went through the draft draft-krishnan-ipv6-hopbyhop-00.txt. I think the attack would be more effective if the router used a multicast address and we knew that some routers on-path support the option while others don't. Instead of sending random options which would be dropped in the first-hop itself and not be amplified. 6. I think when talking about destination options we need to talk about the=20 "Tunnel Encapsulation Limit" option, which is analyzed even along the way when tunneling, is to be done. We do process the Destination Options in the intermediate nodes in some cases. 7. It seems the IPv6 spec is unclear about whether if a Fragment header means the packet is a fragment or if only when the More or fragment offset field is set is the packet a fragment. ESP/ AH RFC's state that a packet is a fragment if the fragment header is present. However the SIIT document states the opposite. 8. Another thing that can be done is basic evasion against firewall. A simple evasion attack is the IPv6 spec could be that some implementations for duplicate fragments assume the fragment received first is kept while some other may assume the one received later is kept. This can cause basic evasion in case a device is passively monitoring for attacks. 9. I agree middleboxes including policy boxes rely on fields inside the header to identify a flow. Even when they are not the end systems.=20 However if a middlebox is acting on behalf of a device it needs to look deeper into the packet. =20 10. One more thing about Padding option is that we should have only one padding option, either 1 instance of PadN or one of Pad1. 11. Having fragments also can cause the packet to go to the slow path (software rather then hardware), which can cause CPU exhaustion attacks. Thanks, Vishwas From owner-v6ops@ops.ietf.org Wed Jan 04 04:55:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu5MQ-0000Wa-Fs for v6ops-archive@megatron.ietf.org; Wed, 04 Jan 2006 04:55:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05792 for ; Wed, 4 Jan 2006 04:53:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu5KE-000JFX-D4 for v6ops-data@psg.com; Wed, 04 Jan 2006 09:52:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu5KD-000JFG-Kx for v6ops@ops.ietf.org; Wed, 04 Jan 2006 09:52:57 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Security Overview Date: Wed, 4 Jan 2006 01:52:57 -0800 Message-ID: Thread-Topic: IPv6 Security Overview Thread-Index: AcYREk7TOOnTcFjSS3STWPPePBMbIwAAPT9Q From: "Vishwas Manral" To: Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Francis, Thanks for the reply. My comments are inline prefixed by a VM>, do let me know where I am wrong. -----Original Message----- From: Francis.Dupont@point6.net [mailto:Francis.Dupont@point6.net]=20 Sent: Wednesday, January 04, 2006 3:06 PM To: Vishwas Manral Cc: v6ops@ops.ietf.org Subject: Re: IPv6 Security Overview=20 In your previous mail you wrote: 1. Section 2.1.1 - "Routing headers can be used to evade access controls based on destination addresses." =20 One more problem with Routing Header is it can cause packets to loop. =3D> either we have not the same definition of a loop or the kind of = loop you talk about is not a security problem. Assume a case where we have a loop of addresses in the Routing header, destination A and B. Thus 1 packet sent by a malicious router is amplified. =3D> how, the packet is the same, only the addresses and the pointer to the next address (and of course the TTL/HL) change. I think a simple check at a firewall could be to see that the routing header does not contain the same address more then once, just as we have a check for the multicast address. =20 =3D> I don't think it matters. VM> I agree the TTL/ Hop Limit changes etc. However by keeping address alternating i.e. Address [2x] =3D A, Address [2x+1] =3D B for x =3D 1 to = n, we make a packet transit the same router n times, thus increasing the load on a router. It is a simple amplification attack. 2. Also regarding the point you have made "Routing headers can be used to evade access controls based on destination addresses." I think the access control should look at the Final Destination and not the destination address when a routing header is present. =20 =3D> it should look at both: this is the issue with headers/options = which introduce multiple source or destination addresses: the simple 2 addresses ACL is not enough and policies can become complex. VM> The best condition would be to be able to filter out based on any field. However based on the current implementation we need to filter on the final destination. The draft seemed to state that we currently do it on the destination address in the IPv6 header. 3. Another thing about routing header is we may not want to process the header (type 0) in the fast path (hardware) and the packet would generally be sent for slow-path processing (software) thus overwhelming the software. =20 =3D> there is no reason to go through the slow path for routing headers. The whole idea of extension headers is to stop the stupid circle: slow path so not used so no interest to support it in hardware... VM> Ok. 3. Manipulation of "Traffic class" or "Flow Label" field by an intermediate device by changing the values so that a packet can get better service can cause legitimate flows not traversing the intermediate device to be effected(of course if a malicious router is on-path it can affect the traffic). This means that off-path routers can affect traffic. Also because AH does not protect the field it is easy to manipulate (mutable).=20 =20 It would have helped if the flow label field was not mutable(and hence protected by AH) as it is anyway dependent on the source address. =20 =3D> as AH is no more used this is an academic discussion. I do not = think so. VM> I agree AH has been downgraded to a MAY in RFC4301. However one point I can think of is that AH is more amenable to middleboxes than ESP authentication only service. I am not sure if we can say AH is no more used, we just had an RFC4302 for the same. I also think that AH should take care that Flow Label, however that is an IPsec(and backward compatibility) discussion. 4. Section 2.1.4 - RFC2473 does not specify that we need to check the tunnel source address is legitimate or not. This can cause any ND packet to be sent tunneled from multiple hops away, thus making the "Hop Limit" check not so useful. =3D> either the tunnel is a link and a ND packet over it is for the = tunnel interface, or it is not a link and a ND packet is out of scope. I can't see a problem associated with ND here even I agree the 4 addresses of a tunneled packet should be checked (cf RFC 3964 for an example). VM> I agree we need to put a check for IPv6 in IPv6 tunnels too, just as we have for others. We however have missed that out. 6. I think when talking about destination options we need to talk about the=20 "Tunnel Encapsulation Limit" option, which is analyzed even along the way when tunneling, is to be done. We do process the Destination Options in the intermediate nodes in some cases. =20 =3D> the TEL is an intermediate destination option, the processing has = to be done in the encapsulator. VM> Agree, that is what I have been stating too. 7. It seems the IPv6 spec is unclear about whether if a Fragment header means the packet is a fragment or if only when the More or fragment offset field is set is the packet a fragment. ESP/ AH RFC's state that a packet is a fragment if the fragment header is present. However the SIIT document states the opposite. =3D> we just lack a definition of what is a fragment... VM> This could be used a simple evasion technique. We have ambiguities in RFC's itself. =20 10. One more thing about Padding option is that we should have only one padding option, either 1 instance of PadN or one of Pad1. =3D> this is not so clear: PadN can be a nice hidden channel. VM> We should not allow multiple Pad1 or PadN options. Is there something I am missing? 11. Having fragments also can cause the packet to go to the slow path (software rather then hardware), which can cause CPU exhaustion attacks. =3D> do you mean we should forbid fragments for any transport which has its own segmentation (i.e., not UDP)? VM> We are talking about security issues. I am just listing that having too many fragments can cause state exhaustion in middleboxes as well as other routers which send fragments to slow path along the way. We are not giving a solution here in my view. Regards Francis.Dupont@point6.net From owner-v6ops@ops.ietf.org Wed Jan 04 05:55:44 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6Ix-0005TD-IB for v6ops-archive@megatron.ietf.org; Wed, 04 Jan 2006 05:55:43 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12554 for ; Wed, 4 Jan 2006 05:54:28 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu6GZ-000MGu-41 for v6ops-data@psg.com; Wed, 04 Jan 2006 10:53:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu6GY-000MGg-9F for v6ops@ops.ietf.org; Wed, 04 Jan 2006 10:53:14 +0000 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 4 Jan 2006 10:53:12 +0000 (GMT) Date: Wed, 4 Jan 2006 10:53:10 +0000 From: David Malone To: Vishwas Manral Cc: Francis.Dupont@point6.net, v6ops@ops.ietf.org Subject: Re: IPv6 Security Overview Message-ID: <20060104105310.GA15684@walton.maths.tcd.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Jan 04, 2006 at 01:52:57AM -0800, Vishwas Manral wrote: > I think a simple check at a firewall could be to see that the > routing header does not contain the same address more then once, just as > we have a check for the multicast address. > > => I don't think it matters. > VM> I agree the TTL/ Hop Limit changes etc. However by keeping address > alternating i.e. Address [2x] = A, Address [2x+1] = B for x = 1 to n, we > make a packet transit the same router n times, thus increasing the load > on a router. It is a simple amplification attack. I think I agree with Francis, that it doesn't really matter. However, it is probably worth noting that your check does not prevent the attack either. If you can find 128 live addresses on either side of the router you can carry out the attack without listing any address twice. (I guess you might want to use a routing header that traverses a single router a few times to get a better estimate of the RTT through that router.) > It would have helped if the flow label field was not mutable(and hence > protected by AH) as it is anyway dependent on the source address. FWIF, RFC 3697 already says the flowlabel should be delivered unchanged to destination nodes. Though, as you point out, having IPsec enforce that is a different matter. David. From owner-v6ops@ops.ietf.org Wed Jan 04 06:02:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6PV-0006wJ-VF for v6ops-archive@megatron.ietf.org; Wed, 04 Jan 2006 06:02:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13158 for ; Wed, 4 Jan 2006 06:01:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu6OE-000Ml6-GU for v6ops-data@psg.com; Wed, 04 Jan 2006 11:01:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu6OD-000Mku-Sq for v6ops@ops.ietf.org; Wed, 04 Jan 2006 11:01:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Security Overview Date: Wed, 4 Jan 2006 03:01:08 -0800 Message-ID: Thread-Topic: IPv6 Security Overview Thread-Index: AcYRHRStrF87b93TR2eojL7nwxT2IAAAREkQ From: "Vishwas Manral" To: "David Malone" Cc: , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi David, > I think I agree with Francis, that it doesn't really matter.=20 > However, it is probably worth noting that your check does not > prevent the attack either. If you can find 128 live addresses=20 > on either side of the router you can carry out the attack=20 > without listing any address twice. > > (I guess you might want to use a routing header that traverses > a single router a few times to get a better estimate of the RTT > through that router.) That is a very interesting point and I did not see it that way. However we should note down the attack in the draft even if we do not know how best to solve it (we are tracking security considerations for IPv6). That said, still the easiest attack this way would be to know two adjacent addresses, that way we can have two adjacent devices sending packets to each other. The one you define is a slightly harder one where we need to know 128 addresses on both sides of the router. A check raises the barrier. Thanks, Vishwas -----Original Message----- From: dwmalone@maths.tcd.ie [mailto:dwmalone@maths.tcd.ie] On Behalf Of David Malone Sent: Wednesday, January 04, 2006 4:23 PM To: Vishwas Manral Cc: Francis.Dupont@point6.net; v6ops@ops.ietf.org Subject: Re: IPv6 Security Overview On Wed, Jan 04, 2006 at 01:52:57AM -0800, Vishwas Manral wrote: > I think a simple check at a firewall could be to see that the > routing header does not contain the same address more then once, just as > we have a check for the multicast address. > =20 > =3D> I don't think it matters. > VM> I agree the TTL/ Hop Limit changes etc. However by keeping address > alternating i.e. Address [2x] =3D A, Address [2x+1] =3D B for x =3D 1 = to n, we > make a packet transit the same router n times, thus increasing the load > on a router. It is a simple amplification attack. I think I agree with Francis, that it doesn't really matter. However, it is probably worth noting that your check does not prevent the attack either. If you can find 128 live addresses on either side of the router you can carry out the attack without listing any address twice. (I guess you might want to use a routing header that traverses a single router a few times to get a better estimate of the RTT through that router.) > It would have helped if the flow label field was not mutable(and hence > protected by AH) as it is anyway dependent on the source address. FWIF, RFC 3697 already says the flowlabel should be delivered unchanged to destination nodes. Though, as you point out, having IPsec enforce that is a different matter. David. From owner-v6ops@ops.ietf.org Wed Jan 04 06:10:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eu6XW-0000dp-DU for v6ops-archive@megatron.ietf.org; Wed, 04 Jan 2006 06:10:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14081 for ; Wed, 4 Jan 2006 06:09:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu6Vh-000NHM-Sp for v6ops-data@psg.com; Wed, 04 Jan 2006 11:08:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eu6Vh-000NH5-4A for v6ops@ops.ietf.org; Wed, 04 Jan 2006 11:08:53 +0000 Received: from [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42] (hell.unfix.org [IPv6:2001:7b8:20d:0:2d0:b7ff:fe8f:5d42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 4BACB7FFB; Wed, 4 Jan 2006 12:08:46 +0100 (CET) Message-ID: <43BBACB3.2080804@unfix.org> Date: Wed, 04 Jan 2006 12:08:35 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vishwas Manral CC: David Malone , Francis.Dupont@point6.net, v6ops@ops.ietf.org Subject: Re: IPv6 Security Overview References: In-Reply-To: X-Enigmail-Version: 0.93.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3C68B2D70C7260A74DDCDA4C" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3C68B2D70C7260A74DDCDA4C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Vishwas Manral wrote: > Hi David, >=20 >> I think I agree with Francis, that it doesn't really matter.=20 >> However, it is probably worth noting that your check does not >> prevent the attack either. If you can find 128 live addresses=20 >> on either side of the router you can carry out the attack=20 >> without listing any address twice. >> >> (I guess you might want to use a routing header that traverses >> a single router a few times to get a better estimate of the RTT >> through that router.) > That is a very interesting point and I did not see it that way. However= > we should note down the attack in the draft even if we do not know how > best to solve it (we are tracking security considerations for IPv6). If you want to 'solve' this attack then *IGNORE* the Routing Header. Or at least sent a ICMP parameter problem back to the sending host. One can always do a traceroute and use the path shown in reverse or a bit mixed to create a nice loop already. Personally I don't see much use for a Routing Header but there are apparently folks who have a use for them other than abuse. Greets, Jeroen --------------enig3C68B2D70C7260A74DDCDA4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFDu6yzKaooUjM+fCMRAu9tAJ0WDxgfpZHhsHNm71ipaK2Ns6KUVgCeIcRm pQfApzXdrpJQkeRoePVa/Ok= =1UFa -----END PGP SIGNATURE----- --------------enig3C68B2D70C7260A74DDCDA4C-- From owner-v6ops@ops.ietf.org Thu Jan 05 04:15:41 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRDb-00009P-7W for v6ops-archive@megatron.ietf.org; Thu, 05 Jan 2006 04:15:36 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15362 for ; Thu, 5 Jan 2006 04:14:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuR9W-000Dg5-E7 for v6ops-data@psg.com; Thu, 05 Jan 2006 09:11:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [202.249.10.124] (helo=shuttle.wide.toshiba.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuR9V-000Dfs-SB for v6ops@ops.ietf.org; Thu, 05 Jan 2006 09:11:22 +0000 Received: from impact.jinmei.org (unknown [3ffe:501:100f:1010:3583:efad:e5f9:3384]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D20A51521A; Thu, 5 Jan 2006 18:11:17 +0900 (JST) Date: Thu, 05 Jan 2006 18:11:16 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: bob@thefinks.com Cc: bob.hinden@nokia.com, v6ops@ops.ietf.org Subject: Re: towards phasing out the 6bone In-Reply-To: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> References: <2a8350a60512252229m36066dd1k968755cb972407ee@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: owner-v6ops@ops.ietf.org Precedence: bulk >>>>> On Sun, 25 Dec 2005 22:29:15 -0800, >>>>> Robert Fink said: > Your point is a valid one. I will start sending regular reminders to > the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. > In spite of that, many nets will ignore these warnings and thus have > to take the consequences when all 3FFE routes are filtered out as of > 6/6/06, and I guess that's just the way it will have to be. Thanks for the prompt action, and sorry for the delay in response. Aside from the discussion of whether to filter the 6bone prefix completely on June 6th and thereafter, I agree that the best thing the IETF can do is to send a reminder message to the current 6bone operators. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp From owner-v6ops@ops.ietf.org Thu Jan 05 04:37:30 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuRYo-0007PB-3L for v6ops-archive@megatron.ietf.org; Thu, 05 Jan 2006 04:37:30 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17813 for ; Thu, 5 Jan 2006 04:36:15 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuRXq-000Ezb-Pq for v6ops-data@psg.com; Thu, 05 Jan 2006 09:36:30 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuRXp-000EvD-PL for v6ops@ops.ietf.org; Thu, 05 Jan 2006 09:36:30 +0000 Received: from [10.0.0.138] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001538700.msg for ; Thu, 05 Jan 2006 10:36:49 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Thu, 05 Jan 2006 10:34:46 +0100 Subject: Re: towards phasing out the 6bone From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: towards phasing out the 6bone Thread-Index: AcYR20PSgoTtf33OEdqfDAANky3PwA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Authenticated-Sender: jordi.palet@consulintel.es X-MDRemoteIP: 10.0.0.138 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Thu, 05 Jan 2006 10:36:53 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jinmei, all, Fully agree. I've been doing this with all the folks that I know still using 6Bone since several months ago. Is important to keep the people wake up on this as much up-front as possible, and if possible provide some examples of others that already did the move. For example, I think WIDE is still using 6bone addresses for a few tunnels, it may be possible to make this being moved to production space and use it as an example for the rest of the operators (WIDE is always a nice example with anything related to IPv6 !). In fact, we even started a program to avoid those people who still don't have a quality IPv6 service from their own upstream providers, in order to avoid them losing the IPv6 service meanwhile. This is under the scope of OCCAID (http://www.occaid.net). I've seen a message sent to another 6Bone PoP participants, which I modify here a bit to make it open to any 6Bone operator: "With the termination of the 6Bone experiment on 6th June 2006, all the 6Bone address space need to be returned to the 6Bone registry on that date. At that time the 6Bone addressing space will become widely filtered (some operators are already filtering it right now). Because of this, we highly recommend to all the 6Bone participants to take early measures instead of waiting till the last minute, in order to avoid getting the service dropped and probably missing some customers. The 6Bone has been a long and highly successful experiment, with the result that many ISPs are now offering their own commercial IPv6 connection services. You are receiving three months notice of this discontinuation of the 6Bone facility as a reminder in the hope that this is sufficient time for you to make alternative arrangements for your continued IPv6 connection requirements. Our first suggestion is that you ask for the service to your existing upstream providers, most of them are already providing the service, or just waiting for customers like you demanding for it in order to start the service. If this doesn't work and you can't look for alternative service providers, there are several alternative choices. One of them is public utility non-for-profit projects, such as OCCAID (http://www.occaid.org), which may be able to provide transit in a temporary basis until you can get it from your commercial upstream providers. If you are interested in taking up this offer, please send an e-mail to 6bone-transfer@occaid.org." Regards, Jordi > De: JINMEI Tatuya / =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 > Organizaci=C3=B3n: Research & Development Center, Toshiba Corp., Kawasaki, Japan. > Responder a: > Fecha: Thu, 05 Jan 2006 18:11:16 +0900 > Para: > CC: , "v6ops@ops.ietf.org" > Asunto: Re: towards phasing out the 6bone >=20 >>>>>> On Sun, 25 Dec 2005 22:29:15 -0800, >>>>>> Robert Fink said: >=20 >> Your point is a valid one. I will start sending regular reminders to >> the 6bone mail list on 1 Jan 06 and repeat them regularly till 6/6/06. >=20 >> In spite of that, many nets will ignore these warnings and thus have >> to take the consequences when all 3FFE routes are filtered out as of >> 6/6/06, and I guess that's just the way it will have to be. >=20 > Thanks for the prompt action, and sorry for the delay in response. >=20 > Aside from the discussion of whether to filter the 6bone prefix > completely on June 6th and thereafter, I agree that the best thing the > IETF can do is to send a reminder message to the current 6bone > operators. >=20 > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp >=20 ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Fri Jan 06 00:24:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Euk56-0006OJ-3D for v6ops-archive@megatron.ietf.org; Fri, 06 Jan 2006 00:24:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04507 for ; Fri, 6 Jan 2006 00:22:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Euk0x-000LW4-SW for v6ops-data@psg.com; Fri, 06 Jan 2006 05:19:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Euk0x-000LVs-6Q for v6ops@ops.ietf.org; Fri, 06 Jan 2006 05:19:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: IPv6 Security Overview Date: Thu, 5 Jan 2006 21:19:45 -0800 Message-ID: Thread-Topic: IPv6 Security Overview Thread-Index: AcYSR+rzIlzPBzDCQAaIUlJTMFG+6gAOLxZg From: "Vishwas Manral" To: Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Francis, =3D> I am sorry to have to say that but I don't believe we should change protocols to make the life of middleboxes better, i.e., middleboxes have to adapt, not the opposite. And here I say middleboxes because fragments are transparent for routers (i.e., a lot of fragments or a lot of packets are the same thing for a router). Routers also do basic load balancing (ECMP) based on deeper packet inspection, this is where things can be affected (ACL's etc). I agree to what you say above. However I think we are doing a security analysis of the protocol and hence noting down the possible places where we can have issues. The draft also talks about issues with overusing "Router Alert option" or having excessive "hop-by-hop" options; it does not however mean we are removing the options totally or putting a limit on it (Seemed to me that way from the spirit of the draft, the authors could probably clarify). Thanks, Vishwas -----Original Message----- From: Francis.Dupont@point6.net [mailto:Francis.Dupont@point6.net]=20 Sent: Friday, January 06, 2006 4:02 AM To: Vishwas Manral Cc: v6ops@ops.ietf.org Subject: Re: IPv6 Security Overview=20 In your previous mail you wrote: =20 =3D> I don't think it matters. VM> I agree the TTL/ Hop Limit changes etc. However by keeping address alternating i.e. Address [2x] =3D A, Address [2x+1] =3D B for x =3D 1 = to n, we make a packet transit the same router n times, thus increasing the load on a router. It is a simple amplification attack. =20 =3D> it is a low order attack against an intermediate slow link when the real issue is bad security policies (bad =3D not prepared to see packets following strange routes). =3D> as AH is no more used this is an academic discussion. I do not think so. VM> I agree AH has been downgraded to a MAY in RFC4301. However one point I can think of is that AH is more amenable to middleboxes than ESP authentication only service. I am not sure if we can say AH is no more =3D> just ask IPsec people. used, we just had an RFC4302 for the same. I also think that AH should take care that Flow Label, however that is an IPsec(and backward compatibility) discussion. =20 =3D> it was an IPsec discussion and backward compatibility won. 10. One more thing about Padding option is that we should have only one padding option, either 1 instance of PadN or one of Pad1. =3D> this is not so clear: PadN can be a nice hidden channel. VM> We should not allow multiple Pad1 or PadN options. Is there something I am missing? =20 =3D> yes, people want to be free to use Pad1 and PadN as they believe it is the best. BTW adding a constraint here shall kill compatibility. =3D> do you mean we should forbid fragments for any transport which = has its own segmentation (i.e., not UDP)? VM> We are talking about security issues. I am just listing that having too many fragments can cause state exhaustion in middleboxes as well as other routers which send fragments to slow path along the way. We are not giving a solution here in my view. =20 =3D> I am sorry to have to say that but I don't believe we should change protocols to make the life of middleboxes better, i.e., middleboxes have to adapt, not the opposite. And here I say middleboxes because fragments are transparent for routers (i.e., a lot of fragments or a lot of packets are the same thing for a router). Regards =20 Francis.Dupont@point6.net From avgeo@delphi.com Sun Jan 08 07:49:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EvZzg-0000cZ-G6 for v6ops-archive@megatron.ietf.org; Sun, 08 Jan 2006 07:49:56 -0500 Received: from cable64-39.anadolu.kablonet.com.tr (cable64-39.anadolu.kablonet.com.tr [195.174.64.39] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22076 for ; Sun, 8 Jan 2006 07:48:27 -0500 (EST) Date: Sun, 08 Jan 2006 03:52:45 -0500 From: Susanna Pack X-Mailer: inducible 6.91.97697 Reply-To: Candace Jones X-Priority: 3 (Normal) Message-ID: <9288687528269196355974@delphi.com> To: v6ops-archive@ietf.org Subject: Amazing, Bette In-Reply-To: <5444640818467848178465@delphi.com> References: <356202244570659829149726@delphi.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------=51272484889" Content-Transfer-Encoding: 7bit --------=51272484889 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Designs in connection with postage stamps and coinage may be described, I think, as the silent ambassadors on national taste.Freedom from effort in the present merely means that there has been effort stored up in the past.
To refuse graciously is to confer a favor. --------=51272484889 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Wilbur-> http://uwmfsu.tlozs.info/?wtvqggxwpqqyjjgjnqzpohdqdnj --------=51272484889-- From owner-v6ops@ops.ietf.org Mon Jan 09 20:37:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ew8SU-0001HX-Og for v6ops-archive@megatron.ietf.org; Mon, 09 Jan 2006 20:37:58 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17708 for ; Mon, 9 Jan 2006 20:36:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ew8OL-000NOx-9f for v6ops-data@psg.com; Tue, 10 Jan 2006 01:33:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [202.112.3.67] (helo=cernet.edu.cn) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ew8OI-000NOi-Kt for v6ops@ops.ietf.org; Tue, 10 Jan 2006 01:33:40 +0000 Received: from ZhangMiao([166.111.203.206]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm543c37740; Tue, 10 Jan 2006 09:55:55 +0800 Date: Tue, 10 Jan 2006 09:33:24 +0800 From: "Zhang Miao" Reply-To: zm@cernet.edu.cn To: "v6ops" Subject: Request for comments Organization: Tsinghua University X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====001_Dragon115312350104_=====" X-AIMC-AUTH: zm X-AIMC-MAILFROM: zm@cernet.edu.cn Message-ID: X-AIMC-Msg-ID: HMrjIwOB Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --=====001_Dragon115312350104_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, I write two documents to describe some idea on IPv6 transition. The first document, draft-zhang-ipv6-universal-00.txt describes an architecture for promoting the transition to IPv6. The other document, draft-zhang-transition-multihoming-00.txt describes an algorithm that can be used in this architecture. These ideas are very preliminary. Since I didn't follow the history of the evolvement of the IPv6, I am afraid that I ignore some stories that related to the documents I wrote. I need your help very much. Thanks a lot! Miao ***************************************************************** * Zhang Miao * * Ph.D, Assistant Professor, Network Research Center * * Tsinghua University,Beijing,China(100084) * * Tel: (8610)-62795818-6271 * * Email: zm at cernet.edu.cn * * Web: http://netarchlab.tsinghua.edu.cn/~zm * ***************************************************************** --=====001_Dragon115312350104_===== Content-Type: application/octet-stream; name="draft-zhang-ipv6-universal-00.txt" Content-Disposition: attachment; filename="draft-zhang-ipv6-universal-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE0uIFpoYW5nDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gV3UNCkV4cGlyZXM6IEp1bHkgMTQs IDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVHNpbmdodWEgVW5pdmVyc2l0eQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBK YW51YXJ5IDEwLCAyMDA2DQoNCg0KICAgICAgICAgICAgICBUaGUgVW5pdmVyNiBBcmNoaXRlY3R1 cmUgZm9yIElQdjYgVHJhbnNpdGlvbg0KICAgICAgICAgICAgICAgICAgICAgZHJhZnQtemhhbmct aXB2Ni11bml2ZXJzYWwtMDANCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBCeSBzdWJtaXR0 aW5nIHRoaXMgSW50ZXJuZXQtRHJhZnQsIGVhY2ggYXV0aG9yIHJlcHJlc2VudHMgdGhhdCBhbnkN CiAgIGFwcGxpY2FibGUgcGF0ZW50IG9yIG90aGVyIElQUiBjbGFpbXMgb2Ygd2hpY2ggaGUgb3Ig c2hlIGlzIGF3YXJlDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkg b2Ygd2hpY2ggaGUgb3Igc2hlIGJlY29tZXMNCiAgIGF3YXJlIHdpbGwgYmUgZGlzY2xvc2VkLCBp biBhY2NvcmRhbmNlIHdpdGggU2VjdGlvbiA2IG9mIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJh ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAg IFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIGFuZCBpdHMgd29ya2luZyBncm91cHMuICBO b3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9j dW1lbnRzIGFzIEludGVybmV0LQ0KICAgRHJhZnRzLg0KDQogICBJbnRlcm5ldC1EcmFmdHMgYXJl IGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMNCiAgIGFu ZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVu dHMgYXQgYW55DQogICB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQt RHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRo YW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVy bmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0 Zi8xaWQtYWJzdHJhY3RzLnR4dC4NCg0KICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hh ZG93IERpcmVjdG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y Zy9zaGFkb3cuaHRtbC4NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBK dWx5IDE0LCAyMDA2Lg0KDQpDb3B5cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoQykgVGhl IEludGVybmV0IFNvY2lldHkgKDIwMDYpLg0KDQpBYnN0cmFjdA0KDQogICBNYWlubHkgZHVlIHRv IHRoZSBzY2FyY2Ugb2YgSVB2NCBhZGRyZXNzLCBpdCBpcyBhIHBvc3NpYmxlIHRyZW5kIHRoYXQN CiAgIElQdjYgd2lsbCB0YWtlIHRoZSBwbGFjZSBvZiBJUHY0IGluIHRoZSBmdXR1cmUuICBIb3dl dmVyLCBkdWUgdG8gdGhlDQogICBsYXJnZSBhbW91bnQgb2YgSVB2NCBsZWdhY3ksIGl0IGlzIGhh cmQgdG8gdHJhbnNpdCB0byBJUHY2IG92ZXIgb25lDQogICBuaWdodC4gIEl0IGlzIHByZWZlcmVk IHRvIHRyYW5zaXRpbmcgdG8gSVB2NiB3aXRoIGxvdyBjb3N0LCB3aGlsZQ0KICAgcHJvdGVjdGlu ZyB0aGUgbGVnYWN5IG9mIElQdjQuICBJbiB0aGlzIGRvY3VtZW50LCB3ZSBwcm9wb3NlIGEgdGhy ZWUtDQogICBsYXllciBhcmNoaXRlY3R1cmUgLSBVbml2ZXI2LCBpbiB3aGljaCBJUHY2IHdpbGwg YmUgYSB1bml2ZXJzYWwNCiAgIG92ZXJsYXkgbmV0d29yaywgb24gdG9wIG9mIGJvdGggSVB2NCBh bmQgSVB2NiBuZXR3b3Jrcy4gIEJvdGggSVB2NA0KICAgYXBwbGljYXRpb24gYW5kIElQdjYgYXBw bGljYXRpb24gY2FuIGJlIHN1cHBvcnRlZCBvdmVyIHRoZSBJUHY2DQoNCg0KDQpaaGFuZyAmIFd1 ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1Bh Z2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFRoZSBVbml2ZXI2IEFyY2hpdGVjdHVy ZSAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIG92ZXJsYXkuDQoNCg0KVGFibGUgb2Yg Q29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgUmVxdWlyZW1lbnQgZm9yIHRoZSBh cmNoaXRlY3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDQNCiAgIDMuICBUaGUg VW5pdmVyNiBhcmNoaXRlY3R1cmUgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAgNg0KICAgICAzLjEuICBEZXNjcmlwdGlvbiBvZiB0aGUgYXJjaGl0ZWN0dXJlICAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDMuMi4gIFRoZSBhbmFseXNpcyBvZiB0aGUgaW5j ZW50aXZlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgIDQuICBUaGUgY2hhbGxl bmdlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOQ0K ICAgICA0LjEuICBJUHY2IGFjY2VzcyBmb3IgaG9zdHMgaW4gSVB2NCBuYXRpdmUgbmV0d29yayAu IC4gLiAuIC4gLiAuICA5DQogICAgIDQuMi4gIFN1cHBvcnQgSVB2NCBhcHBsaWNhdGlvbiBvdmVy IElQdjYgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDUuICBSZWZlcmVuY2VzIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMA0KICAgQXV0 aG9ycycgQWRkcmVzc2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDExDQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1l bnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpaaGFuZyAmIFd1ICAgICAg ICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgMl0N CgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFRoZSBVbml2ZXI2IEFyY2hpdGVjdHVyZSAgICAg ICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0KICAgVGhpcyBtZW1v IGlzIGludGVuZGVkIHRvIGRlc2NpcmJlIGEgcG9zc2libGUgZGlyZWN0aW9uIGZvciBJUHY2DQog ICB0cmFuc2l0aW9uLiAgVGhvdWdoIG1hbnkgcGVvcGxlIGhhdmUgYWdyZWVkIHRoYXQgSVB2NiB3 aWxsIHRha2UgdGhlDQogICBwbGFjZSBvZiBJUHY0IGluIHRoZSBmdXR1cmUsIGhvdyB0byBtYWtl IHN1Y2Nlc3NmdWwgdHJhbnNpdGlvbiB3aXRoDQogICBsb3cgY29zdCBpcyBzdGlsbCBhIHByb2Js ZW0uICBJbiB0aGUgSVB2NiB0cmFuc2l0aW9uIHByb2Nlc3MsIHdlIGp1c3QNCiAgIG5vdGljZSB0 d28gcHJvYmxlbXMuICBPbmUgcHJvYmxlbSBpcyB0aGUgbGFyZ2UgYW1vdW50IG9mIElQdjQgbGVn YWN5Lg0KICAgSXQgaXMgaGFyZCB0byBjaGFuZ2UgYWxsIElQdjQgcm91dGVycyB0byBJUHY2L2R1 YWwtc3RhY2sgcm91dGVycywgb3INCiAgIGNoYW5nZSBhbGwgSVB2NCBuZXR3b3JrcyB0byBJUHY2 IG5ldHdvcmtzIG92ZXIgb25lIG5pZ2h0LiAgVGhlDQogICBleGlzdGluZyBpbnZlc3RtZW50IG9u IElQdjQgc2hvdWxkIGJlIHByb3RlY3RlZCB3aGVuIGRlcGxveWluZyBJUHY2Lg0KICAgQW5vdGhl ciBwcm9ibGVtIGlzIHRoZSBwb3NzaWJsZSBzY2VuYXJpbyB0byBoYXZlIHR3byBzZXBlcmF0ZWQg bGFyZ2UNCiAgIG5ldHdvcmsgLSBuYXRpdmUgSVB2NCBuZXR3b3JrLCBhbmQgbmF0aXZlIElQdjYg bmV0d29yay4gIEl0IGlzDQogICBpbXBvcnRhbnQgdG8ga2VlcCB0aGUgSW50ZXJuZXQgYSB1bml2 ZXJzYWwgbmV0d29yayBkdXJpbmcgdGhlDQogICB0cmFuc2l0aW9uIHByb2Nlc3MsIGkuZS4sIHR3 byBlbmQgaG9zdHMgY2FuIHJlYWNoIGVhY2ggb3RoZXIgZW5kLXRvLQ0KICAgZW5kLg0KDQogICBX aXRoIHRoZSBhYm92ZSBjb25zaWRlcmF0aW9uLCB3ZSBwcm9wb3NlIGFuIGFyY2hpdGVjdHVyZSAt IFVuaXZlcjYsDQogICBmb3IgSVB2NiB0cmFuc2l0aW9uLiAgT2YgY291cnNlLCBvbmUgbW90aXZh dGlvbiBvZiBkZXNpZ25pbmcgdGhpcw0KICAgYXJjaGl0ZWN0dXJlIGlzIHRvIHByb21vdGUgdGhl IHRyYW5zaXRpb24gdG8gSVB2Ni4gIEFsc28sIHdlIHRyeSB0bw0KICAgc29sdmUgdGhlIHByb2Js ZW1zIG1lbnRpb25lZCBhYm92ZSB3aXRoIHRoZSBwcm9wb3NlZCBhcmNoaXRlY3R1cmUuDQogICBU aGUgYXJjaGl0ZWN0dXJlIGhhcyB0aHJlZSBsYXllcnMuICBJUHY2IGlzIGEgdW5pdmVyc2FsIG92 ZXJsYXkNCiAgIG5ldHdvcmssIG9uIHRvcCBvZiBib3RoIElQdjQgYW5kIElQdjYgbmV0d29ya3Mu ICBCb3RoIElQdjQNCiAgIGFwcGxpY2F0aW9uIGFuZCBJUHY2IGFwcGxpY2F0aW9uIGNhbiBiZSBz dXBwb3J0ZWQgb3ZlciB0aGUgSVB2Ng0KICAgb3ZlcmxheS4NCg0KICAgSXQgc2hvdWxkIGJlIG5v dGljZWQgdGhhdCwgbm90IGFsbCB0aGUgdGVjaG5vbG9naWVzIHJlcXVpcmVkIGJ5IHRoZQ0KICAg VW5pdmVyNiBhcmNoaXRlY3R1cmUgYXJlIGF2YWlsYWJsZSBub3cuICBXZSBhbHNvIGRlc2NyaWJl IHdoYXQNCiAgIHRlY2hub2xvZ3kgc2hvdWxkIGJlIGRlc2lnbmVkIHRvIHN1cHBvcnQgdGhlIGFy Y2hpdGVjdHVyZS4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQpaaGFuZyAmIFd1ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAg ICAgICAgICAgW1BhZ2UgM10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFRoZSBVbml2ZXI2 IEFyY2hpdGVjdHVyZSAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCjIuICBSZXF1aXJlbWVu dCBmb3IgdGhlIGFyY2hpdGVjdHVyZQ0KDQogICBXaXRoIHRoZSBkZXBsb3ltZW50IG9mIElQdjYs IHRoZXJlIHdpbGwgYmUgdHdvIHNlcGVyYXRlZCBsYXJnZQ0KICAgbmV0d29ya3M6DQoNCiAgIG8g IE5hdGl2ZSBJUHY0IG5ldHdvcmsuICBJdCBpcyB0aGUgbGVnYWN5IG9mIHRoZSBjdXJyZW50IElu dGVybmV0Lg0KICAgICAgVGhlIHJvdXRlcnMgY2FuIG9ubHkgZm9yd2FyZCBJUHY0IHBhY2tldHMs IHdoaWxlIHRoZSBob3N0cyBtYXkgYmUNCiAgICAgIGR1YWwtc3RhY2sgYnkgdXBkYXRpbmcgdGhl IHNvZnR3YXJlLg0KDQogICBvICBOYXRpdmUgSVB2NiBuZXR3b3JrLiAgVGhlcmUgbWF5IGJlIG5v IElQdjQgYWRkcmVzcyBibG9jayBhdmFpbGFibGUNCiAgICAgIHdoZW4gc2V0dGluZyB1cCBuZXcg bmV0d29yay4gIFRoZSByb3V0ZXJzIGNhbiBvbmx5IGZvcndhcmQgSVB2Ng0KICAgICAgcGFja2V0 cy4gIFRoZSBob3N0cyBhcmUgdXNpbmcgZHVhbC1zdGFjaywgb3Igb25seSBzdXBwb3J0aW5nIElQ djYuDQogICAgICBFdmVuIGlmIHRoZSByb3V0ZXJzIGFyZSBkdWFsLXN0YWNrLCB0aGVyZSBpcyBu byBnbG9iYWwgSVB2NA0KICAgICAgYWRkcmVzcyBhbGxvY2F0ZWQgZm9yIHRoZSBuZXR3b3JrLg0K DQogICBUaGVyZSBhcmUgYWxzbyBzb21lIGR1YWwtc3RhY2sgbmV0d29ya3MuICBCb3RoIHJvdXRl cnMgYW5kIGhvc3RzIGhhdmUNCiAgIGR1YWwtc3RhY2sgc3VwcG9ydCwgYW5kIGJvdGggZ2xvYmFs IElQdjYgYW5kIElQdjQgYWRkcmVzcyBhcmUNCiAgIGFsbG9jYXRlZCBmb3IgdGhlIG5ldHdvcmsu ICBTdWNoIG5ldHdvcmsgY2FuIGJlIHZpZXdlZCBhcyB0aGUNCiAgIG92ZXJsYXBwZWQgcGFydCBv ZiBuYXRpdmUgSVB2NCBuZXR3b3JrIGFuZCBuYXRpdmUgSVB2NiBuZXR3b3JrLg0KDQogICAgICAg ICAgICAsLS0tLS0tLS0tLS4NCiAgICAgICAgICAgLCcgICBJUHY0ICAgICBgDQogICAgICAgICAg LyAgICBOYXRpdmUgICAgIFwNCiAgICAgICAgIC8gICAgIE5ldHdvcmsgICAgIFwNCiAgICAgICAg OyAgICAgICAgICAgICAgICAgIDoNCiAgICAgICAgfCAgICwtLS0tLS0tLS0tLiAgIHwNCiAgICAg ICAgOiAgLCcgICAgICAgICAgIGAgIDsNCiAgICAgICAgIFwvICBEdWFsLVN0YWNrICBcLw0KICAg ICAgICAgL1wgICAgTmV0d29yayAgIC9cDQogICAgICAgIDsgIGAuICAgICAgICAgICwnICA6DQog ICAgICAgIHwgICAgJy0tLS0tLS0tLSAgICB8DQogICAgICAgIDogICAgICAgICAgICAgICAgICA7 DQogICAgICAgICBcICAgICAgSVB2NiAgICAgICAvDQogICAgICAgICAgXCAgICBOYXRpdmUgICAg IC8NCiAgICAgICAgICAgYC4gIE5ldHdvcmsgICwnDQogICAgICAgICAgICAgJy0tLS0tLS0tLQ0K DQogICBJbiB0aGUgY29leGlzdGluZyBvZiBib3RoIElQdjQgYW5kIElQdjYgbmF0aXZlIG5ldHdv cmtzLCB0byBwcm9tb3RlDQogICB0aGUgZGVwbG95bWVudCBvZiBJUHY2LCBzb21lIGltcG9ydGFu dCByZXF1aXJlbWVudHMgc2hvdWxkIGJlDQogICBhZGRyZXNzZWQ6DQoNCiAgIDEuICBQcm90ZWN0 IHRoZSBsZWdhY3kgaW52ZXN0bm1lbnQgb24gSVB2NCBuYXRpdmUgbmV0d29yay4gIFRoZQ0KICAg ICAgIHJvdXRlcnMgYW5kIHN3aXRjaGVzIHRoYXQgY2FuIG9ubHkgc3VwcG9ydCBJUHY0IHdpbGwg bm90IGJlIHRha2VuDQogICAgICAgcGxhY2UgYnkgSVB2Ni1lbmFibGVkIG5ldHdvcmsgZGV2aWNl cywgZHVlIHRvIGhpZ2ggY29zdCBvZiBuZXcNCiAgICAgICBkZXZpY2VzIGFuZCB0aGUgZXN0aW1h dGlvbiBvZiBubyBleHRyYSBpbmNvbWUgZnJvbSBJUHY2IGluIHRoZQ0KICAgICAgIG5lYXIgZnV0 dXJlLiAgRW5kIHVzZXJzIHNob3VsZCBoYXZlIHRoZSBhYmlsaXR5IHRvIGFjY2VzcyBJUHY2DQog ICAgICAgZXZlbiB3aXRoIG5vIGNoYW5nZXMgdG8gdGhlIElQdjQgcm91dGVycyBhbmQgc3dpdGNo ZXMuDQoNCg0KDQoNClpoYW5nICYgV3UgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE0LCAy MDA2ICAgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAg VGhlIFVuaXZlcjYgQXJjaGl0ZWN0dXJlICAgICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KICAg Mi4gIFByb3ZpZGUgYSB3YXkgZm9yIHVuaXZlcnNhbCBhY2Nlc3MuICBJUHY0IGFuZCBJUHY2IGFy ZSB0d28NCiAgICAgICBkaWZmZXJlbnQgImxhbmd1YWdlIiB0aGF0IGNhbiBub3QgZGlyZWN0bHkg dGFsayB0byBlYWNoIG90aGVyLg0KICAgICAgIFRoZXJlIGhhcyBiZWVuIGEgbGFyZ2UgYW1vdW50 IG9mIHVzZXJzIGluIHRoZSBJUHY0IG5hdGl2ZQ0KICAgICAgIG5ldHdvcmsuICBXaXRoIHRoZSB1 c2luZyB1cCBvZiBJUHY0IGFkZHJlc3MsIGl0IGlzIGV4cGVjdGVkIHRoYXQNCiAgICAgICB0aGVy ZSB3aWxsIGFsc28gYmUgYSBsYXJnZSBhbW91bnQgb2YgdXNlcnMgaW4gdGhlIElQdjYgbmF0aXZl DQogICAgICAgbmV0d29yay4gIFRoZSB1c2VycyBpbiAiSVB2NCBjb250aW5lbnQiIGFuZCBpbiAi SVB2NiBjb250aW5lbnQiDQogICAgICAgc2hvdWxkIGhhdmUgdGhlIGFiaWxpdHkgdG8gYWNjZXNz IGVhY2ggb3RoZXIgaW4gYW4gZW5kLXRvLWVuZA0KICAgICAgIHdheS4NCg0KICAgMy4gIFByb3Zp ZGUgc3VwcG9ydCBmb3IgbGVnYWN5IElQdjQgYXBwbGljYXRpb25zLiAgRXZlbiBzb21lIElQdjQN CiAgICAgICBhcHBsaWNhdGlvbnMgY2FuIGJlIG1vZGlmaWVkIHRvIHN1cHBvcnQgSVB2Niwgc29t ZSB3aWxsIG5ldmVyIGJlDQogICAgICAgbW9kaWZpZWQgdG8gaGF2ZSBJUHY2IHN1cHBvcnQuICBU aGVyZSBzaG91bGQgaGF2ZSBzdXBwb3J0IGZvcg0KICAgICAgIHN1Y2ggSVB2NCBhcHBsaWNhdGlv biB0byBydW4gb3ZlciBJUHY2IG9ubHkgbmV0d29yay4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpaaGFu ZyAmIFd1ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAg ICAgW1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFRoZSBVbml2ZXI2IEFyY2hp dGVjdHVyZSAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCjMuICBUaGUgVW5pdmVyNiBhcmNo aXRlY3R1cmUNCg0KMy4xLiAgRGVzY3JpcHRpb24gb2YgdGhlIGFyY2hpdGVjdHVyZQ0KDQogICBI ZXJlIHdlIGRlc2NyaWJlIGFuIGFyY2hpdGVjdHVyZSB0byBtZWV0IHRoZSByZXF1aXJlbWVudHMg YW5hbHl6ZWQNCiAgIGFib3ZlLiAgVGhlIFVuaXZlcjYgYXJjaGl0ZWN0dXJlIGlzIGNvbXBvc2Vk IG9mIHRocmVlLWxheWVycy4gIEluIHRoZQ0KICAgIkluZnJhc3RydWN0dXJlIExheWVyIiwgdGhl cmUgbWF5IGJlIElQdjQgbmF0aXZlIG5ldHdvcmsgb3IgSVB2Ng0KICAgbmF0aXZlIG5ldHdvcmsu ICBPdmVyIHRoZSBJbmZyYXN0cnVjdHVyZSBMYXllciwgYSAiUHJvdG9jb2wgTGF5ZXIiDQogICBj YW4gcHJvdmlkZSB1bml2ZXJhbCBhY2Nlc3MgdG8gSVB2NiBmb3IgYWxsIHRoZSB1c2VycyBlaXRo ZXIgaW4gdGhlDQogICBJUHY0IG5hdGl2ZSBuZXR3b3JrIG9yIGluIHRoZSBJUHY2IG5hdGl2ZSBu ZXR3b3JrLiAgVGhlIFByb3RvY29sDQogICBMYXllciBzaG91bGQgc3VwcG9ydCBib3RoIElQdjQg YXBwbGljYXRpb24gYW5kIElQdjYgYXBwbGljYXRpb24gaW4NCiAgIHRoZSBBcHBsaWNhdGlvbiBM YXllciBvdmVyIHRoZSBJUHY2IHByb3RvY29sLg0KDQogICBXaXRoICJJbmZyYXN0cnVjdHVyZSBM YXllciIsIGl0IGlzIGRlbm90ZWQgdGhlIHBoeXNpY2FsIG5ldHdvcmssDQogICBjb21wb3NlZCBv ZiByZWFsIHJvdXRlcnMgYW5kIHN3aXRjaGVzLiAgV2l0aCAiUHJvdG9jb2wgTGF5ZXIiLCBpdCBp cw0KICAgZGVub3RlZCB0aGUgbG9naWNhbCBuZXR3b3JrLCB3aGljaCBjYW4gZGVsaXZlciBJUHY2 IHBhY2tldHMsIHdoYXRldmVyDQogICB0aGUgdW5kZXJsYXkgc2l0dWF0aW9uLg0KDQogICArLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCiAgIHwgICAgSVB2NCAgICB8ICAgIElQdjYgICAgfCAg ICBBcHBsaWNhdGlvbiBMYXllcg0KICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0rDQogICB8 ICAgICAgICAgIElQdjYgICAgICAgICAgIHwgICAgUHJvdG9jb2wgTGF5ZXINCiAgICstLS0tLS0t LS0tLS0rLS0tLS0tLS0tLS0tKw0KICAgfCAgICBJUHY0ICAgIHwgICAgSVB2NiAgICB8ICAgIElu ZnJhc3RydWN0dXJlIExheWVyDQogICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLSsNCg0KICAg QWJvdmUgaXMgYSBsYXllciB2aWV3IG9mIHRoZSBhcmNoaXRlY3R1cmUuICBOZXh0IHdlIGRlc2Ny aWJlIGEgdmlldw0KICAgZnJvbSB0aGUgdG9wb2xvZ3kuICBJUHY0IG5hdGl2ZSBuZXR3b3JrIGFu ZCBJUHY2IG5hdGl2ZSBuZXR3b3JrIGFyZQ0KICAgc2VwZXJhdGVkLiAgVGhlIGhvc3RzIGluIElQ djQgbmF0aXZlIG5ldHdvcmsgY2FuIGJlIG1hZGUgdG8gc3VwcG9ydA0KICAgSVB2NiBieSB1cGRh dGluZyB0aGUgc29mdHdhcmUuICBUaGVyZSBhcmUgYWxzbyBzb21lIElQdjYgaXNsYW5kIGF0DQog ICB0aGUgZWRnZSBvZiB0aGUgSVB2NCBuYXRpdmUgbmV0d29yay4gIFRoZXNlIGhvc3RzIGFuZCBJ UHY2IGlzbGFuZHMNCiAgIGdldCB0aGVpciBnbG9iYWwgSVB2NiBhZGRyZXNzIGFuZCBhY2Nlc3Mg dG8gdGhlIElQdjYgbmF0aXZlIG5ldHdvcmsNCiAgIGZyb20gdGhlIElQdjYgQWNjZXNzIFBvaW50 Lg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KWmhhbmcgJiBXdSAgICAgICAg ICAgICAgICBFeHBpcmVzIEp1bHkgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDZdDQoM DQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICBUaGUgVW5pdmVyNiBBcmNoaXRlY3R1cmUgICAgICAg ICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICAgICAgKy0tLS0tLS0tLSsNCiAgICAgICB8SVB2NiBI b3N0fC0tLS0tLiAgLS0tLg0KICAgICAgICstLS0tLS0tLS0rICAgICAgLyAgICAgIFwNCiAgICAg ICAgICAvICAgICAgICAgICAgOyBJUHY2ICAgfA0KICAgICAgICAgLyAgICAgICAgICAgICB8IElz bGFuZCAvDQogICAgICAgIDsgICAgICAgSVB2NCAgICBgLCAgICA7DQogICAgICAgIHwgICAgICBO YXRpdmUgICAgICAtLQ0KICAgICAgICA6ICAgICAgTmV0d29yayAgICAgOw0KICAgICAgICAgXCAg ICstLS0tLS0tLS0rICAvDQogICAgICAgICAgLS0tfCBJUHY2IEFQIHwtLQ0KICAgICAgICAgLyAg ICstLS0tLS0tLS0rICBcDQogICAgICAgIDsgICAgICAgICAgICAgICAgICA6DQogICAgICAgIHwg ICAgICAgICAgICAgICAgICB8DQogICAgICAgIDogICAgICAgICAgICAgICAgICA7DQogICAgICAg ICBcICAgICAgSVB2NiAgICAgICAvDQogICAgICAgICAgXCAgICBOYXRpdmUgICAgIC8NCiAgICAg ICAgICAgYC4gIE5ldHdvcmsgICwnDQogICAgICAgICAgICAgJy0tLS0tLS0tLQ0KDQogICBUaGUg aWRlYSBvZiBoYXZpbmcgaG9zdHMgaW4gSVB2NCBuYXRpdmUgbmV0d29yayB0byBhY2Nlc3MgSVB2 NiBpcyBub3QNCiAgIG5ldy4gIEl0IGhhcyBiZWVuIHByb3Bvc2VkIGluIDZ0bzRbMV0sIFR1bm5l bCBCcm9rZXJbMl0gZXRjLiAgVGhlDQogICBmb2N1cyBvZiB0aGlzIG1lbW8gaXMgdG8gdGhpbmsg SVB2NCBuYXRpdmUgbmV0d29yayBhbmQgSVB2NiBuYXRpdmUNCiAgIG5ldHdvcmsgdG9nZXRoZXIg YW5kIHRvIG1ha2UgSVB2NiB0aGUgdW5pdmVyc2FsIG5ldHdvcmsgcHJvdG9jb2wNCiAgIGR1cmlu ZyB0aGUgdHJhbnNpdGlvbiB0byBJUHY2Lg0KDQozLjIuICBUaGUgYW5hbHlzaXMgb2YgdGhlIGlu Y2VudGl2ZQ0KDQogICBJbiB0aGlzIHNlY3Rpb24sIHdlIGFuYWx5emUgdGhlIGluY2VudGl2ZSBm cm9tIGRpZmZlcmVudCBhc3BlY3RzLCBhbmQNCiAgIHRyeSB0byBleHBsYWluIHdoeSBpdCBpcyBw b3NzaWJsZSB0byBhY2hpZXZlIHRoZSB0cmFuc2l0aW9uIHRvIElQdjYNCiAgIHdpdGggVW5pdmVy NiBhcmNoaXRlY3R1cmUuDQoNCiAgIEZyb20gdGhlIHBvaW50IG9mIGVuZCB1c2VycyBpbiB0aGUg SVB2NiBuYXRpdmUgbmV0d29yay4gIE9uZSBnb29kDQogICBuZXdzIGlzIHRoYXQgSVB2NiBzdXBw b3J0IGluIHByb3RvY29sIHN0YWNrIGhhcyBiZWVuIGF2YWlsYWJsZSBmb3INCiAgIG1hbnkgbWFp bi1zdHJlYW0gb3BlcmF0aW5nIHN5c3RlbXMsIGUuZy4sIExpbnV4LCBNUyBXaW5kb3dzLiAgSXQg aXMNCiAgIGVhc3kgdG8gdXBkYXRlIHRoZSBzb2Z0d2FyZSB0byBoYXZlIElQdjYgc3VwcG9ydC4g IFRvIGNvbW11bmljYXRlDQogICB3aXRoIHRoZSBwZW9wbGUgaW4gdGhlIElQdjYgbmF0aXZlIG5l dHdvcmsgYW5kIHRvIHVzZSB0aGUgc2VydmljZSBpbg0KICAgdGhlIElQdjYgbmF0aXZlIG5ldHdv cmsgYXJlIHRoZSBpbmNlbnRpdmVzIGZvciB0aGUgZW5kIHVzZXJzIHRvDQogICBhY2Nlc3MgdGhl IElQdjYgbmF0aXZlIG5ldHdvcmsgdmlhIHRoZSBJUHY2IEFjY2VzcyBQb2ludC4NCg0KICAgRnJv bSB0aGUgcG9pbnQgb2YgdGhlIElTUCBvZiBJUHY0IG5hdGl2ZSBuZXR3b3JrLiAgVG8gbWVldCB0 aGUgZGVtYW5kDQogICBmcm9tIHRoZSB1c2VycyB0byBhY2Nlc3MgSVB2NiwgaXQgaXMgbm90IG5l Y2Vzc2FyeSB0byByZXBsYWNlIHRoZQ0KICAgSVB2NCBzd2l0Y2hlcyBhbmQgcm91dGVycyBpbiB0 aGUgbmVhciBmdXR1cmUuICBUaGVpciBpbnZlc3RtZW50IG9uDQogICB0aGUgSVB2NCBkZXZpY2Vz IGFyZSBwcm90ZWN0ZWQsIHdoaWxlIHRoZWlyIGN1c3RvbWVycyBjYW4gc3RpbGwNCiAgIGFjY2Vz cyBJUHY2Lg0KDQogICBGcm9tIHRoZSBwb25pdCBvZiB0aGUgSVNQIG9mIElQdjYgbmF0aXZlIG5l dHdvcmsuICBJdCBpcyBhIGdvb2QNCiAgIGFzcGVjdCB0aGF0IHRoZSBleGlzdGluZyBJUHY0IG5l dHdvcmsgaGFzIHByb3ZpZGVkIGFjY2VzcyBsaW5rIHRvIHRoZQ0KICAgZW5kIHVzZXJzLiAgVGhv dWdoIHByb2JhYmx5IHRoZXkgY2FuJ3QgZGlyZWN0bHkgZ2V0IGluY29tZSBmcm9tDQoNCg0KDQpa aGFuZyAmIFd1ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAg ICAgICAgW1BhZ2UgN10NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAgIFRoZSBVbml2ZXI2IEFy Y2hpdGVjdHVyZSAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIHByb3ZpZGluZyBJUHY2 IGFjY2VzcyBwb2ludCwgdGhlIHZhbHVlIG9mIHRoZWlyIElQdjYgbmF0aXZlIG5ldHdvcmsNCiAg IHdpbGwgaW5jcmVhc2UgYXMgbW9yZSBhbmQgbW9yZSBwZW9wbGUgaGF2ZSBhY2Nlc3MgdG8gdGhl IElQdjYgbmF0aXZlDQogICBuZXR3b3JrLg0KDQogICBGcm9tIHRoZSBwb2ludCBvZiB0aGUgQXBw bGljYXRpb24gU2VydmljZSBQcm92aWRlcihBU1ApLiAgVGhlIFVuaXZlcjYNCiAgIGFyY2hpdGVj dHVyZSBwcm92aWRlcyBhIHBsYXRmb3JtIHRoYXQgdGhleSBjYW4gcHJvdmlkZSBzZXJ2aWNlIHRv DQogICBib3RoIElQdjQgYW5kIElQdjYgbmV0d29yayB1c2Vycy4NCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQpaaGFuZyAmIFd1ICAgICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwg MjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURyYWZ0ICAgICAgICAg IFRoZSBVbml2ZXI2IEFyY2hpdGVjdHVyZSAgICAgICAgICAgIEphbnVhcnkgMjAwNg0KDQoNCjQu ICBUaGUgY2hhbGxlbmdlcw0KDQogICBUbyBhY2hpZXZlIHRoZSBVbml2ZXI2IGFyY2hpdGVjdHVy ZSwgdGhlcmUgYXJlIGFsc28gc29tZSBjaGFsbGVuZ2VzLg0KICAgSGVyZSB3ZSBvbmx5IG1lbnRp b24gdHdvIGltcG9ydGFudCBjaGFsbGVuZ2VzLiAgT25lIGlzIGhvdyB0byBzdXBwb3J0DQogICBh Y2Nlc3MgdG8gSVB2NiBpbiB0aGUgSVB2NCBuYXRpdmUgbmV0d29yayB3aXRoIGxvdyBjb3N0LiAg VGhlIG90aGVyDQogICBpcyBob3cgdG8gc3VwcG9ydCBJUHY0IGFwcGxpY2F0aW9uIG92ZXIgSVB2 NiBwcm90b2NvbC4NCg0KNC4xLiAgSVB2NiBhY2Nlc3MgZm9yIGhvc3RzIGluIElQdjQgbmF0aXZl IG5ldHdvcmsNCg0KICAgVGhlIGhvc3RzIG9yIElQdjYgaXNsYW5kcyBpbiB0aGUgSVB2NCBuYXRp dmUgbmV0d29yayBnZXQgYWNjZXNzIHRvDQogICB0aGUgSVB2NiBuYXRpdmUgbmV0d29yayB2aWEg SVB2NiBBY2Nlc3MgUG9pbnQgd2l0aCBJUHY2IG92ZXIgSVB2NA0KICAgdHVubmVsLiAgSWYgbm8g c3BlY2lhbCBjb25zaWRlcmF0aW9uLCBhbG1vc3QgYWxsIElQdjYgdHJhZmZpYyAoZXhjZXB0DQog ICB0cmFmZmljIGluc2lkZSB0aGUgSVB2NiBpc2xhbmRzKSBmcm9tIHRoZSBob3N0cyBpbiBJUHY0 IG5hdGl2ZQ0KICAgbmV0d29yayB3aWxsIGJlIGZvcndhcmRlZCBieSBJUHY2IEFjY2VzcyBQb2lu dC4gIEl0IHdpbGwgbm90IG9ubHkNCiAgIG1ha2UgdGhlIElQdjYgQWNjZXNzIFBvaW50IGEgcGVy Zm9ybWFuY2UgYm90dGxlbmVjaywgYnV0IGFsc28gcHV0IGENCiAgIGJ1cmRlbiBvbiB0aGUgSVNQ IHdoaWNoIChpbiBtb3N0IGNhc2VzLCBmcmVlKSBwcm92aWRlcyB0aGUgSVB2Ng0KICAgQWNjZXNz IFBvaW50Lg0KDQogICBJbiB0aGUgVW5pdmVyNiBhcmNoaXRlY3R1cmUsIElQdjYgQWNjZXNzIFBv aW50IGlzIGEgYnJpZGdlIGJldHdlZW4NCiAgIHRoZSAiSVB2NCBjb250aW5lbnQiIGFuZCB0aGUg IklQdjYgY29udGluZW50Ii4gIEl0IGlzIG9ubHkgbmVjZXNzYXJ5DQogICBmb3IgdGhlIHRyYWZm aWMgYmV0d2VlbiB0aGUgdHdvIGNvbnRpbmVudHMgdG8gYmUgZm9yd2FyZGVkIG92ZXIgdGhlDQog ICBJUHY2IEFjY2VzcyBQb2ludC4gIFNvbWUgbWV0aG9kcyBjYW4gYmUgZGVzaWduZWQgdG8gYXZv aWQgdGhlIHRyYWZmaWMNCiAgIGZvciB0aGUgSVB2NiBjb21tdW5pY2F0aW9uIGluc2lkZSB0aGUg SVB2NCBjb250aW5lbnQgYmVpbmcgZm9yd2FyZGVkDQogICBieSB0aGUgSVB2NiBBY2Nlc3MgUG9p bnQuDQoNCjQuMi4gIFN1cHBvcnQgSVB2NCBhcHBsaWNhdGlvbiBvdmVyIElQdjYNCg0KICAgVG8g cHJvdmlkZSB0aGUgc3VwcG9ydCBmb3IgSVB2NCBhcHBsaWNhdGlvbiBydW5uaW5nIG92ZXIgSVB2 NiBpcyBub3QNCiAgIG9ubHkgdGhlIHJlcXVpcmVtZW50IGZvciBVbml2ZXI2IGFyY2hpdGVjdHVy ZSwgYnV0IGFsc28gYSByZXF1aXJlbWVudA0KICAgZm9yIHRoZSBJbnRlcm5ldCBhZnRlciB0cmFu c2l0aW9uIHRvIGEgcHVyZSBJUHY2IG5ldHdvcmsuICBUaGUNCiAgIGFzc3VtcHRpb24gaXMgdGhh dCB0aGVyZSB3aWxsIGJlIG5vIElQdjQgc3VwcG9ydCBleGlzdGluZyBpbiB0aGUNCiAgIG5ldHdv cmssIGUuZy4sIElQdjQgcm91dGVycywgb3IgSVB2NCBETlMuICBUaGUgZ29hbCBpcyB0byBydW4g dGhlDQogICBsZWdhY3kgSVB2NCBhcHBsaWNhdGlvbiwgd2l0aG91dCBtb2RpZnlpbmcgYW5kIHJl LWNvbXBpbGluZyB0aGUgY29kZQ0KICAgb2YgdGhlIGFwcGxpY2F0aW9uLg0KDQogICBGb3IgdGhl IElQdjQgYXBwbGljYXRpb24sIHRoZSBQcm9jb2NvbCBMYXllciBvZiBVbml2ZXI2IHNob3VsZCBh Y3QgYXMNCiAgIGEgIm5ldHdvcmsgdmlydHVhbCBtYWNoaW5lIiwgd2hpY2ggbWFrZXMgdGhlIElQ djQgYXBwbGljYXRpb24gcnVuDQogICBqdXN0IGFzIG92ZXIgYSByZWFsIElQdjQgbmV0d29yay4N Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KWmhhbmcgJiBXdSAgICAgICAgICAgICAgICBFeHBp cmVzIEp1bHkgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1E cmFmdCAgICAgICAgICBUaGUgVW5pdmVyNiBBcmNoaXRlY3R1cmUgICAgICAgICAgICBKYW51YXJ5 IDIwMDYNCg0KDQo1LiAgUmVmZXJlbmNlcw0KDQogICBbMV0gIENhcnBlbnRlciwgQi4gYW5kIEsu IE1vb3JlLCAiQ29ubmVjdGlvbiBvZiBJUHY2IERvbWFpbnMgdmlhIElQdjQNCiAgICAgICAgQ2xv dWRzIiwgUkZDIDMwNTYsIEZlYnJ1YXJ5IDIwMDEuDQoNCiAgIFsyXSAgRHVyYW5kLCBBLiwgRmFz YW5vLCBQLiwgR3VhcmRpbmksIEkuLCBhbmQgRC4gTGVudG8sICJJUHY2IFR1bm5lbA0KICAgICAg ICBCcm9rZXIiLCBSRkMgMzA1MywgSmFudWFyeSAyMDAxLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNClpoYW5nICYgV3UgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE0LCAyMDA2 ICAgICAgICAgICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgVGhl IFVuaXZlcjYgQXJjaGl0ZWN0dXJlICAgICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KQXV0aG9y cycgQWRkcmVzc2VzDQoNCiAgIE1pYW8gWmhhbmcNCiAgIFRzaW5naHVhIFVuaXZlcnNpdHkNCiAg IE5ldHdvcmsgUmVzZWFyY2ggQ2VudGVyLCBUc2luZ2h1YSBVbml2ZXJzaXR5DQogICBCZWlqaW5n ICAxMDAwODQNCiAgIFAuUi5DaGluYQ0KDQogICBFbWFpbDogem1AY2VybmV0LmVkdS5jbg0KDQoN CiAgIEppYW5waW5nIFd1DQogICBUc2luZ2h1YSBVbml2ZXJzaXR5DQogICBOZXR3b3JrIFJlc2Vh cmNoIENlbnRlciwgVHNpbmdodWEgVW5pdmVyc2l0eQ0KICAgQmVpamluZyAgMTAwMDg0DQogICBQ LlIuQ2hpbmENCg0KICAgRW1haWw6IGppYW5waW5nQGNlcm5ldC5lZHUuY24NCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClpo YW5nICYgV3UgICAgICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE0LCAyMDA2ICAgICAgICAgICAg ICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgICAgICAgVGhlIFVuaXZlcjYgQXJj aGl0ZWN0dXJlICAgICAgICAgICAgSmFudWFyeSAyMDA2DQoNCg0KRnVsbCBDb3B5cmlnaHQgU3Rh dGVtZW50DQoNCiAgIENvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYpLg0K DQogICBUaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5k IHJlc3RyaWN0aW9ucw0KICAgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kIGV4Y2VwdCBhcyBzZXQg Zm9ydGggdGhlcmVpbiwgdGhlIGF1dGhvcnMNCiAgIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0K DQogICBUaGlzIGRvY3VtZW50IGFuZCB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBh cmUgcHJvdmlkZWQgb24gYW4NCiAgICJBUyBJUyIgYmFzaXMgYW5kIFRIRSBDT05UUklCVVRPUiwg VEhFIE9SR0FOSVpBVElPTiBIRS9TSEUgUkVQUkVTRU5UUw0KICAgT1IgSVMgU1BPTlNPUkVEIEJZ IChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVUDQogICBFTkdJ TkVFUklORyBUQVNLIEZPUkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElN UExJRUQsDQogICBJTkNMVURJTkcgQlVUIE5PVCBMSU1JVEVEIFRPIEFOWSBXQVJSQU5UWSBUSEFU IFRIRSBVU0UgT0YgVEhFDQogICBJTkZPUk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0Ug QU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElFRA0KICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJ VFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuDQoNCg0KSW50ZWxsZWN0dWFs IFByb3BlcnR5DQoNCiAgIFRoZSBJRVRGIHRha2VzIG5vIHBvc2l0aW9uIHJlZ2FyZGluZyB0aGUg dmFsaWRpdHkgb3Igc2NvcGUgb2YgYW55DQogICBJbnRlbGxlY3R1YWwgUHJvcGVydHkgUmlnaHRz IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWltZWQgdG8NCiAgIHBlcnRhaW4gdG8g dGhlIGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4N CiAgIHRoaXMgZG9jdW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRl ciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWlsYWJsZTsgbm9yIGRv ZXMgaXQgcmVwcmVzZW50IHRoYXQgaXQgaGFzDQogICBtYWRlIGFueSBpbmRlcGVuZGVudCBlZmZv cnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24NCiAgIG9uIHRoZSBw cm9jZWR1cmVzIHdpdGggcmVzcGVjdCB0byByaWdodHMgaW4gUkZDIGRvY3VtZW50cyBjYW4gYmUN CiAgIGZvdW5kIGluIEJDUCA3OCBhbmQgQkNQIDc5Lg0KDQogICBDb3BpZXMgb2YgSVBSIGRpc2Ns b3N1cmVzIG1hZGUgdG8gdGhlIElFVEYgU2VjcmV0YXJpYXQgYW5kIGFueQ0KICAgYXNzdXJhbmNl cyBvZiBsaWNlbnNlcyB0byBiZSBtYWRlIGF2YWlsYWJsZSwgb3IgdGhlIHJlc3VsdCBvZiBhbg0K ICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGljZW5zZSBvciBwZXJtaXNzaW9u IGZvciB0aGUgdXNlIG9mDQogICBzdWNoIHByb3ByaWV0YXJ5IHJpZ2h0cyBieSBpbXBsZW1lbnRl cnMgb3IgdXNlcnMgb2YgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiBjYW4gYmUgb2J0YWluZWQgZnJv bSB0aGUgSUVURiBvbi1saW5lIElQUiByZXBvc2l0b3J5IGF0DQogICBodHRwOi8vd3d3LmlldGYu b3JnL2lwci4NCg0KICAgVGhlIElFVEYgaW52aXRlcyBhbnkgaW50ZXJlc3RlZCBwYXJ0eSB0byBi cmluZyB0byBpdHMgYXR0ZW50aW9uIGFueQ0KICAgY29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRl bnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBwcm9wcmlldGFyeQ0KICAgcmlnaHRzIHRoYXQgbWF5 IGNvdmVyIHRlY2hub2xvZ3kgdGhhdCBtYXkgYmUgcmVxdWlyZWQgdG8gaW1wbGVtZW50DQogICB0 aGlzIHN0YW5kYXJkLiAgUGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRG IGF0DQogICBpZXRmLWlwckBpZXRmLm9yZy4NCg0KDQpBY2tub3dsZWRnbWVudA0KDQogICBGdW5k aW5nIGZvciB0aGUgUkZDIEVkaXRvciBmdW5jdGlvbiBpcyBjdXJyZW50bHkgcHJvdmlkZWQgYnkg dGhlDQogICBJbnRlcm5ldCBTb2NpZXR5Lg0KDQoNCg0KDQoNClpoYW5nICYgV3UgICAgICAgICAg ICAgICAgRXhwaXJlcyBKdWx5IDE0LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDEyXQ0KDA0K --=====001_Dragon115312350104_===== Content-Type: application/octet-stream; name="draft-zhang-transition-multihoming-00.txt" Content-Disposition: attachment; filename="draft-zhang-transition-multihoming-00.txt" Content-Transfer-Encoding: base64 DQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIE0uIFpoYW5nDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSi4gQmkNCkV4cGlyZXM6IEp1bHkgMTQs IDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBKLiBXdQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUc2lu Z2h1YSBVbml2ZXJzaXR5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEphbnVhcnkgMTAsIDIwMDYNCg0KDQogTWl0aWdhdGluZyB0aGUgQnVy ZGVuIG9mIElQdjYgUmVsYXkgR2F0ZXdheSB3aXRoIE11bHRpaG9taW5nIE1lY2hhbmlzbQ0KICAg ICAgICAgICAgICAgICBkcmFmdC16aGFuZy10cmFuc2l0aW9uLW11bHRpaG9taW5nLTAwDQoNClN0 YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgQnkgc3VibWl0dGluZyB0aGlzIEludGVybmV0LURyYWZ0 LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55DQogICBhcHBsaWNhYmxlIHBhdGVudCBv ciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBpcyBhd2FyZQ0KICAgaGF2ZSBi ZWVuIG9yIHdpbGwgYmUgZGlzY2xvc2VkLCBhbmQgYW55IG9mIHdoaWNoIGhlIG9yIHNoZSBiZWNv bWVzDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4gYWNjb3JkYW5jZSB3aXRoIFNlY3Rp b24gNiBvZiBCQ1AgNzkuDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVu dHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0DQogICBvdGhlciBncm91 cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0NCiAg IERyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxh Y2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQ0KICAgdGltZS4gIEl0 IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UNCiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiINCg0KICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vz c2VkIGF0DQogICBodHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuDQoN CiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuDQoNCiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gSnVseSAxNCwgMjAwNi4NCg0KQ29weXJp Z2h0IE5vdGljZQ0KDQogICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA2 KS4NCg0KQWJzdHJhY3QNCg0KICAgRm9yIGEgaG9zdCBpbiB0aGUgSVB2NCBuYXRpdmUgbmV0d29y ayB0byBjb21tdW5pY2F0ZSB3aXRoIG90aGVyIGhvc3RzDQogICB3aXRoIElQdjYsIG9uZSBwb3Nz aWJsZSB3YXkgaXMgdG8gc2V0IHVwIElQdjYtaW4tSVB2NCB0dW5uZWwgdG8gdGhlDQogICBJUHY2 IG5hdGl2ZSBuZXR3b3JrIHdpdGggc29tZSByZWxheSBnYXRld2F5LiAgSXQgaXMgZXhwZWN0ZWQg dGhhdCB0aGUNCiAgIHJlbGF5IGdhdGV3YXkgd2lsbCBiZWNvbWUgYSBib3R0bGVuZWNrIGZvciB0 aGUgZGF0YSBmb3J3YXJkaW5nLiAgSW4NCiAgIHRoaXMgZG9jdW1lbnQsIHdlIHByb3Bvc2UgYSBz Y2hlbWUgdGhhdCBhcHBseWluZyBtdWx0aWhvbWluZw0KICAgbWVjaGFuaXNtIChkZXJpdmVkIGZy b20gdGhlIHdvcmsgYXQgc2hpbTYgV0cpIHRvIGRlY3JlYXNlIHRoZQ0KICAgb3ZlcmhlYWQgYXQg dGhlIElQdjYgcmVsYXkgZ2F0ZXdheS4gIElmIGJvdGggb2YgdGhlIHR3byBJUHY2IGhvc3RzDQoN Cg0KDQpaaGFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAg ICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgIEFwcGx5IE11bHRpaG9t aW5nIGluIElQdjYgVHJhbnNpdGlvbiAgICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIGFyZSBpbiB0 aGUgSVB2NCBuYXRpdmUgbmV0d29yaywgdGhleSBjYW4gc3dpdGNoIHRvIGNvbW11bmljYXRpbmcN CiAgIGRpcmVjdGx5IHdpdGggNnRvNCBhZGRyZXNzIGJ5IHVzaW5nIHRoZSBtZWNoYW5pc20gcHJv cG9zZWQgaW4gdGhlDQogICBzaGltNiBXb3JraW5nIEdyb3VwLCB0aHVzIG1pdGlnYXRlIHRoZSBi dXJkZW4gb2YgcGFja2V0IGZvcndhcmRpbmcgYXQNCiAgIHRoZSBJUHY2IHJlbGF5IGdhdGV3YXku DQoNCg0KVGFibGUgb2YgQ29udGVudHMNCg0KICAgMS4gIEludHJvZHVjdGlvbiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAzDQogICAyLiAgUHJvYmxl bSBTdGF0ZW1lbnQgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDQNCiAgIDMuICBTb2x1dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAzLjEuICBCYXNpYyBJZGVhcyAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA2DQogICAgIDMuMi4gIERldGFpbHMg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAg IDQuICBPdGhlciBJc3N1ZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgOA0KICAgICA0LjEuICBHZW5lcmF0aW9uIG9mIDZ0bzQgQWRkcmVzcyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4DQogICAgIDQuMi4gIFJlbGF0aW9uIHdpdGgg c2hpbTYgUHJvdG9jb2wgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDgNCiAgIDUuICBC ZW5lZml0IEFuYWx5c2lzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAgOQ0KICAgICA1LjEuICBJbmNlbnRpdmUgZm9yIERlcGxveW1lbnQgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICA5DQogICAgIDUuMi4gIEluY3JlbWVudGFsIERlcGxveW1l bnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDkNCiAgIDYuICBSZWZlcmVu Y2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAx MA0KICAgQXBwZW5kaXggQS4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIDExDQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMTINCiAgIEludGVsbGVjdHVhbCBQcm9w ZXJ0eSBhbmQgQ29weXJpZ2h0IFN0YXRlbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAxMw0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpaaGFu ZywgZXQgYWwuICAgICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAg ICAgW1BhZ2UgMl0NCgwNCkludGVybmV0LURyYWZ0ICAgIEFwcGx5IE11bHRpaG9taW5nIGluIElQ djYgVHJhbnNpdGlvbiAgICAgIEphbnVhcnkgMjAwNg0KDQoNCjEuICBJbnRyb2R1Y3Rpb24NCg0K ICAgSWYgYSBob3N0IGluIHRoZSBJUHY0IG5hdGl2ZSBuZXR3b3JrIHdhbnRzIHRvIHRhbGsgd2l0 aCBvdGhlciBob3N0DQogICB3aXRoIElQdjYgYWRkcmVzcywgb25lIHBvc3NpYmxlIHdheSBpcyB0 byBhc3NpZ24gaXQgd2l0aCBhIGdsb2JhbA0KICAgUHJvdmlkZXItQXNzaWduZWQgSVB2NiBhZGRy ZXNzLiAgVGhlIElTUCB3aGljaCBvd25zIHRoZSBhZGRyZXNzIGNhbg0KICAgcHJvdmlkZSBJUHY2 IGFjY2VzcyBzZXJ2aWNlIHdpdGggc29tZSBJUHY2IHJlbGF5IGdhdGV3YXkgdG8gdGhlIElQdjYN CiAgIG5hdGl2ZSBuZXR3b3JrIGJ5IHVzaW5nIHNvbWUgbWVjaGFuaXNtcyBsaWtlIElQdjYgVHVu bmVsIEJyb2tlciBbMV0uDQogICBJdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBJUHY2IHJlbGF5IGdh dGV3YXkgd2lsbCBiZWNvbWUgYSBib3R0bGVuZWNrLA0KICAgc2luY2UgYWxsIElQdjYgdHJhZmZp YyBmcm9tIG9yIHRvIHRoaXMgaG9zdCB3aWxsIGJlIGZvcndhcmRlZCB0aHJvdWdoDQogICB0aGUg cmVsYXkgZ2F0ZXdheS4NCg0KICAgVGhpcyBtZW1vIHByb3Bvc2VzIGEgc2ltcGxlIHNvbHV0aW9u IHRvIG1pdGlnYXRlIHRoZSBidXJkZW4gb2YgSVB2Ng0KICAgcmVsYXkgZ2F0ZXdheSB3aXRoIHRo ZSBtdWx0aWhvbWluZyBtZWNoYW5pc20uICBPbmUgb2JzZXJ2YXRpb24gaXMNCiAgIHRoYXQgbWFu eSBob3N0cyB0aGF0IG1heSBiZSB0aGUgcG90ZW50aWFsIHVzZXJzIG9mIElQdjYgYXBwbGljYXRp b25zDQogICBhcmUgc3RpbGwgaW4gdGhlIElQdjQgbmF0aXZlIG5ldHdvcmsuICBJdCBpcyB2ZXJ5 IHBvc3NpYmxlIHRoYXQgdHdvDQogICBob3N0cyB0aGF0IGNvbW11bmljYXRlIGVhY2ggb3RoZXIg d2l0aCBJUHY2IGFyZSBib3RoIGluIHRoZSBJUHY0DQogICBuYXRpdmUgbmV0d29yay4gIEluIHRo aXMgc2l0dWF0aW9uLCBpdCBpcyB1bm5lY2Vzc2FyeSB0byBmb3J3YXJkIElQdjYNCiAgIHRyYWZm aWMgYmV0d2VlbiB0aGVzZSB0d28gaG9zdHMgYnkgdGhlIElQdjYgcmVsYXkgZ2F0ZXdheS4gIFRo ZXkgY2FuDQogICBkaXJlY3RseSBleGNoYW5nZSBJUHY2IHRyYWZmaWMgaW4gdGhlIElQdjQgbmF0 aXZlIG5ldHdvcmsgd2l0aCA2dG80DQogICBbMl0gYWRkcmVzcy4gIFRoZSBjdXJyZW50IHByb2dy ZXNzIGluIFNoaW02IFdHIFszXSBwcm92aWRlcyBtZWFzdXJlcw0KICAgZm9yIHN3aXRjaGluZyBi ZXR3ZWVuIGdsb2JhbCBQQSBhZGRyZXNzIGFuZCA2dG80IGFkZHJlc3MsIHdpdGhvdXQgYW55DQog ICBoZWxwIGZyb20gdGhlIHRoaXJkIHBhcnRpZXMuDQoNCiAgIFRoZSBzZWNvbmQgc2VjdGlvbiBn aXZlcyBhIGJyaWVmIHByb2JsZW0gc3RhdGVtZW50LiAgVGhlIHRoaXJkDQogICBzZWN0aW9uIGRl c2NyaWJlcyB0aGUgZGV0YWlsIG1lY2hhbmlzbSBvZiB0aGUgc29sdXRpb24uICBUaGUgZm91cnRo DQogICBzZWN0aW9uIGRpc2N1c3NlcyBzb21lIHJlbGF0ZWQgaXNzdWVzLiAgVGhlIGZpZnRoIHNl Y3Rpb24gZGVzY3JpYmVzDQogICB0aGUgYmVuZWZpdCBvZiB0aGUgc29sdXRpb24uDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpaaGFuZywgZXQgYWwuICAg ICAgICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgM10N CgwNCkludGVybmV0LURyYWZ0ICAgIEFwcGx5IE11bHRpaG9taW5nIGluIElQdjYgVHJhbnNpdGlv biAgICAgIEphbnVhcnkgMjAwNg0KDQoNCjIuICBQcm9ibGVtIFN0YXRlbWVudA0KDQogICBXaXRo IHRoZSBtYXR1cml0eSBvZiB0aGUgSVB2NiB0ZWNobm9sb2d5LCB0aGVyZSBoYXZlIGJlZW4gc29t ZSBJUHY2DQogICBuYXRpdmUgbmV0d29ya3MgZXhpc3RpbmcuICBNZWFud2hpbGUsIGl0IGlzIGhh cmQgdG8gY2hhbmdlIHRoZQ0KICAgcm91dGVycyBhbmQgc3dpdGNoZXMgb2YgdGhlIGN1cnJlbnQg SVB2NCBuYXRpdmUgbmV0d29yayB0byBzdXBwb3J0DQogICBJUHY2LiAgU28gaXQgaXMgcG9zc2li bGUgdGhhdCB0aGVyZSB3aWxsIGJlIGEgbG9uZyB0aW1lIGZvciBib3RoIElQdjQNCiAgIG5hdGl2 ZSBuZXR3b3JrIGFuZCBJUHY2IG5hdGl2ZSBuZXR3b3JrIHRvIGNvZXhpc3QuICBPbmUgaW50ZXJl c3RpbmcNCiAgIHByb2JsZW0gaXMgaG93IHRvIHByb3ZpZGUgbWVjaGFuaXNtIGZvciB0aGUgaG9z dCBpbiBJUHY0IG5hdGl2ZQ0KICAgbmV0d29yayB0byBhY2Nlc3MgdGhlIElQdjYgbmV0d29yayBh bmQgdG8gdXNlIElQdjYgYXBwbGljYXRpb24uDQogICBUaGVyZSBhcmUgdHdvIGNvbW1vbiB3YXlz IHNob3duIGFzIHRoZSBhZGRyZXNzIGZvcm1hdDogNnRvNCBhZGRyZXNzLA0KICAgZ2xvYmFsIElQ djYgYWRkcmVzcy4NCg0KICAgNnRvNCBhZGRyZXNzIGlzIG5vdCBwcmVmZXJyZWQgZm9yIGNvbW1v biBJUHY2IGNvbW11bmljYXRpb24sIGZvciB0aGUNCiAgIHByb2JsZW0gb2YgcmVsYXlpbmcgdHJh ZmZpYyBiZXR3ZWVuIElQdjQgbmF0aXZlIG5ldHdvcmsgYW5kIElQdjYNCiAgIG5hdGl2ZSBuZXR3 b3JrIFs0XS4gIE9uZSBwcm9ibGVtIGlzIGhvdyB0byBmaW5kIHRoZSByZWxheSBzZXJ2aWNlIGlu DQogICB0aGUgSVB2NCBuYXRpdmUgbmV0d29yay4gIEFub3RoZXIgcHJvYmxlbSBpcyBob3cgdG8g cm91dGUgYmFjayB0aGUNCiAgIHBhY2tldCBmcm9tIElQdjYgbmF0aXZlIG5ldHdvcmsgdG8gNnRv NCBob3N0LiAgSXQncyBoYXJkIHRvIGRvDQogICBhZ2dyZWdhdGlvbiBmb3IgNnRvNCBhZGRyZXNz Lg0KDQogICBXaXRoIGdsb2JhbCBJUHY2IGFkZHJlc3MgYXNzaWduZWQsIHRoZSByZWxhdGlvbnNo aXAgYmV0d2VlbiB0aGUgaG9zdA0KICAgaW4gSVB2NCBuYXRpdmUgbmV0d29yayBhbmQgdGhlIElT UCB3aGljaCBwcm92aWRlcyBJUHY2IGFjY2VzcyBzZXJ2aWNlDQogICBpcyB2ZXJ5IGNsZWFyLiAg QWxzbywgc2luY2UgdGhlIGFkZHJlc3Mgb2YgdGhlIGhvc3QgaXMgaW4gdGhlIGFkZHJlc3MNCiAg IGJsb2NrIG9mIHRoZSBJU1AsIGl0IGlzIGVhc3kgdG8gZG8gcm91dGluZyBpbiB0aGUgSVB2NiBu YXRpdmUNCiAgIG5ldHdvcmsuICBIb3dldmVyLCBpdCBpcyBleHBlY3RlZCB0aGF0IHRoZSBJUHY2 IHJlbGF5IGdhdGV3YXkgd2lsbA0KICAgYmVjb21lIGEgYm90dGxlbmVjay4gIEFsbCB0aGUgSVB2 NiB0cmFmZmljIGZvciB0aGUgaG9zdHMgaW4gSVB2NA0KICAgbmF0aXZlIG5ldHdvcmsgd2lsbCBi ZSBmb3J3YXJkZWQgYnkgdGhlIHJlbGF5IGdhdGV3YXkuICBBbg0KICAgaW50ZXJlc3RpbmcgcHJv YmxlbSBpcyBob3cgdG8gbWl0aWdhdGUgdGhlIGJ1cmRlbiBvZiB0aGUgcmVsYXkNCiAgIGdhdGV3 YXkuDQoNCiAgIEhlcmUgd2UgaW1hZ2luZSBhIHNjZW5hcmlvOiB0aGUgaG9zdCBpbiB0aGUgSVB2 NCBuYXRpdmUgbmV0d29yayBhbmQNCiAgIHRoZSBob3N0IGluIHRoZSBJUHY2IG5ldHdvcmsgYWxs IHJ1biBJUHY2IGFwcGxpY2F0aW9uIHdpdGggSVB2Ng0KICAgYWRkcmVzcywgYXMgc2hvd24gaW4g RmlndXJlIDEuICBIb3N0IEEsIEhvc3QgQiBhbmQgSG9zdCBDIGFyZSBpbiBJUHY0DQogICBuYXRp dmUgbmV0d29yay4gIFRoZXkgYWxsIGhhdmUgNnRvNCBhZGRyZXNzZXMuICBIb3N0IEEgYW5kIEhv c3QgQiBnZXQNCiAgIGdsb2JhbCBJUHY2IGFkZHJlc3NlcyBhbmQgYWNjZXNzIHNlcnZpY2UgdG8g bmF0aXZlIElQdjYgbmV0d29yayBmcm9tDQogICBJU1AgQS4gSG9zdCBDIGdldHMgZ2xvYmFsIElQ djYgYWRkcmVzcyBhbmQgYWNjZXNzIHNlcnZpY2UgdG8gbmF0aXZlDQogICBJUHY2IG5ldHdvcmsg ZnJvbSBJU1AgQi4gSG9zdCBEIGlzIGluIHRoZSBJUHY2IG5hdGl2ZSBuZXR3b3JrLCBhbmQgaXQN CiAgIG9ubHkgaGFzIGdsb2JhbCBJUHY2IGFkZHJlc3MuDQoNCiAgIEhvc3QgQSBoYXMgY29tbXVu aWNhdGlvbiB3aXRoIEhvc3QgQiwgSG9zdCBDIGFuZCBIb3N0IEQuIEZvcg0KICAgY29tbXVuaWNh dGlvbiBiZXR3ZWVuIEhvc3QgQSBhbmQgSG9zdCBELCB0aGUgaGVscCBmcm9tIHRoZSByZWxheQ0K ICAgZ2F0ZXdheSBvZiBJU1AgQSBpcyBuZWNlc3NhcnkuICBGb3IgY29tbXVuaWNhdGlvbiBiZXR3 ZWVuIEhvc3QgQSBhbmQNCiAgIEhvc3QgQiwgSG9zdCBBIGFuZCBIb3N0IEMsIGl0IGlzIGFsc28g cmVxdWlyZWQgdGhlIGhlbHAgZnJvbSB0aGUNCiAgIHJlbGF5IGdhdGV3YXksIHdoaWNoIHdlIGJl bGlldmUgdG8gYmUgdW5uZWNlc3NhcnkuDQoNCg0KDQoNCg0KDQoNCg0KWmhhbmcsIGV0IGFsLiAg ICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDRd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICBBcHBseSBNdWx0aWhvbWluZyBpbiBJUHY2IFRyYW5zaXRp b24gICAgICBKYW51YXJ5IDIwMDYNCg0KDQogICAgICAgICAgICAsLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0uDQogICAgICAgICAgICwnICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgYA0KICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBcDQogICAgICAgICAvICAgKy0tLSsgICAgICAgICAgICAgICAgICAgICAgKy0tLSsg ICAgICBcDQogICAgICAgIDsgICAgfCBBIHwgICAgICAgICAgICAgICAgICAgICAgfCBDIHwgICAg ICAgOiAgICAgICAgIElQdjQNCiAgICAgICAgfCAgICArLS0tKyAgICAgICAgICAgICAgICAgICAg ICArLS0tKyAgICAgICB8ICAgICAgICBOYXRpdmUNCiAgICAgICAgOiAgICAgL3xcICAgICAgICAg ICAgICAgICAgICAgICAgL3xcICAgICAgICA7ICAgICAgICBOZXR3b3JrDQogICAgICAgICBcICAg ICB8ICAgICAgICAgICstLS0rICAgICAgICAgICB8ICAgICAgICAgLw0KICAgICAgICAgIFwgICAg fCAgICAgICAgICB8IEIgfCAgICAgICAgICAgfCAgICAgICAgLw0KICAgICAgICAgICBgLiAgLS0t fCAgICAgICArLS0tKyAgICAgICAgICAgfCAgICAgICAsJw0KICAgICAgICAgICAgICctLS0tfC0t LS0tLS0tL3xcLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICBcfC8gICAgICAg IHwgICAgICAgICAgICBcfC8NCiAgICAgICAgICAgICAgICArLS0tLSsgICAgICB8ICAgICAgICAg ICstLS0tKw0KICAgICAgICAgICAgICAgIHwgR1cgfDwtLS0tLSAgICAgICAgICAgfCBHVyB8DQog ICAgICAgICAgICAsLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0uDQogICAgICAg ICAgICwnIFwgIElTUCBBICAvICAgICAgICAgICAgXCAgSVNQIEIgIC8gYA0KICAgICAgICAgIC8g ICAgYC4gICAgICwnICAgICAgICAgICAgICBgLiAgICAgLCcgICBcDQogICAgICAgICAvICAgICAg ICctLS0nICAgICAgICAgICAgICAgICAgJy0tLScgICAgICBcDQogICAgICAgIDsgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOiAgICAgICAgIElQdjYNCiAgICAgICAg fCAgICcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICBOYXRp dmUNCiAgICAgICAgOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA7 ICAgICAgICBOZXR3b3JrDQogICAgICAgICBcICAgICAgICAgICAgICAgICstLS0rICAgICAgICAg ICAgICAgICAgICAvDQogICAgICAgICAgXCAgICAgICAgICAgICAgIHwgRCB8ICAgICAgICAgICAg ICAgICAgIC8NCiAgICAgICAgICAgYC4gICAgICAgICAgICAgKy0tLSsgICAgICAgICAgICAgICAg ICwnDQogICAgICAgICAgICAgJy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQog ICBGaWd1cmUgMTogSVB2NiBjb21tdW5pY2F0aW9uIHdpdGggY29leGlzdGVuY2Ugb2YgSVB2NCBu YXRpdmUgbmV0d29yaw0KICAgYW5kIElQdjYgbmF0aXZlIG5ldHdvcmsNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpaaGFuZywgZXQgYWwuICAgICAgICAgICAg IEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCgwNCkludGVy bmV0LURyYWZ0ICAgIEFwcGx5IE11bHRpaG9taW5nIGluIElQdjYgVHJhbnNpdGlvbiAgICAgIEph bnVhcnkgMjAwNg0KDQoNCjMuICBTb2x1dGlvbg0KDQozLjEuICBCYXNpYyBJZGVhcw0KDQogICBU byBkZWNyZWFzZSB0aGUgb3ZlcmhlYWQgb2YgdGhlIElQdjYgcmVsYXkgZ2F0ZXdheSwgd2hlbiBi b3RoIG9mIHRoZQ0KICAgSVB2NiBob3N0cyBhcmUgaW4gdGhlIElQdjQgZG9taW5hbnQgbmV0d29y aywgdGhleSBjYW4gZGlyZWN0bHkNCiAgIGV4Y2hhbmdlIGRhdGEgd2l0aCA2dG80IGFkZHJlc3Ms IGluc3RlYWQgb2YgdXNpbmcgUHJvdmlkZXIgQXNzaWduZWQNCiAgIGFkZHJlc3MgYW5kIHJlbGF5 ZWQgYnkgdGhlIElQdjYgcmVsYXkgZ2F0ZXdheS4gIFRoZSBwcm9wb3NhbCBvZg0KICAgbXVsdGlo b21pbmcgbWVjaGFuaXNtIGluIHNoaW02IHdvcmtpbmcgZ3JvdXAgY2FuIGJlIGFwcGxpZWQgaGVy ZSB0bw0KICAgc29sdmUgdGhlIHByb2JsZW0gb2Ygc3dpdGNoaW5nIGZyb20gZ2xvYmFsIElQdjYg YWRkcmVzcyB0byA2dG80DQogICBhZGRyZXNzLg0KDQozLjIuICBEZXRhaWxzDQoNCiAgIEVhY2gg aG9zdCBpbiB0aGUgSVB2NCBkb21pbmFudCBuZXR3b3JrIHdoaWNoIHJ1bm5pbmcgSVB2NiB3aWxs IGhhdmUNCiAgIHR3byBJUHY2IGFkZHJlc3M6IFByb3ZpZGVyIEFzc2lnbiBhZGRyZXNzIGFzc2ln bmVkIGJ5IHRoZSBJUHY2IGFjY2Vzcw0KICAgc2VydmljZSBwcm92aWRlciwgNnRvNCBhZGRyZXNz IGdlbmVyYXRlZCBmcm9tIElQdjQgYWRkcmVzcyBvciA2dG80DQogICBwcmVmaXggYWR2ZXJ0aXNl bWVudCAodGhpcyBpc3N1ZSB3aWxsIGJlIGRpc2N1c3NlZCBsYXRlcikuDQoNCiAgIEZvciBlYXNl IG9mIG1hbmFnaW5nIHRoZSBJUHY2IGFkZHJlc3MsIHRoZSBob3N0IHdpbGwgdHJlYXQgdGhlIFBB DQogICBhZGRyZXNzIGFzIHRoZSBwcmltYXJ5IElQdjYgYWRkcmVzcywgYW5kIHRyZWF0IDZ0bzQg YWRkcmVzcyBhcyBhbg0KICAgYWx0ZXJuYXRpdmUgYWRkcmVzcy4gIFNvIHdoZW4gaW5pdGlhbGx5 IGNvbW11bmljYXRpbmcgd2l0aCBhbm90aGVyDQogICBob3N0LCB0aGUgUEEgSVB2NiBhZGRyZXNz IHdpbGwgYmUgdXNlZC4gIEFsc28sIHRoZSBQQSBJUHY2IGFkZHJlc3MNCiAgIHdpbGwgYmUgdXNl ZCBpbiB0aGUgRE5TIGVudHJ5LCBpZiB0aGUgaG9zdCBoYXMgYSBVUkwgaW4gdGhlIEROUw0KICAg c2VydmVyLg0KDQogICA2dG80IGFkZHJlc3MgaXMgdGhlIHByZWZlcnJlZCBhZGRyZXNzIHdoZW4g dGhlIGhvc3QgZmluZHMgdGhhdCB0aGUNCiAgIHBlZXIgaG9zdCBpbiBjb21tdW5pY2F0aW9uIGFs c28gaGFzIGEgNnRvNCBhZGRlcnNzLiAgSWYgdGhlIHBlZXIgaG9zdA0KICAgYWxzbyBoYXMgYSA2 dG80IGFkZHJlc3MsIHRoZSBob3N0IGNhbiBkZWR1Y2UgdGhhdCB0aGUgcGVlciBob3N0IGlzDQog ICBhbHNvIGluIHRoZSBJUHY0IG5hdGl2ZSBuZXR3b3JrLCBhbmQgaXQgaXMgdW5uZWNlc3Nhcnkg dG8gZm9yd2FyZA0KICAgZGF0YSB2aWEgdGhlIElQdjYgcmVsYXkgZ2F0ZXdheXMuICBUaGVzZSB0 d28gaG9zdHMgY2FuIGNvbW11bmljYXRlDQogICB3aXRoIGVhY2ggb3RoZXIgd2l0aCBkaXJlY3Qg NnRvNCB0dW5uZWwuDQoNCiAgIFRoZXJlIGFyZSB0d28gaXNzdWVzIHRoYXQgc2hvdWxkIGJlIHNv bHZlZCB0byByZWFsaXplIHRoZSBhYm92ZSBpZGVhOg0KICAgaG93IHRvIGtub3cgdGhhdCB0aGUg cGVlciBhbHNvIGhhcyA2dG80IGFkZHJlc3M7IGhvdyB0byBzd2l0Y2ggdG8NCiAgIGNvbW11bmlj YXRlIHdpdGggNnRvNCBhZGRyZXNzIHdpdGhvdXQgYnJlYWtpbmcgdGhlIG9uZ29pbmcgZGF0YQ0K ICAgdHJhbnNtaXNzaW9uLiAgVGhlc2UgdHdvIHByb2JsZW1zIGFyZSB2ZXJ5IGNvbW1vbiBmb3Ig dGhlIHJlc2VhcmNoIG9mDQogICBtdWx0aWhvbWluZy4gIEFuZCB0aGVyZSBhcmUgbWFueSBwb3Nz aWJsZSB3YXlzIHRvIHNvbHZlIHRoZXNlDQogICBwcm9ibGVtLiAgVGhlIGF1dGhvcnMganVzdCBo YXBwZW4gdG8ga25vdyB0aGUgcHJvZ3Jlc3MgaW4gc2hpbTYgV0csDQogICBhbmQgY29uc2lkZXIg dGhhdCBzb21lIHBhcnQgb2YgdGhlIGlkZWEgaW4gc2hpbTYgc29sdXRpb24gY2FuIGJlDQogICBh cHBsaWVkIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4NCg0KICAgSnVzdCBhcyBkZXNjcmliZWQgaW4g dGhlIHNoaW02IHNvbHV0aW9uLCB0aGUgY29tbXVuaWNhdGlvbiB3aWxsIHRha2UNCiAgIGluIHRo ZSBmb2xsb3dpbmcgc3RlcHM6DQoNCiAgIG8gIFdoZW4gYSBhIGhvc3QgaW4gSVB2NCBuYXRpdmUg bmV0d29yayBzdGFydHMgdG8gY29tbXVuaWNhdGUgd2l0aA0KICAgICAgYW5vdGhlciBob3N0IHdp dGggSVB2NiwgaXQgdXNlcyBQQSBhZGRyZXNzLg0KDQoNCg0KDQpaaGFuZywgZXQgYWwuICAgICAg ICAgICAgIEV4cGlyZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNl0NCgwN CkludGVybmV0LURyYWZ0ICAgIEFwcGx5IE11bHRpaG9taW5nIGluIElQdjYgVHJhbnNpdGlvbiAg ICAgIEphbnVhcnkgMjAwNg0KDQoNCiAgIG8gIFRoZW4gdGhlIGhvc3QgdHJpZXMgdG8gbmVnb3Rp YXRlIHdpdGggdGhlIHBlZXIgaG9zdCB0byBjb25maXJtIHRoZQ0KICAgICAgc3VwcG9ydCBmb3Ig c2hpbTYgbWVjaGFuaXNtIGFuZCB0byBleGNoYW5nZSB0aGUgbGlzdCBvZiBhdmFpbGFibGUNCiAg ICAgIGFkZHJlc3Nlcy4NCg0KICAgbyAgSWYgdGhlIHBlZXIgaG9zdCBjYW4gYWxzbyBzdXBwb3J0 IHNoaW02IG1lY2hhbmlzbSBhbmQgaXQgYWxzbyBvd25zDQogICAgICA2dG80IGFkZHJlc3MsIGJv dGggaG9zdHMgd2lsbCBzd2l0Y2ggdG8gY29tbXVuaWNhdGluZyB3aXRoIDZ0bzQNCiAgICAgIGFk ZHJlc3MuICBUaGUgc3dpdGNoaW5nIHByb2Nlc3MgaXMgdGhlIHNhbWUgdG8gdGhlIHNvbHV0aW9u IGluDQogICAgICBzaGltNi4NCg0KICAgQWZ0ZXIgdGhlc2Ugc3RlcHMsIHRoZSB0cmFmZmljIHdp bGwgbm90IHBhc3MgdGhyb3VnaCB0aGUgcmVsYXkNCiAgIGdhdGV3YXlzLiAgQXMgc2hvd24gaW4g RmlndXJlIDIsIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gSG9zdCBBIGFuZA0KICAgSG9zdCBC IGFuZCB0aGUgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIEhvc3QgQSBhbmQgSG9zdCBDIGlzIGRpcmVj dGx5DQogICBmb3J3YXJkZWQgd2l0aCA2dG80IHR1bm5lbHMuICBUaGUgYnVyZGVuIG9mIHRoZSBy ZWxheSBnYXRld2F5cyBhdCBJU1ANCiAgIEEgYW5kIElTUCBCIGlzIG1pdGlnYXRlZC4NCg0KICAg ICAgICAgICAgLC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLg0KICAgICAgICAg ICAsJyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGANCiAgICAgICAgICAvICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KICAgICAgICAgLyAgICstLS0r ICAgICAgICAgICAgICAgICAgICAgICstLS0rICAgICAgXA0KICAgICAgICA7ICAgIHwgQSB8PC4u Li4uLi4uLi4uLi4uLi4uLi4uPnwgQyB8ICAgICAgIDogICAgICAgICBJUHY0DQogICAgICAgIHwg ICAgKy0tLSsgPC4uLi4uLi4uLiAgICAgICAgICAgKy0tLSsgICAgICAgfCAgICAgICAgTmF0aXZl DQogICAgICAgIDogICAgIC98XCAgICAgICAgICBcOi8gICAgICAgICAgIC98XCAgICAgICAgOyAg ICAgICAgTmV0d29yaw0KICAgICAgICAgXCAgICAgfCAgICAgICAgICArLS0tKyAgICAgICAgICAg fCAgICAgICAgIC8NCiAgICAgICAgICBcICAgIHwgICAgICAgICAgfCBCIHwgICAgICAgICAgIHwg ICAgICAgIC8NCiAgICAgICAgICAgYC4gIC0tLXwgICAgICAgKy0tLSsgICAgICAgICAgIHwgICAg ICAgLCcNCiAgICAgICAgICAgICAnLS0tLXwtLS0tLS0tLS98XC0tLS0tLS0tLS0tLS0tLS0tLS0N CiAgICAgICAgICAgICAgICAgXHwvICAgICAgICB8ICAgICAgICAgICAgXHwvDQogICAgICAgICAg ICAgICAgKy0tLS0rICAgICAgfCAgICAgICAgICArLS0tLSsNCiAgICAgICAgICAgICAgICB8IEdX IHw8LS0tLS0gICAgICAgICAgIHwgR1cgfA0KICAgICAgICAgICAgLC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLg0KICAgICAgICAgICAsJyBcICBJU1AgQSAgLyAgICAgICAgICAg IFwgIElTUCBCICAvIGANCiAgICAgICAgICAvICAgIGAuICAgICAsJyAgICAgICAgICAgICAgYC4g ICAgICwnICAgXA0KICAgICAgICAgLyAgICAgICAnLS0tJyAgICAgICAgICAgICAgICAgICctLS0n ICAgICAgXA0KICAgICAgICA7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDogICAgICAgICBJUHY2DQogICAgICAgIHwgICAnICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgTmF0aXZlDQogICAgICAgIDogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgOyAgICAgICAgTmV0d29yaw0KICAgICAgICAgXCAg ICAgICAgICAgICAgICArLS0tKyAgICAgICAgICAgICAgICAgICAgLw0KICAgICAgICAgIFwgICAg ICAgICAgICAgICB8IEQgfCAgICAgICAgICAgICAgICAgICAvDQogICAgICAgICAgIGAuICAgICAg ICAgICAgICstLS0rICAgICAgICAgICAgICAgICAsJw0KICAgICAgICAgICAgICctLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgRmlndXJlIDI6IElQdjYgY29tbXVuaWNhdGlv biBiZXR3ZWVuIGhvc3RzIGluIElQdjQgbmF0aXZlIG5ldHdvcmsNCiAgIHdpdGggbXVsdGlob21p bmcgbWVjaGFuaXNtDQoNCg0KDQoNCg0KDQoNCg0KWmhhbmcsIGV0IGFsLiAgICAgICAgICAgICBF eHBpcmVzIEp1bHkgMTQsIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5l dC1EcmFmdCAgICBBcHBseSBNdWx0aWhvbWluZyBpbiBJUHY2IFRyYW5zaXRpb24gICAgICBKYW51 YXJ5IDIwMDYNCg0KDQo0LiAgT3RoZXIgSXNzdWVzDQoNCjQuMS4gIEdlbmVyYXRpb24gb2YgNnRv NCBBZGRyZXNzDQoNCiAgIEluIFNlY3Rpb24gMyB3ZSBhc3N1bWUgdGhhdCB0aGUgaG9zdCBpbiBJ UHY0IG5hdGl2ZSBuZXR3b3JrIGhhcyA2dG80DQogICBhZGRyZXNzLiAgVGhlIGhvc3QgY2FuIGdl dCB0aGUgNnRvNCBhZGRyZXNzIGluIHR3byBwb3NzaWJsZSB3YXlzOg0KDQogICBvICBJZiB0aGlz IGhvc3QgaGFzIGdsb2JhbCBJUHY0IGFkZHJlc3MsIGl0IGNhbiBkaXJlY3RseSBkZXJpdmUgNnRv NA0KICAgICAgYWRkcmVzcyBmcm9tIHRoZSBJUHY0IGFkZHJlc3MuDQoNCiAgIG8gIElmIHRoaXMg aG9zdCBpcyBiZWhpbmQgYSBOQVQgZ2F0ZXdheSBhbmQgaXQgb25seSBoYXMgYSBwcml2YXRlDQog ICAgICBJUHY0IGFkZHJlc3MsIHdlIGFzc3VtZSB0aGF0IHRoZXJlIGlzIGEgNnRvNCBnYXRld2F5 IHdoaWNoIGNhbg0KICAgICAgYWR2ZXJ0aXNlIDZ0bzQgcHJlZml4IGluIHRoZSBhZHZlcnRpc2Vt ZW50LiAgQWxzbywgdGhpcyBnYXRld2F5DQogICAgICBzaG91bGQgc3VwcG9ydCA2dG80IHR1bm5l bCB0byBvdGhlciBJUHY0IGhvc3QuDQoNCiAgIEluIGN1cnJlbnQgc3RhZ2UsIHdlIGRvbid0IGNv bnNpZGVyIHRoZSBzaXR1YXRpb24gdGhhdCBhIGhvc3QgaXMNCiAgIGJlaGluZCBhIE5BVCBnYXRl d2F5IGFuZCB0aGVyZSBpc24ndCBhbnkgNnRvNCByb3V0ZXJzLiAgV2Uga25vdyBpdCBpcw0KICAg YSB2ZXJ5IGltcG9ydGFudCBwcm9ibGVtIHRvIHNvbHZlLCBhbmQgd2Ugd2lsbCBpbnZlc3RpZ2F0 ZSBpdCBpbiB0aGUNCiAgIGZ1dHVyZS4gIFRlcmVkbyBbNV0gaXMgYSBnb29kIHJlZmVyZW5jZSBm b3IgdGhlIGZ1dHVyZSBpbnZlc3RpZ2F0aW9uDQogICBvbiB0aGlzIHRvcGljLg0KDQo0LjIuICBS ZWxhdGlvbiB3aXRoIHNoaW02IFByb3RvY29sDQoNCiAgIFRoaXMgcHJvcG9zYWwgYXBwbGllcyBz b21lIHNvbHV0aW9uIGRlZmluZWQgaW4gc2hpbTYuICBIb3dldmVyLCB0bw0KICAgcmVhbGl6ZSB0 aGlzIHByb3Bvc2FsLCBpdCBkb2VzIG5vdCByZXF1aXJlIHRoZSBmdWxsIGltcGxlbWVudGF0aW9u IG9mDQogICBzaGltNiBwcm90b2NvbC4gIE9ubHkgYSBzdWJzZXQgb2Ygc2hpbTYgbWVjaGFuaXNt IGlzIHJlcXVpcmVkLg0KDQogICBUd28gaW1wb3J0YW50IGFzc3VtcHRpb25zIGluIHRoaXMgcHJv YmxlbSB0aGF0IG1ha2UgaXQgZGlmZmVyZW50IGZyb20NCiAgIHRoZSBzaGltNiBwcm9ibGVtcyBh cmU6DQoNCiAgIG8gIFdlIGFzc3VtZSB0aGF0IHRoZSBob3N0IGNhbiByZWxpYWJseSBjb21tdW5p Y2F0ZSB3aXRoIGJvdGggUEEgSVB2Ng0KICAgICAgYWRkcmVzcyBhbmQgNnRvNCBhZGRyZXNzLiAg V2hpbGUgaW4gc2hpbTYsIGl0IGlzIGFzc3VtZWQgdGhhdCBzb21lDQogICAgICBhZGRyZXNzIG1h eSBiZSB1bnJlbGlhYmxlLg0KDQogICBvICBXZSBhc3N1bWUgdGhhdCByZWxheSBnYXRld2F5IGlz IHRoZSBib3R0bGVuZWNrLCBhbmQgNnRvNCBhZGRyZXNzDQogICAgICBpcyBwcmVmZXJyZWQgd2hl biB0aGUgcGVlciBob3N0IGFsc28gaGFzIDZ0bzQgYWRkcmVzcy4gIE1pdGlnYXRpbmcNCiAgICAg IHRoZSBidXJkZW4gb2YgcmVsYXkgZ2F0ZXdheSBpcyB0aGUgZ29hbCBvZiB0aGlzIHByb3Bvc2Fs LiAgV2hpbGUNCiAgICAgIGluIHNoaW02LCBpdCBjYW4ndCBtYWtlIHN1Y2ggZGV0ZXJtaW5pc3Rp YyBkZWNpc2lvbi4NCg0KICAgU28gdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoaXMgcHJvcG9zYWwg Y2FuIGJlIG11Y2ggc2ltcGxlciB0aGFuIGZ1bGwNCiAgIHNoaW02IHByb3RvY29sLiAgRmlyc3Qs IGFmdGVyIGdldHRpbmcgdGhlIHBlZXIgSVB2NiBhZGRyZXNzIGxpc3QsIGl0DQogICBpcyBlYXN5 IHRvIGRlY2lkZSB3aGV0aGVyIHRvIG1ha2UgYSBzd2l0Y2hpbmcuICBTZWNvbmQsIGFmdGVyDQog ICBzd2l0Y2hpbmcgdG8gNnRvNCBhZGRyZXNzLCBpdCBpcyBub3QgcmVxdWlyZWQgdG8gdGVzdCB0 aGUNCiAgIHJlYWNoYWJpbGl0eSBvZiA2dG80IGFkZHJlc3MgcGVyaW9kaWNseS4NCg0KICAgU2lu Y2UgdGhlcmUgaXMgbm8gc2hpbTYgcHJvdG90eXBlIGF2YWlsYWJsZSBhdCBjdXJyZW50IHRpbWUs IHdlIHBsYW4NCiAgIHRvIGltcGxlbWVudCBhIHN1YnNldCBvZiBzaGltNiBwcm90b2NvbCB3aGlj aCBjYW4gc3VwcG9ydCB0aGUNCiAgIGZ1bmN0aW9uIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBp biB0aGUgbmVhciBmdXR1cmUuDQoNCg0KDQpaaGFuZywgZXQgYWwuICAgICAgICAgICAgIEV4cGly ZXMgSnVseSAxNCwgMjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgOF0NCgwNCkludGVybmV0LURy YWZ0ICAgIEFwcGx5IE11bHRpaG9taW5nIGluIElQdjYgVHJhbnNpdGlvbiAgICAgIEphbnVhcnkg MjAwNg0KDQoNCjUuICBCZW5lZml0IEFuYWx5c2lzDQoNCiAgIFRoZSBiZWF1dHkgb2YgdGhpcyBw cm9wb3NhbCBtYWlubHkgc2hvd3MgYXQgdHdvIGFzcGVjdHM6IGZpcnN0LCBpdA0KICAgcHJvdmlk ZXMgZW5vdWdoIGluY2VudGl2ZSBmb3IgdGhlIGRlcGxveW1lbnQ7IHNlY29uZCwgaXQgY2FuIGJl DQogICBpbmNyZW1lbnRhbGx5IGRlcGxveWVkLg0KDQo1LjEuICBJbmNlbnRpdmUgZm9yIERlcGxv eW1lbnQNCg0KICAgVGhlIHByb3Bvc2FsIHdpbGwgYmVuZWZpdCB0aHJlZSBwYXJ0aWVzIGludm9s dmVkIGluIElQdjYgbmV0d29yazogdGhlDQogICBlbmQgdXNlcnMsIHRoZSBJU1Agb2YgSVB2NiBh Y2Nlc3Mgc2VydmljZSwgdGhlIElTUCBvZiBJUHY2DQogICBhcHBsaWNhdGlvbjoNCg0KICAgbyAg Rm9yIHRoZSBlbmQgdXNlcnMuICBXaXRoIGRpcmVjdGx5IGNvbm5lY3RlZCA2dG80IHR1bm5lbHMs IGl0IGlzDQogICAgICBleHBlY3RlZCB0aGF0IHVzZXJzIHdpbGwgZ2V0IGJldHRlciBleHBlcmll bmNlIGluIG1vc3QgY2FzZXMuICBUaGUNCiAgICAgIGluY2VudGl2ZSB0byB0aGUgZW5kIHVzZXJz IGlzIHRoZSBtb3N0IGltcG9ydGFudCwgc2luY2UgdGhlDQogICAgICBtb2RpZmljYXRpb24gaXMg bWFkZSBhdCB0aGUgaG9zdC4NCg0KICAgbyAgRm9yIHRoZSBJU1Agb2YgSVB2NiBhY2Nlc3Mgc2Vy dmljZS4gIFRoaXMgcHJvcG9zYWwgY2FuIGRlY3JlYXNlDQogICAgICB0aGUgY29zdCBvZiB0aGUg SVNQLCBib3RoIGF0IGJ1eWluZyB0aGUgYmFuZHdpZHRoIGFuZCBhdCBidXlpbmcNCiAgICAgIGhp Z2ggcGVyZm9ybWFuY2UgcmVsYXkgZ2F0ZXdheXMuICBJdCBpcyBleHBlY3RlZCB0aGF0IElTUHMg d2lsbA0KICAgICAgZW5jb3VyYWdlIHRoZWlyIGN1c3RvbWVycyB0byBkZXBsb3kgdGhpcyBzb2x1 dGlvbiBvbiB0aGVpciBob3N0cy4NCg0KICAgbyAgRm9yIHRoZSBJU1Agb2YgSVB2NiBhcHBsaWNh dGlvbi4gIFNpbmNlIHRoZSBjb3N0IG9mIHByb3ZpZGluZyBJUHY2DQogICAgICBhY2Nlc3Mgc2Vy dmljZSBpcyBkZWNyZWFzZWQsIGl0IHdpbGwgZW5jb3VyYWdlIG1vcmUgdXNlcnMgdG8NCiAgICAg IGFjY2VzcyBJUHY2IG5ldHdvcmsgYW5kIHVzZSBJUHY2IGFwcGxpY2F0aW9ucy4NCg0KNS4yLiAg SW5jcmVtZW50YWwgRGVwbG95bWVudA0KDQogICBUaGUgcHJvcGVydHkgb2YgaW5jcmVtZW50YWwg ZGVwbG95bWVudCBpcyBpbmhlcml0ZWQgZnJvbSBzaGltNi4NCiAgIEZpcnN0LCBhcyBpdCBpcyBh biBlbmQtdG8tZW5kIHNvbHV0aW9uLCBpdCBkb2VzIG5vdCByZXF1aXJlIGFueQ0KICAgbW9kaWZp Y2F0aW9uIGF0IHRoZSByZWxheSBnYXRld2F5cy4gIFNlY29uZCwgaXQgaXMgYW4gImFkZC1vbiIN CiAgIGZlYXR1cmUgZm9yIHRoZSBob3N0LiAgSWYgZWl0aGVyIG9mIHRoZSBob3N0cyBkb2Vzbid0 IHN1cHBvcnQgdGhpcw0KICAgZnVuY3Rpb24sIHRoZXkgY2FuIHN0aWxsIGNvbW11bmljYXRlIHdp dGggUEEgSVB2NiBhZGRyZXNzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K WmhhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTQsIDIwMDYgICAgICAgICAg ICAgICAgIFtQYWdlIDldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICBBcHBseSBNdWx0aWhvbWluZyBp biBJUHY2IFRyYW5zaXRpb24gICAgICBKYW51YXJ5IDIwMDYNCg0KDQo2LiAgUmVmZXJlbmNlcw0K DQogICBbMV0gIER1cmFuZCwgQS4sIEZhc2FubywgUC4sIEd1YXJkaW5pLCBJLiwgYW5kIEQuIExl bnRvLCAiSVB2NiBUdW5uZWwNCiAgICAgICAgQnJva2VyIiwgUkZDIDMwNTMsIEphbnVhcnkgMjAw MS4NCg0KICAgWzJdICBDYXJwZW50ZXIsIEIuIGFuZCBLLiBNb29yZSwgIkNvbm5lY3Rpb24gb2Yg SVB2NiBEb21haW5zIHZpYSBJUHY0DQogICAgICAgIENsb3VkcyIsIFJGQyAzMDU2LCBGZWJydWFy eSAyMDAxLg0KDQogICBbM10gIFNoaW02IFdvcmtpbmcgR3JvdXAsICJTaXRlIE11bHRpaG9taW5n IGJ5IElQdjYgSW50ZXJtZWRpYXRpb24NCiAgICAgICAgKHNoaW02KSIsIElFVEYgV29ya2luZyBH cm91cCwNCiAgICAgICAgPGh0dHA6Ly93d3cuaWV0Zi5vcmcvaHRtbC5jaGFydGVycy9zaGltNi1j aGFydGVyLmh0bWw+Lg0KDQogICBbNF0gIFNhdm9sYSwgUC4gYW5kIEMuIFBhdGVsLCAiU2VjdXJp dHkgQ29uc2lkZXJhdGlvbnMgZm9yIDZ0bzQiLA0KICAgICAgICBSRkMgMzk2NCwgRGVjZW1iZXIg MjAwNC4NCg0KICAgWzVdICBIdWl0ZW1hLCBDLiwgIlRlcmVkbzogVHVubmVsaW5nIElQdjYgb3Zl ciBVRFAgdGhyb3VnaCBOQVRzIiwNCiAgICAgICAgZHJhZnQtaHVpdGVtYS12Nm9wcy10ZXJlZG8t MDUudHh0ICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAgQXByaWwgMjAwNS4NCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN ClpoYW5nLCBldCBhbC4gICAgICAgICAgICAgRXhwaXJlcyBKdWx5IDE0LCAyMDA2ICAgICAgICAg ICAgICAgIFtQYWdlIDEwXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgQXBwbHkgTXVsdGlob21pbmcg aW4gSVB2NiBUcmFuc2l0aW9uICAgICAgSmFudWFyeSAyMDA2DQoNCg0KQXBwZW5kaXggQS4gIEFj a25vd2xlZGdlbWVudHMNCg0KICAgVGhlIGF1dGhvcnMgZ3JhdGVmdWxseSBhY2tub3dsZWRnZSB0 aGUgY29tbWVudHMgZnJvbSBFcmljIE5vcmRtYXJrDQogICBhbmQgVG9ueSBIYWluLg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClpoYW5nLCBldCBhbC4gICAgICAgICAgICAg RXhwaXJlcyBKdWx5IDE0LCAyMDA2ICAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgQXBwbHkgTXVsdGlob21pbmcgaW4gSVB2NiBUcmFuc2l0aW9uICAgICAgSmFu dWFyeSAyMDA2DQoNCg0KQXV0aG9ycycgQWRkcmVzc2VzDQoNCiAgIE1pYW8gWmhhbmcNCiAgIFRz aW5naHVhIFVuaXZlcnNpdHkNCiAgIE5ldHdvcmsgUmVzZWFyY2ggQ2VudGVyLCBUc2luZ2h1YSBV bml2ZXJzaXR5DQogICBCZWlqaW5nICAxMDAwODQNCiAgIFAuUi5DaGluYQ0KDQogICBFbWFpbDog em1AY2VybmV0LmVkdS5jbg0KDQoNCiAgIEp1biBCaQ0KICAgVHNpbmdodWEgVW5pdmVyc2l0eQ0K ICAgTmV0d29yayBSZXNlYXJjaCBDZW50ZXIsIFRzaW5naHVhIFVuaXZlcnNpdHkNCiAgIEJlaWpp bmcgIDEwMDA4NA0KICAgUC5SLkNoaW5hDQoNCiAgIEVtYWlsOiBqdW5iaUBjZXJuZXQuZWR1LmNu DQoNCg0KICAgSmlhbnBpbmcgV3UNCiAgIFRzaW5naHVhIFVuaXZlcnNpdHkNCiAgIE5ldHdvcmsg UmVzZWFyY2ggQ2VudGVyLCBUc2luZ2h1YSBVbml2ZXJzaXR5DQogICBCZWlqaW5nICAxMDAwODQN CiAgIFAuUi5DaGluYQ0KDQogICBFbWFpbDogamlhbnBpbmdAY2VybmV0LmVkdS5jbg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KWmhhbmcsIGV0IGFsLiAg ICAgICAgICAgICBFeHBpcmVzIEp1bHkgMTQsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTJd DQoMDQpJbnRlcm5ldC1EcmFmdCAgICBBcHBseSBNdWx0aWhvbWluZyBpbiBJUHY2IFRyYW5zaXRp b24gICAgICBKYW51YXJ5IDIwMDYNCg0KDQpGdWxsIENvcHlyaWdodCBTdGF0ZW1lbnQNCg0KICAg Q29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuDQoNCiAgIFRoaXMgZG9j dW1lbnQgaXMgc3ViamVjdCB0byB0aGUgcmlnaHRzLCBsaWNlbnNlcyBhbmQgcmVzdHJpY3Rpb25z DQogICBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQgZXhjZXB0IGFzIHNldCBmb3J0aCB0aGVyZWlu LCB0aGUgYXV0aG9ycw0KICAgcmV0YWluIGFsbCB0aGVpciByaWdodHMuDQoNCiAgIFRoaXMgZG9j dW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGFyZSBwcm92aWRlZCBv biBhbg0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFU SU9OIEhFL1NIRSBSRVBSRVNFTlRTDQogICBPUiBJUyBTUE9OU09SRUQgQlkgKElGIEFOWSksIFRI RSBJTlRFUk5FVCBTT0NJRVRZIEFORCBUSEUgSU5URVJORVQNCiAgIEVOR0lORUVSSU5HIFRBU0sg Rk9SQ0UgRElTQ0xBSU0gQUxMIFdBUlJBTlRJRVMsIEVYUFJFU1MgT1IgSU1QTElFRCwNCiAgIElO Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiBU SEUNCiAgIElORk9STUFUSU9OIEhFUkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9S IEFOWSBJTVBMSUVEDQogICBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBPUiBGSVRORVNT IEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRS4NCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkNCg0K ICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBz Y29wZSBvZiBhbnkNCiAgIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmln aHRzIHRoYXQgbWlnaHQgYmUgY2xhaW1lZCB0bw0KICAgcGVydGFpbiB0byB0aGUgaW1wbGVtZW50 YXRpb24gb3IgdXNlIG9mIHRoZSB0ZWNobm9sb2d5IGRlc2NyaWJlZCBpbg0KICAgdGhpcyBkb2N1 bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2ggcmlnaHRz DQogICBtaWdodCBvciBtaWdodCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNl bnQgdGhhdCBpdCBoYXMNCiAgIG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlm eSBhbnkgc3VjaCByaWdodHMuICBJbmZvcm1hdGlvbg0KICAgb24gdGhlIHByb2NlZHVyZXMgd2l0 aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1lbnRzIGNhbiBiZQ0KICAgZm91bmQgaW4g QkNQIDc4IGFuZCBCQ1AgNzkuDQoNCiAgIENvcGllcyBvZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0 byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55DQogICBhc3N1cmFuY2VzIG9mIGxpY2Vuc2Vz IHRvIGJlIG1hZGUgYXZhaWxhYmxlLCBvciB0aGUgcmVzdWx0IG9mIGFuDQogICBhdHRlbXB0IG1h ZGUgdG8gb2J0YWluIGEgZ2VuZXJhbCBsaWNlbnNlIG9yIHBlcm1pc3Npb24gZm9yIHRoZSB1c2Ug b2YNCiAgIHN1Y2ggcHJvcHJpZXRhcnkgcmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBv ZiB0aGlzDQogICBzcGVjaWZpY2F0aW9uIGNhbiBiZSBvYnRhaW5lZCBmcm9tIHRoZSBJRVRGIG9u LWxpbmUgSVBSIHJlcG9zaXRvcnkgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaXByLg0KDQog ICBUaGUgSUVURiBpbnZpdGVzIGFueSBpbnRlcmVzdGVkIHBhcnR5IHRvIGJyaW5nIHRvIGl0cyBh dHRlbnRpb24gYW55DQogICBjb3B5cmlnaHRzLCBwYXRlbnRzIG9yIHBhdGVudCBhcHBsaWNhdGlv bnMsIG9yIG90aGVyIHByb3ByaWV0YXJ5DQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5v bG9neSB0aGF0IG1heSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQNCiAgIHRoaXMgc3RhbmRhcmQu ICBQbGVhc2UgYWRkcmVzcyB0aGUgaW5mb3JtYXRpb24gdG8gdGhlIElFVEYgYXQNCiAgIGlldGYt aXByQGlldGYub3JnLg0KDQoNCkFja25vd2xlZGdtZW50DQoNCiAgIEZ1bmRpbmcgZm9yIHRoZSBS RkMgRWRpdG9yIGZ1bmN0aW9uIGlzIGN1cnJlbnRseSBwcm92aWRlZCBieSB0aGUNCiAgIEludGVy bmV0IFNvY2lldHkuDQoNCg0KDQoNCg0KWmhhbmcsIGV0IGFsLiAgICAgICAgICAgICBFeHBpcmVz IEp1bHkgMTQsIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgMTNdDQoMDQo= --=====001_Dragon115312350104_=====-- From owner-v6ops@ops.ietf.org Tue Jan 10 04:46:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwG4w-0002lT-60 for v6ops-archive@megatron.ietf.org; Tue, 10 Jan 2006 04:46:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18205 for ; Tue, 10 Jan 2006 04:44:51 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwG2c-000L8n-Hu for v6ops-data@psg.com; Tue, 10 Jan 2006 09:43:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.154] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EwG2a-000L8C-3i for v6ops@ops.ietf.org; Tue, 10 Jan 2006 09:43:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message Subject: RE: Tiny fragments and IPv6 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Jan 2006 01:43:40 -0800 Message-ID: Thread-Topic: Tiny fragments and IPv6 Thread-Index: AcX1GZD/Q9O2jtN3SKqqslmAp46ufggsDKqA From: "Vishwas Manral" To: "Fred Baker" , "Margaret Wasserman" Cc: Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Margaret/ Fred, I have updated the draft based on private comments as well as comments on the list. http://www.ietf.org/internet-drafts/draft-manral-v6ops-tiny-fragments-is sues-02.txt The people making comments have been duly acknowledged in the relevant section. Any other comments from the list would be a lot of help. Thanks, Vishwas -----Original Message----- From: Fred Baker [mailto:fred@cisco.com]=20 Sent: Wednesday, November 30, 2005 12:48 AM To: Margaret Wasserman Cc: v6ops@ops.ietf.org; Vishwas Manral Subject: Re: Tiny fragments and IPv6 It does happen in IPv4. Vishwas' concern is that the attack that =20 happens in IPv4 might happen in IPv6, and is wondering whether there =20 are best practices that we can discuss to minimize the impact. On Nov 29, 2005, at 1:13 PM, Margaret Wasserman wrote: > Why is this an IPv6-specific problem? Is there a reason why the =20 > same type > of attack does not work in IPv4? From zhaonancyw@elong.com Tue Jan 10 11:44:08 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwMbQ-0003L7-4w for v6ops-archive@megatron.ietf.org; Tue, 10 Jan 2006 11:44:08 -0500 Received: from 160-dz2-8.acn.waw.pl (160-dz2-8.acn.waw.pl [82.210.159.160]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20010 for ; Tue, 10 Jan 2006 11:42:44 -0500 (EST) Received: (longue 6994 invoked from network); Tue, 10 Jan 2006 06:59:09 -0500 MIME-Version: 1.0 Message-Id: <638385599269073317934581.18213@microsoft.com> X-Originating-Ip: [46.132.244.160] Subject: Amazing, Samantha From: Tyler Maynard X-Mailer: rightward 3.414.52578 Date: Tue, 10 Jan 2006 11:19:14 -0500 To: v6ops-archive@ietf.org X-Confirm-Reading-To: hsm@epost.de Disposition-Notification-To: beverlyf@delphi.com Content-Type: multipart/mixed; boundary="------=49991062689884" Content-Transfer-Encoding: quoted-printable --------=49991062689884 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


No one will do it for you.
Spinoza Experience keeps a dear school, but fools will learn in no other.The people who are absent are the ideal those who are present seem to be quite commonplace. --------=49991062689884 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Lorenzo-> http://uwqalg.honchor.info/?rkfuguxwpqqydqhrinzpoipfltm --------=49991062689884-- From wcdi@homestead.com Wed Jan 11 07:55:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EwfW0-0005gO-MI for v6ops-archive@megatron.ietf.org; Wed, 11 Jan 2006 07:55:48 -0500 Received: from tal21-1-82-225-175-19.fbx.proxad.net (tal21-1-82-225-175-19.fbx.proxad.net [82.225.175.19]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09055 for ; Wed, 11 Jan 2006 07:54:27 -0500 (EST) Received: from endothelial (entrepreneur user inexpressible@microsoft.com) by microsoft.com (fluoridate.deprecatory.nudge.4.3.2) with twinkle id 70-02.aiken; Wed, 11 Jan 2006 03:56:15 -0500 Message-ID: <9426159@guardian> From: Stacey Cunningham To: v6ops-archive@ietf.org Subject: Amazing, Colin Date: Wed, 11 Jan 2006 05:16:13 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 56964142.26605224.46905716.579135 X-MimeOLE: Produced By Microsoft MimeOLE 8314.12103231.67980.573537 Content-Type: multipart/mixed; boundary="------=34236388122" Content-Transfer-Encoding: quoted-printable --------=34236388122 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


An ugly sight, a man who is afraid.Inner work is finding joy in work. Our real work is heart work and soul work.
The battle for women's rights has been largely won.There are no mistakes or failures, only lessons. --------=34236388122 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Jackie-> http://elnaun.sweetpeper.info/?uptmefxwpqqyahkrcszpovbuevt --------=34236388122-- From ssxe@f.com.cnri.reston.va.us Sun Jan 15 15:28:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyETy-0001cx-Jp for v6ops-archive@megatron.ietf.org; Sun, 15 Jan 2006 15:28:10 -0500 Received: from host-81-190-38-222.szczecin.mm.pl (host-81-190-38-222.szczecin.mm.pl [81.190.38.222]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12968 for ; Sun, 15 Jan 2006 15:26:44 -0500 (EST) Received: (carpentry 44451 invoked from network); Sun, 15 Jan 2006 10:44:39 -0500 Message-ID: <57057287252.invincible-throw-evocable@microsoft.com> From: Marvin Dooley To: v6ops-archive@ietf.org References: <6279484690340.1041258298349@f.com> Subject: Amazing, Merlin Date: Sun, 15 Jan 2006 11:12:18 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------=786094768309" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: scab 74.013.1545560 X-MimeOLE: staccato 60.072.3664 Content-Transfer-Encoding: 7bit --------=786094768309 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


We have to talk about liberating minds as well as liberating society.It is not flesh and blood, but heart which makes us fathers and sons.
The five steps in teaching an employee new skills are preparation, explanation, showing, observation and supervision.The novice in advertising frequently gives the public credit, for too much intelligence. --------=786094768309 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Lamar-> http://pgvojs.idealbride.info/?tqbkslxwpqqyjsewnlzpotafdat --------=786094768309-- From tigger@csionline.net Mon Jan 16 18:34:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eydrn-0002Ao-0o for v6ops-archive@megatron.ietf.org; Mon, 16 Jan 2006 18:34:27 -0500 Received: from p5485D036.dip.t-dialin.net (p5485D036.dip.t-dialin.net [84.133.208.54]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25127 for ; Mon, 16 Jan 2006 18:33:01 -0500 (EST) Received: from mail by microsoft.com with local id 50-5-06; Mon, 16 Jan 2006 16:51:01 -0500 From: Bettye Billings To: v6ops-archive@ietf.org Subject: Amazing, Darin Mime-Version: 1.0 X-Mailer: dehumidify Web-Mail 2.19 X-Originating-IP: 62.118.145.163 via proxy [122.154.68.238] Date: Mon, 16 Jan 2006 17:10:16 -0500 Reply-To: Ila Palacios Message-Id: <32774-2449439-8449.condemn-ye-offend@csionline.net> Content-Type: multipart/mixed; boundary="------=3770498037828" Content-Transfer-Encoding: 8bit --------=3770498037828 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


If we could sell our experience for what they cost us, we'd all be millionaires.I look upon every day to be lost, in which I do not make a new acquaintance.
Life does not require us to make good it asks only that we give our best at each level of experience.Berlioz says nothing in his music, but he says it magnificently.Honor is like an island, rugged and without a beach once we have left it, we can never return. --------=3770498037828 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Derick-> http://oguogk.lojb.info/?hdhhjpxwpqqybpbjrgzpojiwlfw --------=3770498037828-- From owner-v6ops@ops.ietf.org Mon Jan 16 19:45:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyeyy-00042O-02 for v6ops-archive@megatron.ietf.org; Mon, 16 Jan 2006 19:45:56 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29413 for ; Mon, 16 Jan 2006 19:44:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyevI-000C16-ID for v6ops-data@psg.com; Tue, 17 Jan 2006 00:42:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.19] (helo=MMS3.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyevH-000C0t-Jd for v6ops@ops.ietf.org; Tue, 17 Jan 2006 00:42:07 +0000 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 16 Jan 2006 16:41:56 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 10CA867422; Mon, 16 Jan 2006 16:41:55 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id B226F67420 for ; Mon, 16 Jan 2006 16:41:55 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSG66416; Mon, 16 Jan 2006 16:41:54 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 19B0E20501 for ; Mon, 16 Jan 2006 16:41:54 -0800 ( PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Flow label and its uses Date: Mon, 16 Jan 2006 16:41:53 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B363069EF@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYa/s95586xkLNiQsC4/8WkFKq3ug== From: "Bora Akyol" To: v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011607; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34334343334333302E303032392D412D; ENG=IBF; TS=20060117004158; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011607_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD2E2DE41W1578349-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I am looking at pointers on how commonspread the usage of the "Flow Label" field is in IPv6 (specifically end-node operating systems). Any help would be appreciated, Regards, Bora From owner-v6ops@ops.ietf.org Mon Jan 16 23:52:31 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyipa-0005jP-V4 for v6ops-archive@megatron.ietf.org; Mon, 16 Jan 2006 23:52:31 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15029 for ; Mon, 16 Jan 2006 23:51:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyimJ-0000ni-CL for v6ops-data@psg.com; Tue, 17 Jan 2006 04:49:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.158] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyimI-0000nT-JU for v6ops@ops.ietf.org; Tue, 17 Jan 2006 04:49:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Mon, 16 Jan 2006 20:49:04 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYa/s95586xkLNiQsC4/8WkFKq3ugAIbObQ From: "Vishwas Manral" To: "Bora Akyol" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Bora, From my reading of documents the Flow Label is not very often used. You can check the implementation report (fairly dated) http://www.ietf.org/IESG/Implementations/ipv6-implementations.txt And a more recent draft http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty-bcc-flowla bel-00.txt Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Bora Akyol Sent: Tuesday, January 17, 2006 6:12 AM To: v6ops@ops.ietf.org Subject: Flow label and its uses I am looking at pointers on how commonspread the usage of the "Flow Label" field is in IPv6 (specifically end-node operating systems). Any help would be appreciated, Regards, Bora From owner-v6ops@ops.ietf.org Tue Jan 17 03:25:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EymA1-0000P4-OI for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 03:25:50 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26325 for ; Tue, 17 Jan 2006 03:24:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eym4D-0002AI-Qu for v6ops-data@psg.com; Tue, 17 Jan 2006 08:19:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [193.247.251.10] (helo=viola.thenet.ch) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eym4C-0002A4-Ah for v6ops@ops.ietf.org; Tue, 17 Jan 2006 08:19:48 +0000 Received: (qmail 18167 invoked from network); 17 Jan 2006 08:19:45 -0000 Received: from laurana.thenet.ch (HELO Sathya) (rao@telscom.ch@193.247.120.3) by viola.thenet.ch with SMTP; 17 Jan 2006 08:19:45 -0000 Message-ID: <005201c61b3e$c0fd8400$8613a8c0@Sathya> From: "Sathya Rao" To: "Bora Akyol" , References: <03235919BBDE634289BB6A0758A20B363069EF@NT-SJCA-0751.brcm.ad.broadcom.com> Subject: Re: Flow label and its uses Date: Tue, 17 Jan 2006 09:19:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You are right. Though some discussions were held on IPv6 flowlabel few years back, there is no real implementation. We did some implementation work and demonstrated the use of flow label to improve QoS. But we did not get much support to our work. May be time to take up again. Cheers Sathya ----- Original Message ----- From: "Bora Akyol" To: Sent: Tuesday, January 17, 2006 1:41 AM Subject: Flow label and its uses I am looking at pointers on how commonspread the usage of the "Flow Label" field is in IPv6 (specifically end-node operating systems). Any help would be appreciated, Regards, Bora From owner-v6ops@ops.ietf.org Tue Jan 17 05:40:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyoGL-00013F-Ds for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 05:40:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03742 for ; Tue, 17 Jan 2006 05:39:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyoEJ-000AZb-BL for v6ops-data@psg.com; Tue, 17 Jan 2006 10:38:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [134.226.81.11] (helo=salmon.maths.tcd.ie) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyoEH-000AZJ-Pe for v6ops@ops.ietf.org; Tue, 17 Jan 2006 10:38:22 +0000 Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 17 Jan 2006 10:38:19 +0000 (GMT) Date: Tue, 17 Jan 2006 10:38:18 +0000 From: David Malone To: Bora Akyol Cc: v6ops@ops.ietf.org Subject: Re: Flow label and its uses Message-ID: <20060117103818.GA15939@walton.maths.tcd.ie> References: <03235919BBDE634289BB6A0758A20B363069EF@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03235919BBDE634289BB6A0758A20B363069EF@NT-SJCA-0751.brcm.ad.broadcom.com> User-Agent: Mutt/1.5.6i Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Jan 16, 2006 at 04:41:53PM -0800, Bora Akyol wrote: > I am looking at pointers on how commonspread the usage of the "Flow > Label" field is in IPv6 (specifically end-node operating systems). Orla McGann did some measurements of this in her thesis: http://www.redbrick.dcu.ie/~orly/thesis.pdf Section 5.2.4 (page 101 of the PDF, numbered 91) has some live measurements of how many hosts were setting the flow label and some fingerprinting to determine what OS they were running. David. From owner-v6ops@ops.ietf.org Tue Jan 17 10:47:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eyt3P-0004mL-VH for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 10:47:28 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25648 for ; Tue, 17 Jan 2006 10:46:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eyt0d-0004ng-Vb for v6ops-data@psg.com; Tue, 17 Jan 2006 15:44:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eyt0c-0004nL-E4 for v6ops@ops.ietf.org; Tue, 17 Jan 2006 15:44:34 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id k0HFhuOl095304 for ; Tue, 17 Jan 2006 15:44:00 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0HFhYqp100260 for ; Tue, 17 Jan 2006 16:43:35 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id k0HFhY5i016637 for ; Tue, 17 Jan 2006 16:43:34 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id k0HFhXES016622; Tue, 17 Jan 2006 16:43:33 +0100 Received: from zurich.ibm.com (sig-9-146-222-32.de.ibm.com [9.146.222.32]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA57650; Tue, 17 Jan 2006 16:43:32 +0100 Message-ID: <43CD10A4.9090301@zurich.ibm.com> Date: Tue, 17 Jan 2006 16:43:32 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: David Malone CC: Bora Akyol , v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: <03235919BBDE634289BB6A0758A20B363069EF@NT-SJCA-0751.brcm.ad.broadcom.com> <20060117103818.GA15939@walton.maths.tcd.ie> In-Reply-To: <20060117103818.GA15939@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I've been a little disappointed not to see multiple drafts proposing use cases within the rules set by RFC 3697. That document was intended to set the baseline for flow label based classifiers, but use cases are needed too. Brian David Malone wrote: > On Mon, Jan 16, 2006 at 04:41:53PM -0800, Bora Akyol wrote: > >>I am looking at pointers on how commonspread the usage of the "Flow >>Label" field is in IPv6 (specifically end-node operating systems). > > > Orla McGann did some measurements of this in her thesis: > > http://www.redbrick.dcu.ie/~orly/thesis.pdf > > Section 5.2.4 (page 101 of the PDF, numbered 91) has some live > measurements of how many hosts were setting the flow label and some > fingerprinting to determine what OS they were running. > > David. > From owner-v6ops@ops.ietf.org Tue Jan 17 12:49:27 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyuxQ-0005yl-Mu for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 12:49:27 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04406 for ; Tue, 17 Jan 2006 12:47:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyuvG-000EP2-A7 for v6ops-data@psg.com; Tue, 17 Jan 2006 17:47:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.17] (helo=mms1.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyuvF-000EOq-6L for v6ops@ops.ietf.org; Tue, 17 Jan 2006 17:47:09 +0000 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 17 Jan 2006 09:46:58 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 9234667421; Tue, 17 Jan 2006 09:46:58 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 45C6667420; Tue, 17 Jan 2006 09:46:58 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSJ77931; Tue, 17 Jan 2006 09:46:45 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 7CAD120501; Tue, 17 Jan 2006 09:46:45 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Tue, 17 Jan 2006 09:46:44 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306AA7@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYbfN5wp5Byy8GOT6agXsb3S7sOpwAEMUuw From: "Bora Akyol" To: "Brian E Carpenter" cc: v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011706; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230332E34334344324336372E303031452D412D; ENG=IBF; TS=20060117174659; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011706_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD3F21810G1712650-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Thanks Brian, If this field is indeed not commonly used (presumably due to lack of an API to take an advantage of it in end point OSs), is it worth it to define it as "Reserved." I don't want to raise a controversial issue here, but this 'wild card' field presents some challenges in implementation of v6 support without well understood applications. Regards, Bora =20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Tuesday, January 17, 2006 7:44 AM > To: David Malone > Cc: Bora Akyol; v6ops@ops.ietf.org > Subject: Re: Flow label and its uses >=20 > I've been a little disappointed not to see multiple drafts=20 > proposing use cases within the rules set by RFC 3697. That=20 > document was intended to set the baseline for flow label=20 > based classifiers, but use cases are needed too. >=20 > Brian >=20 > David Malone wrote: > > On Mon, Jan 16, 2006 at 04:41:53PM -0800, Bora Akyol wrote: > >=20 > >>I am looking at pointers on how commonspread the usage of the "Flow=20 > >>Label" field is in IPv6 (specifically end-node operating systems). > >=20 > >=20 > > Orla McGann did some measurements of this in her thesis: > >=20 > > http://www.redbrick.dcu.ie/~orly/thesis.pdf > >=20 > > Section 5.2.4 (page 101 of the PDF, numbered 91) has some live=20 > > measurements of how many hosts were setting the flow label and some=20 > > fingerprinting to determine what OS they were running. > >=20 > > David. > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jan 17 15:53:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyxpV-0002XL-T4 for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 15:53:25 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17008 for ; Tue, 17 Jan 2006 15:51:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyxmG-00034Q-02 for v6ops-data@psg.com; Tue, 17 Jan 2006 20:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EyxmF-00033p-46 for v6ops@ops.ietf.org; Tue, 17 Jan 2006 20:50:03 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EyxmD-0008DL-HY; Tue, 17 Jan 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-onlinkassumption-04.txt Message-Id: Date: Tue, 17 Jan 2006 15:50:01 -0500 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : IPv6 Neighbor Discovery On-Link Assumption Considered Harmful Author(s) : S. Roy, et al. Filename : draft-ietf-v6ops-onlinkassumption-04.txt Pages : 11 Date : 2006-1-17 This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems, and describes how these problems outweigh the benefits of this part of the conceptual sending algorithm. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-onlinkassumption-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-v6ops-onlinkassumption-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-v6ops-onlinkassumption-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. --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: <2006-1-17113506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-onlinkassumption-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-onlinkassumption-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-1-17113506.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Tue Jan 17 18:14:29 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez021-0001Fr-Fm for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 18:14:29 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04023 for ; Tue, 17 Jan 2006 18:13:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eyzzg-000EiQ-Ul for v6ops-data@psg.com; Tue, 17 Jan 2006 23:12:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.17] (helo=mms1.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Eyzzf-000EiD-G5 for v6ops@ops.ietf.org; Tue, 17 Jan 2006 23:12:04 +0000 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 17 Jan 2006 15:11:52 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id BB94167424; Tue, 17 Jan 2006 15:11:51 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2D5FD67421; Tue, 17 Jan 2006 15:11:51 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSL10206; Tue, 17 Jan 2006 15:11:50 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 16CA720501; Tue, 17 Jan 2006 15:11:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Tue, 17 Jan 2006 15:11:51 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306B62@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYa/s95586xkLNiQsC4/8WkFKq3ugAIbObQACa0ivA= From: "Bora Akyol" To: "Vishwas Manral" , v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011709; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34334344373838452E303031452D412D; ENG=IBF; TS=20060117231154; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011709_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD3A63210G1800735-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Vishwas Manral [mailto:Vishwas@sinett.com]=20 > And a more recent draft > http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- > bcc-flowla > bel-00.txt This last one looks a lot like MPLS in IPv6 ;-) Bora From owner-v6ops@ops.ietf.org Tue Jan 17 18:33:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez0Ka-0005Hk-7W for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 18:33:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05386 for ; Tue, 17 Jan 2006 18:32:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ez0Jg-000GWD-LF for v6ops-data@psg.com; Tue, 17 Jan 2006 23:32:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ez0Jb-000GUp-Hx for v6ops@ops.ietf.org; Tue, 17 Jan 2006 23:32:39 +0000 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 17 Jan 2006 15:32:39 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k0HNWcQi026582; Tue, 17 Jan 2006 15:32:38 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0HNbWJM032684; Tue, 17 Jan 2006 15:37:32 -0800 In-Reply-To: <03235919BBDE634289BB6A0758A20B36306B62@NT-SJCA-0751.brcm.ad.broadcom.com> References: <03235919BBDE634289BB6A0758A20B36306B62@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <274882C3-3DC8-40A2-9E9E-BBBE43EA7544@cisco.com> Cc: "Vishwas Manral" , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Flow label and its uses Date: Tue, 17 Jan 2006 15:32:37 -0800 To: "Bora Akyol" X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=852; t=1137541052; x=1137973252; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Flow=20label=20and=20its=20uses| From:Fred=20Baker=20| Date:Tue,=2017=20Jan=202006=2015=3A32=3A37=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=GD49o7q1yHagG801ySJfd0FLwTRHhM5p6vpHY8wg6UC+OpsTmW9qKnpEQ5v9jFEBnrlxjzLU UP/dJUaOXSrijpLFSdywEEuC4CO5DVYgPo6In4eKgDoTBWzmA85afxG+ypOQ6vmxT7KTGNRvDl9 CidIc8kE6ES4Y+o546BEEl9c= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'd encourage you to look at the big-internet archives (if they exist) from about 1993. The flow label was proposed to support the nimrod architecture, and in essence *was* what we later described as "MPLS", but in the IPv6 header. That's one of the reasons that the flow label isn't covered by the IPSEC checksum - so it could be managed appropriately at ingress and egress to the various "flows" or "LSPs". Yes, there has been a lot of water under that bridge. Between requiring the flow label to pass unchanged and making the address fixed length and of the same construction as the IPv4 address, Nimrod became very difficult to implement in IPv6, and Noel still isn't very happy with the IPv6 community. On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote: > > >> -----Original Message----- >> From: Vishwas Manral [mailto:Vishwas@sinett.com] > >> And a more recent draft >> http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- >> bcc-flowla >> bel-00.txt > > This last one looks a lot like MPLS in IPv6 ;-) > > Bora From owner-v6ops@ops.ietf.org Tue Jan 17 18:51:20 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez0bg-0000mD-Rd for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 18:51:20 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06509 for ; Tue, 17 Jan 2006 18:49:55 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ez0ai-000I4U-Cq for v6ops-data@psg.com; Tue, 17 Jan 2006 23:50:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.19] (helo=MMS3.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ez0ag-000I49-V5 for v6ops@ops.ietf.org; Tue, 17 Jan 2006 23:50:19 +0000 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 17 Jan 2006 15:50:06 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 5873767424; Tue, 17 Jan 2006 15:50:01 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 212AB67426; Tue, 17 Jan 2006 15:49:59 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSL23060; Tue, 17 Jan 2006 15:49:59 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id E3FA820502; Tue, 17 Jan 2006 15:49:58 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Tue, 17 Jan 2006 15:50:01 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306B7C@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYbvlaNx0d9ZfhMQPWGplA1atBpIAAAYDCg From: "Bora Akyol" To: "Fred Baker" cc: v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011709; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230352E34334344383138332E303031322D452D496151787168486E71713359712B34497879424261413D3D; ENG=IBF; TS=20060117235007; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011709_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD35D2441W1907101-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A pointer to some reference material on NIMROD: http://ana-3.lcs.mit.edu/~jnc/nimrod/nimsl.html =20 http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html http://www.ir.bbn.com/projects/nimrod Is there any use in keeping flow label as is, or should be relabeled as "Reserved"? I think there is some agreement that the label in=20 (Label, IP Source Address, IP Destination Address) triplet does not add a whole lot of value. Regards, Bora > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, January 17, 2006 3:33 PM > To: Bora Akyol > Cc: Vishwas Manral; v6ops@ops.ietf.org > Subject: Re: Flow label and its uses >=20 > I'd encourage you to look at the big-internet archives (if they > exist) from about 1993. The flow label was proposed to=20 > support the nimrod architecture, and in essence *was* what we=20 > later described as "MPLS", but in the IPv6 header. That's one=20 > of the reasons that the flow label isn't covered by the IPSEC=20 > checksum - so it could be managed appropriately at ingress=20 > and egress to the various "flows" or "LSPs". >=20 > Yes, there has been a lot of water under that bridge. Between=20 > requiring the flow label to pass unchanged and making the=20 > address fixed length and of the same construction as the IPv4=20 > address, Nimrod became very difficult to implement in IPv6,=20 > and Noel still isn't very happy with the IPv6 community. >=20 > On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote: >=20 > > > > > >> -----Original Message----- > >> From: Vishwas Manral [mailto:Vishwas@sinett.com] > > > >> And a more recent draft > >> http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- > >> bcc-flowla > >> bel-00.txt > > > > This last one looks a lot like MPLS in IPv6 ;-) > > > > Bora >=20 >=20 From owner-v6ops@ops.ietf.org Tue Jan 17 19:49:14 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez1Vi-0000M8-2v for v6ops-archive@megatron.ietf.org; Tue, 17 Jan 2006 19:49:14 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16934 for ; Tue, 17 Jan 2006 19:47:48 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ez1TM-000N1r-HT for v6ops-data@psg.com; Wed, 18 Jan 2006 00:46:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ez1TL-000N0J-OI for v6ops@ops.ietf.org; Wed, 18 Jan 2006 00:46:47 +0000 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 17 Jan 2006 16:46:48 -0800 X-IronPort-AV: i="3.99,378,1131350400"; d="scan'208"; a="1767518249:sNHT31788432" Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k0I0klQJ023838; Tue, 17 Jan 2006 16:46:47 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0I0pdJs000851; Tue, 17 Jan 2006 16:51:40 -0800 In-Reply-To: <03235919BBDE634289BB6A0758A20B36306B7C@NT-SJCA-0751.brcm.ad.broadcom.com> References: <03235919BBDE634289BB6A0758A20B36306B7C@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <714B616E-7EE6-4FF7-9BDB-2DE870902A96@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Flow label and its uses Date: Tue, 17 Jan 2006 16:46:45 -0800 To: "Bora Akyol" X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1717; t=1137545500; x=1137977700; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Flow=20label=20and=20its=20uses| From:Fred=20Baker=20| Date:Tue,=2017=20Jan=202006=2016=3A46=3A45=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=nZrc8Q0WpbeXUeXeukgg0olqZo7FeYWbbp6dfpBvGiS7StySfW94h+BVG7LK6Lg3G0hfX5w2 3c+klqHQDIz/vP4BzOjL4T8jDzYhaZr0DMPwORE91P+RoGjo4/vwnjYinO1KJA8hg0aHeqF8VRR JxsPojqMM4vSouuNLT4JFIFk= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit personally, I would label it reserved. I think the authors of RFC 3697 see it as something akin to a 20 bit DSCP, and if someone wants to see it that way it's fine by me. In any event, that is an ipv6wg question more than a v6ops question. On Jan 17, 2006, at 3:50 PM, Bora Akyol wrote: > A pointer to some reference material on NIMROD: > > http://ana-3.lcs.mit.edu/~jnc/nimrod/nimsl.html > > http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html > > http://www.ir.bbn.com/projects/nimrod > > Is there any use in keeping flow label as is, > or should be relabeled as "Reserved"? > > I think there is some agreement that > the label in > (Label, IP Source Address, IP Destination Address) > triplet does not add a whole lot of value. > > Regards, > > Bora > > >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Tuesday, January 17, 2006 3:33 PM >> To: Bora Akyol >> Cc: Vishwas Manral; v6ops@ops.ietf.org >> Subject: Re: Flow label and its uses >> >> I'd encourage you to look at the big-internet archives (if they >> exist) from about 1993. The flow label was proposed to >> support the nimrod architecture, and in essence *was* what we >> later described as "MPLS", but in the IPv6 header. That's one >> of the reasons that the flow label isn't covered by the IPSEC >> checksum - so it could be managed appropriately at ingress >> and egress to the various "flows" or "LSPs". >> >> Yes, there has been a lot of water under that bridge. Between >> requiring the flow label to pass unchanged and making the >> address fixed length and of the same construction as the IPv4 >> address, Nimrod became very difficult to implement in IPv6, >> and Noel still isn't very happy with the IPv6 community. >> >> On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote: >> >>> >>> >>>> -----Original Message----- >>>> From: Vishwas Manral [mailto:Vishwas@sinett.com] >>> >>>> And a more recent draft >>>> http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- >>>> bcc-flowla >>>> bel-00.txt >>> >>> This last one looks a lot like MPLS in IPv6 ;-) >>> >>> Bora >> >> From owner-v6ops@ops.ietf.org Wed Jan 18 08:07:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzD2A-000848-VQ for v6ops-archive@megatron.ietf.org; Wed, 18 Jan 2006 08:07:33 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10395 for ; Wed, 18 Jan 2006 08:06:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzCxg-0005ip-D3 for v6ops-data@psg.com; Wed, 18 Jan 2006 13:02:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzCxd-0005iI-IS for v6ops@ops.ietf.org; Wed, 18 Jan 2006 13:02:49 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0ID2Zfw282906 for ; Wed, 18 Jan 2006 13:02:38 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0ID2ZVS232558 for ; Wed, 18 Jan 2006 13:02:35 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k0ID2Yw1019911 for ; Wed, 18 Jan 2006 13:02:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k0ID2Ygt019896; Wed, 18 Jan 2006 13:02:34 GMT Received: from zurich.ibm.com (sig-9-145-133-160.de.ibm.com [9.145.133.160]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA72474; Wed, 18 Jan 2006 14:02:33 +0100 Message-ID: <43CE3C66.4020505@zurich.ibm.com> Date: Wed, 18 Jan 2006 14:02:30 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Fred Baker CC: Bora Akyol , v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: <03235919BBDE634289BB6A0758A20B36306B7C@NT-SJCA-0751.brcm.ad.broadcom.com> <714B616E-7EE6-4FF7-9BDB-2DE870902A96@cisco.com> In-Reply-To: <714B616E-7EE6-4FF7-9BDB-2DE870902A96@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred Baker wrote: > personally, I would label it reserved. I think the authors of RFC 3697 > see it as something akin to a 20 bit DSCP, and if someone wants to see > it that way it's fine by me. In any event, that is an ipv6wg question > more than a v6ops question. Indeed. And it isn't "reserved"; it *is* part of the header with the semantics defined to the extent of RFC 3697. My point is that people who want to use it, e.g. for load balancing, ought to be writing drafts. Brian > > On Jan 17, 2006, at 3:50 PM, Bora Akyol wrote: > >> A pointer to some reference material on NIMROD: >> >> http://ana-3.lcs.mit.edu/~jnc/nimrod/nimsl.html >> >> http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html >> >> http://www.ir.bbn.com/projects/nimrod >> >> Is there any use in keeping flow label as is, >> or should be relabeled as "Reserved"? >> >> I think there is some agreement that >> the label in >> (Label, IP Source Address, IP Destination Address) >> triplet does not add a whole lot of value. >> >> Regards, >> >> Bora >> >> >>> -----Original Message----- >>> From: Fred Baker [mailto:fred@cisco.com] >>> Sent: Tuesday, January 17, 2006 3:33 PM >>> To: Bora Akyol >>> Cc: Vishwas Manral; v6ops@ops.ietf.org >>> Subject: Re: Flow label and its uses >>> >>> I'd encourage you to look at the big-internet archives (if they >>> exist) from about 1993. The flow label was proposed to >>> support the nimrod architecture, and in essence *was* what we >>> later described as "MPLS", but in the IPv6 header. That's one >>> of the reasons that the flow label isn't covered by the IPSEC >>> checksum - so it could be managed appropriately at ingress >>> and egress to the various "flows" or "LSPs". >>> >>> Yes, there has been a lot of water under that bridge. Between >>> requiring the flow label to pass unchanged and making the >>> address fixed length and of the same construction as the IPv4 >>> address, Nimrod became very difficult to implement in IPv6, >>> and Noel still isn't very happy with the IPv6 community. >>> >>> On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote: >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Vishwas Manral [mailto:Vishwas@sinett.com] >>>> >>>> >>>>> And a more recent draft >>>>> http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- >>>>> bcc-flowla >>>>> bel-00.txt >>>> >>>> >>>> This last one looks a lot like MPLS in IPv6 ;-) >>>> >>>> Bora >>> >>> >>> > From owner-v6ops@ops.ietf.org Wed Jan 18 13:04:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzHfA-00078C-BN for v6ops-archive@megatron.ietf.org; Wed, 18 Jan 2006 13:04:04 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09496 for ; Wed, 18 Jan 2006 13:02:38 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzHbu-0005zT-By for v6ops-data@psg.com; Wed, 18 Jan 2006 18:00:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.19] (helo=MMS3.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzHbt-0005z7-6l for v6ops@ops.ietf.org; Wed, 18 Jan 2006 18:00:41 +0000 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 18 Jan 2006 10:00:26 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D286767420; Wed, 18 Jan 2006 10:00:25 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 3661A67421; Wed, 18 Jan 2006 10:00:25 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSO74989; Wed, 18 Jan 2006 10:00:13 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id CA5DB20501; Wed, 18 Jan 2006 10:00:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Wed, 18 Jan 2006 10:00:13 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYcL4fuNdUloGEaSDOCIuCJ9kTTZwAKKq3g From: "Bora Akyol" To: "Brian E Carpenter" , "Fred Baker" cc: v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011806; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34334345383130392E303032412D452D496151787168486E71713359712B34497879424261413D3D; ENG=IBF; TS=20060118180029; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011806_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD05DB041W2150065-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable From a switching hardware perspective, it would be nice to either define the use of this field as --endpoint only-- or label it "Reserved." There has been significant time since RFC3697 and the lack of applications may indicate that this field (with the exception of NIMROD) may not have a use at all. Regards Bora > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Wednesday, January 18, 2006 5:03 AM > To: Fred Baker > Cc: Bora Akyol; v6ops@ops.ietf.org > Subject: Re: Flow label and its uses >=20 > Fred Baker wrote: > > personally, I would label it reserved. I think the authors of RFC =20 > > 3697 see it as something akin to a 20 bit DSCP, and if=20 > someone wants =20 > > to see it that way it's fine by me. In any event, that is=20 > an ipv6wg =20 > > question more than a v6ops question. >=20 > Indeed. And it isn't "reserved"; it *is* part of the header=20 > with the semantics defined to the extent of RFC 3697. My=20 > point is that people who want to use it, e.g. for load=20 > balancing, ought to be writing drafts. >=20 > Brian >=20 > >=20 > > On Jan 17, 2006, at 3:50 PM, Bora Akyol wrote: > >=20 > >> A pointer to some reference material on NIMROD: > >> > >> http://ana-3.lcs.mit.edu/~jnc/nimrod/nimsl.html > >> > >> http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html > >> > >> http://www.ir.bbn.com/projects/nimrod > >> > >> Is there any use in keeping flow label as is, or should be=20 > relabeled=20 > >> as "Reserved"? > >> > >> I think there is some agreement that > >> the label in > >> (Label, IP Source Address, IP Destination Address) triplet=20 > does not=20 > >> add a whole lot of value. > >> > >> Regards, > >> > >> Bora > >> > >> > >>> -----Original Message----- > >>> From: Fred Baker [mailto:fred@cisco.com] > >>> Sent: Tuesday, January 17, 2006 3:33 PM > >>> To: Bora Akyol > >>> Cc: Vishwas Manral; v6ops@ops.ietf.org > >>> Subject: Re: Flow label and its uses > >>> > >>> I'd encourage you to look at the big-internet archives (if they > >>> exist) from about 1993. The flow label was proposed to=20 > support the=20 > >>> nimrod architecture, and in essence *was* what we later=20 > described as=20 > >>> "MPLS", but in the IPv6 header. That's one of the reasons=20 > that the=20 > >>> flow label isn't covered by the IPSEC checksum - so it could be=20 > >>> managed appropriately at ingress and egress to the=20 > various "flows"=20 > >>> or "LSPs". > >>> > >>> Yes, there has been a lot of water under that bridge. Between=20 > >>> requiring the flow label to pass unchanged and making the address=20 > >>> fixed length and of the same construction as the IPv4 address,=20 > >>> Nimrod became very difficult to implement in IPv6, and Noel still=20 > >>> isn't very happy with the IPv6 community. > >>> > >>> On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote: > >>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Vishwas Manral [mailto:Vishwas@sinett.com] > >>>> > >>>> > >>>>> And a more recent draft > >>>>> http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- > >>>>> bcc-flowla > >>>>> bel-00.txt > >>>> > >>>> > >>>> This last one looks a lot like MPLS in IPv6 ;-) > >>>> > >>>> Bora > >>> > >>> > >>> > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Wed Jan 18 13:42:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzIGc-0000XF-IN for v6ops-archive@megatron.ietf.org; Wed, 18 Jan 2006 13:42:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11981 for ; Wed, 18 Jan 2006 13:41:20 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzIFR-0009WS-23 for v6ops-data@psg.com; Wed, 18 Jan 2006 18:41:33 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzIFP-0009W5-V1 for v6ops@ops.ietf.org; Wed, 18 Jan 2006 18:41:32 +0000 Received: from netcore.fi (localhost [127.0.0.1]) by netcore.fi (8.12.8/8.12.8) with ESMTP id k0IIeUHa022124; Wed, 18 Jan 2006 20:40:30 +0200 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.8/8.12.8/Submit) with ESMTP id k0IIeSk9022121; Wed, 18 Jan 2006 20:40:30 +0200 Date: Wed, 18 Jan 2006 20:40:28 +0200 (EET) From: Pekka Savola To: Bora Akyol cc: Brian E Carpenter , Fred Baker , v6ops@ops.ietf.org Subject: RE: Flow label and its uses In-Reply-To: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> Message-ID: References: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on otso.netcore.fi X-Virus-Status: Clean Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Wed, 18 Jan 2006, Bora Akyol wrote: > From a switching hardware perspective, it would be nice > to either define the use of this field as --endpoint only-- > or label it "Reserved." > > There has been significant time since RFC3697 and the lack > of applications may indicate that this field (with > the exception of NIMROD) may not have a use at all. I've been watching this discussion with mild puzzlement. There is (basically) nothing that the routers need to do with the flow label. Whatever they might end up doing with it would likely mostly fall under the control plane, so it doesn't need to be put in the hardware. So what's the problem? Do you want to try to reuse the "basically unused 20 bits" for some local purposes? That's not going to be allowed. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Jan 18 13:47:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzILZ-0001sG-OJ for v6ops-archive@megatron.ietf.org; Wed, 18 Jan 2006 13:47:53 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12334 for ; Wed, 18 Jan 2006 13:46:27 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzIL7-000A7D-Kc for v6ops-data@psg.com; Wed, 18 Jan 2006 18:47:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.19] (helo=MMS3.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzIL5-000A6b-QF for v6ops@ops.ietf.org; Wed, 18 Jan 2006 18:47:25 +0000 Received: from 10.10.64.154 by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 18 Jan 2006 10:47:11 -0800 X-Server-Uuid: B238DE4C-2139-4D32-96A8-DD564EF2313E Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id D728567423; Wed, 18 Jan 2006 10:47:10 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 8F53F67421; Wed, 18 Jan 2006 10:47:10 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSO92925; Wed, 18 Jan 2006 10:47:09 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6D8AE20501; Wed, 18 Jan 2006 10:47:09 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Wed, 18 Jan 2006 10:47:08 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306C7C@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYcXuwW46jxULCVQ8m+8JbSkfl0LAAAFa+A From: "Bora Akyol" To: "Pekka Savola" cc: "Brian E Carpenter" , "Fred Baker" , v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006011807; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230352E34334345384246442E303031412D412D; ENG=IBF; TS=20060118184713; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006011807_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FD052A541W2161695-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > > There has been significant time since RFC3697 and the lack of=20 > > applications may indicate that this field (with the exception of=20 > > NIMROD) may not have a use at all. >=20 > I've been watching this discussion with mild puzzlement. >=20 > There is (basically) nothing that the routers need to do with=20 > the flow label. Whatever they might end up doing with it=20 > would likely mostly fall under the control plane, so it=20 > doesn't need to be put in the hardware. >=20 Hi Pekka, Did you get a chance to look over the proposal that is floating around to use the flow label as a locally significant switching label? Also, if the flow label can be used as an indication of=20 classification at the source, then it can be used to=20 decide preferential treatment in the network (hence the 20 bit DSCP extension proposal I guess -- which I have not read). Regards, Bora From owner-v6ops@ops.ietf.org Wed Jan 18 15:45:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKAr-0001uU-E7 for v6ops-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:45:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21977 for ; Wed, 18 Jan 2006 15:43:30 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzK89-000KZI-IA for v6ops-data@psg.com; Wed, 18 Jan 2006 20:42:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzK86-000KZ3-W9 for v6ops@ops.ietf.org; Wed, 18 Jan 2006 20:42:07 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 18 Jan 2006 12:42:07 -0800 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k0IKg6jt022296; Wed, 18 Jan 2006 12:42:06 -0800 (PST) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k0IKkuwp008425; Wed, 18 Jan 2006 12:46:56 -0800 In-Reply-To: References: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <49CD1898-889B-4168-A99D-9D5BE5DB58DC@cisco.com> Cc: Bora Akyol , Brian E Carpenter , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Flow label and its uses Date: Wed, 18 Jan 2006 12:42:04 -0800 To: Pekka Savola X-Mailer: Apple Mail (2.746.2) DKIM-Signature: a=rsa-sha1; q=dns; l=1716; t=1137617216; x=1138049416; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Flow=20label=20and=20its=20uses| From:Fred=20Baker=20| Date:Wed,=2018=20Jan=202006=2012=3A42=3A04=20-0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=VgZrzf+fuB3A/KnRHBE54XydRMK+sXPo9dkQHyh9Ri1b8AcUMbbhp9F2QKTnNI0s1vlnYEIo VuX/ivJs8hYsT9KvouAvFloRlCNvj1lefzEaeaYvlgiAmk1eDsZTLp8hE8CYc1FrFZcWoSIm+eB hhqgwXqJzdxUpKArbiOvKyRE= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit In the NIMROD scenario, the flow label identifies something akin to a virtual circuit; more properly, it identifies an aggregated route. A "map" (a bag of prefixes advertised by a network entity such as an ISP or an enterprise network) is connected to the network of reference by some route, and the flow label permits a high speed lookup, rather than looking up the prefix. It is very much like the MPLS label lookup done in MPLS routing. Sham's draft referenced earlier in the thread has a similar model. RFC 3697 proposes that it be used for source classification of the traffic; the router is supposed to look up the flow label and use that in diffserv classification in a manner similar to the current use of the DSCP; the values an application could expect to find support for in the network would have to be installed in the path by some form of signaling or be well known in the network. Either way, the forwarding implementation (whether software or firmware) is going to be looking up the flow label in the data path. Hence Bora's comment that it has to be aware of the flow label. On Jan 18, 2006, at 10:40 AM, Pekka Savola wrote: > Hi, > > On Wed, 18 Jan 2006, Bora Akyol wrote: >> From a switching hardware perspective, it would be nice >> to either define the use of this field as --endpoint only-- >> or label it "Reserved." >> >> There has been significant time since RFC3697 and the lack >> of applications may indicate that this field (with >> the exception of NIMROD) may not have a use at all. > > I've been watching this discussion with mild puzzlement. > > There is (basically) nothing that the routers need to do with the > flow label. Whatever they might end up doing with it would likely > mostly fall under the control plane, so it doesn't need to be put > in the hardware. > > So what's the problem? Do you want to try to reuse the "basically > unused 20 bits" for some local purposes? That's not going to be > allowed. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From mikeskillz@excite.com Thu Jan 19 03:00:36 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzUih-00075H-8f for v6ops-archive@megatron.ietf.org; Thu, 19 Jan 2006 03:00:35 -0500 Received: from c-71-198-37-16.hsd1.ca.comcast.net (c-71-198-37-16.hsd1.ca.comcast.net [71.198.37.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28776 for ; Thu, 19 Jan 2006 02:59:08 -0500 (EST) Received: (from restaurant@microsoft.com) by microsoft.com (0.13.8/45.3.4/Submit) id contrition; Thu, 19 Jan 2006 01:24:58 -0500 Date: Thu, 19 Jan 2006 01:14:12 -0500 Message-Id: <356029.998970@microsoft.com> To: v6ops-archive@ietf.org Subject: Amazing, Jeannine From: Alden Osborn Reply-To: ledas@earthlink.com Content-Type: multipart/mixed; boundary="------=52143084336" Content-Transfer-Encoding: 7bit --------=52143084336 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Although the masters make the rules for the wise men and the fools got nothing, Ma, to live up to.The only fence against the world is a thorough knowledge of it.
Life cannot subsist in society but by reciprocal concessions.No one that encounters prosperity does not also encounter danger.Nothing ends nicely, that's why it ends. --------=52143084336 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Adolfo-> --------=52143084336-- From owner-v6ops@ops.ietf.org Thu Jan 19 09:41:49 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezayz-0004tD-De for v6ops-archive@megatron.ietf.org; Thu, 19 Jan 2006 09:41:49 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27630 for ; Thu, 19 Jan 2006 09:40:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzauO-0000sk-P3 for v6ops-data@psg.com; Thu, 19 Jan 2006 14:37:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzauN-0000sK-Aq for v6ops@ops.ietf.org; Thu, 19 Jan 2006 14:37:03 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0JEaLx0231708 for ; Thu, 19 Jan 2006 14:36:26 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0JEZZgF237592 for ; Thu, 19 Jan 2006 14:35:35 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k0JEZY38024498 for ; Thu, 19 Jan 2006 14:35:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k0JEZWfT024402; Thu, 19 Jan 2006 14:35:33 GMT Received: from zurich.ibm.com (sig-9-146-218-37.de.ibm.com [9.146.218.37]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA57260; Thu, 19 Jan 2006 15:35:30 +0100 Message-ID: <43CFA0B0.5030208@zurich.ibm.com> Date: Thu, 19 Jan 2006 15:22:40 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Bora Akyol CC: Fred Baker , v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Bora Akyol wrote: >>From a switching hardware perspective, it would be nice > to either define the use of this field as --endpoint only-- > or label it "Reserved." I disagree pretty strongly. As defined now, this field *needs* to be covered by hardware classifiers. It was to clarify that point (which is ambiguous in RFC 2460) that the IPv6 WG produced RFC 3697. > > There has been significant time since RFC3697 and the lack > of applications may indicate that this field (with > the exception of NIMROD) may not have a use at all. NIMROD is ancient history. I firmly believe the use cases will come, once IPv6 is deployed to the extent that people really care about load balancing etc. Brian > > Regards > > Bora > > > >>-----Original Message----- >>From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >>Sent: Wednesday, January 18, 2006 5:03 AM >>To: Fred Baker >>Cc: Bora Akyol; v6ops@ops.ietf.org >>Subject: Re: Flow label and its uses >> >>Fred Baker wrote: >> >>>personally, I would label it reserved. I think the authors of RFC >>>3697 see it as something akin to a 20 bit DSCP, and if >> >>someone wants >> >>>to see it that way it's fine by me. In any event, that is >> >>an ipv6wg >> >>>question more than a v6ops question. >> >>Indeed. And it isn't "reserved"; it *is* part of the header >>with the semantics defined to the extent of RFC 3697. My >>point is that people who want to use it, e.g. for load >>balancing, ought to be writing drafts. >> >> Brian >> >> >>>On Jan 17, 2006, at 3:50 PM, Bora Akyol wrote: >>> >>> >>>>A pointer to some reference material on NIMROD: >>>> >>>>http://ana-3.lcs.mit.edu/~jnc/nimrod/nimsl.html >>>> >>>>http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html >>>> >>>>http://www.ir.bbn.com/projects/nimrod >>>> >>>>Is there any use in keeping flow label as is, or should be >> >>relabeled >> >>>>as "Reserved"? >>>> >>>>I think there is some agreement that >>>>the label in >>>>(Label, IP Source Address, IP Destination Address) triplet >> >>does not >> >>>>add a whole lot of value. >>>> >>>>Regards, >>>> >>>>Bora >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Fred Baker [mailto:fred@cisco.com] >>>>>Sent: Tuesday, January 17, 2006 3:33 PM >>>>>To: Bora Akyol >>>>>Cc: Vishwas Manral; v6ops@ops.ietf.org >>>>>Subject: Re: Flow label and its uses >>>>> >>>>>I'd encourage you to look at the big-internet archives (if they >>>>>exist) from about 1993. The flow label was proposed to >> >>support the >> >>>>>nimrod architecture, and in essence *was* what we later >> >>described as >> >>>>>"MPLS", but in the IPv6 header. That's one of the reasons >> >>that the >> >>>>>flow label isn't covered by the IPSEC checksum - so it could be >>>>>managed appropriately at ingress and egress to the >> >>various "flows" >> >>>>>or "LSPs". >>>>> >>>>>Yes, there has been a lot of water under that bridge. Between >>>>>requiring the flow label to pass unchanged and making the address >>>>>fixed length and of the same construction as the IPv4 address, >>>>>Nimrod became very difficult to implement in IPv6, and Noel still >>>>>isn't very happy with the IPv6 community. >>>>> >>>>>On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote: >>>>> >>>>> >>>>>> >>>>>>>-----Original Message----- >>>>>>>From: Vishwas Manral [mailto:Vishwas@sinett.com] >>>>>> >>>>>> >>>>>>>And a more recent draft >>>>>>>http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty- >>>>>>>bcc-flowla >>>>>>>bel-00.txt >>>>>> >>>>>> >>>>>>This last one looks a lot like MPLS in IPv6 ;-) >>>>>> >>>>>>Bora >>>>> >>>>> >>>>> >> >> > > From owner-v6ops@ops.ietf.org Thu Jan 19 10:44:37 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezbxi-0002iS-G5 for v6ops-archive@megatron.ietf.org; Thu, 19 Jan 2006 10:44:37 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01822 for ; Thu, 19 Jan 2006 10:43:06 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezbvv-0006ET-1P for v6ops-data@psg.com; Thu, 19 Jan 2006 15:42:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezbvt-0006EB-PL for v6ops@ops.ietf.org; Thu, 19 Jan 2006 15:42:42 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0JFa0RG056206 for ; Thu, 19 Jan 2006 15:42:36 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0JEZYgF147970 for ; Thu, 19 Jan 2006 14:35:35 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k0JEZXsi024421 for ; Thu, 19 Jan 2006 14:35:34 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k0JEZUcA024368; Thu, 19 Jan 2006 14:35:31 GMT Received: from zurich.ibm.com (sig-9-146-218-37.de.ibm.com [9.146.218.37]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA57252; Thu, 19 Jan 2006 15:35:28 +0100 Message-ID: <43CFA09D.9090704@zurich.ibm.com> Date: Thu, 19 Jan 2006 15:22:21 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Pekka Savola CC: Bora Akyol , Fred Baker , v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: <03235919BBDE634289BB6A0758A20B36306C5C@NT-SJCA-0751.brcm.ad.broadcom.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Pekka Savola wrote: > Hi, > > On Wed, 18 Jan 2006, Bora Akyol wrote: > >> From a switching hardware perspective, it would be nice >> to either define the use of this field as --endpoint only-- >> or label it "Reserved." >> >> There has been significant time since RFC3697 and the lack >> of applications may indicate that this field (with >> the exception of NIMROD) may not have a use at all. > > > I've been watching this discussion with mild puzzlement. > > There is (basically) nothing that the routers need to do with the flow > label. Whatever they might end up doing with it would likely mostly > fall under the control plane, so it doesn't need to be put in the hardware. No, that's wrong if it gets used in line speed QOS classifiers. That's what I'd expect in load balancing. Brian > > So what's the problem? Do you want to try to reuse the "basically > unused 20 bits" for some local purposes? That's not going to be allowed. > From owner-v6ops@ops.ietf.org Fri Jan 20 01:52:34 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezq8M-0000C8-KO for v6ops-archive@megatron.ietf.org; Fri, 20 Jan 2006 01:52:34 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12500 for ; Fri, 20 Jan 2006 01:51:03 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezq4v-0008Yr-Sj for v6ops-data@psg.com; Fri, 20 Jan 2006 06:48:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.158] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezq4t-0008X8-8e for v6ops@ops.ietf.org; Fri, 20 Jan 2006 06:48:55 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Thu, 19 Jan 2006 22:48:53 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYdEsI2VWZJ1rPbTtifaRwoHtBVrwAeN0GA From: "Vishwas Manral" To: "Brian E Carpenter" , "Pekka Savola" Cc: "Bora Akyol" , "Fred Baker" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I agree flow-label if used as a direct one-to-one mapping to a flow (protocol/ ports) can be of use.=20 Especially in cases where the upper layer header cannot be derived - encrypted input, fragments etc and the end-to-end nature of flow label is there.=20 This could be used as a selector instead of creating a new SA instead of OPAQUE for the IPsec RFC4301 case. Changes would be required for RFC4306 for the same too. I am sure things like load balancing which require deeper packet inspection can also be done. Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, January 19, 2006 7:52 PM To: Pekka Savola Cc: Bora Akyol; Fred Baker; v6ops@ops.ietf.org Subject: Re: Flow label and its uses Pekka Savola wrote: > Hi, >=20 > On Wed, 18 Jan 2006, Bora Akyol wrote: >=20 >> From a switching hardware perspective, it would be nice >> to either define the use of this field as --endpoint only-- >> or label it "Reserved." >> >> There has been significant time since RFC3697 and the lack >> of applications may indicate that this field (with >> the exception of NIMROD) may not have a use at all. >=20 >=20 > I've been watching this discussion with mild puzzlement. >=20 > There is (basically) nothing that the routers need to do with the flow > label. Whatever they might end up doing with it would likely mostly=20 > fall under the control plane, so it doesn't need to be put in the hardware. No, that's wrong if it gets used in line speed QOS classifiers. That's what I'd expect in load balancing. Brian >=20 > So what's the problem? Do you want to try to reuse the "basically=20 > unused 20 bits" for some local purposes? That's not going to be allowed. >=20 From owner-v6ops@ops.ietf.org Fri Jan 20 07:34:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvSr-0005gI-PE for v6ops-archive@megatron.ietf.org; Fri, 20 Jan 2006 07:34:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08940 for ; Fri, 20 Jan 2006 07:32:34 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzvPr-0008dh-Ng for v6ops-data@psg.com; Fri, 20 Jan 2006 12:30:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzvPq-0008dA-K9 for v6ops@ops.ietf.org; Fri, 20 Jan 2006 12:30:54 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0KCThoM053318 for ; Fri, 20 Jan 2006 12:29:57 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0KCTh5l236652 for ; Fri, 20 Jan 2006 12:29:43 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k0KCTgen020599 for ; Fri, 20 Jan 2006 12:29:42 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k0KCTglb020590; Fri, 20 Jan 2006 12:29:42 GMT Received: from zurich.ibm.com (sig-9-145-134-195.de.ibm.com [9.145.134.195]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA38190; Fri, 20 Jan 2006 13:29:40 +0100 Message-ID: <43D0D7B1.9070308@zurich.ibm.com> Date: Fri, 20 Jan 2006 13:29:37 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Vishwas Manral CC: Pekka Savola , Bora Akyol , Fred Baker , v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Vishwas Manral wrote: >... I am sure things like load balancing which require > deeper packet inspection can also be done. The whole point is that you will not need deep packet inspection if the flow label is set by the source. Brian From owner-v6ops@ops.ietf.org Fri Jan 20 07:55:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzvnK-00060Q-QL for v6ops-archive@megatron.ietf.org; Fri, 20 Jan 2006 07:55:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10164 for ; Fri, 20 Jan 2006 07:53:43 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzvmM-000ASb-9f for v6ops-data@psg.com; Fri, 20 Jan 2006 12:54:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00, MIME_BASE64_NO_NAME,RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0 Received: from [208.17.33.59] (helo=pacdcoavas10.cable.comcast.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EzvmL-000ASO-HH for v6ops@ops.ietf.org; Fri, 20 Jan 2006 12:54:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: Re: Flow label and its uses Date: Fri, 20 Jan 2006 07:53:39 -0500 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C73C2F202@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Flow label and its uses Thread-Index: AcYdEsI2VWZJ1rPbTtifaRwoHtBVrwAeN0GAAA06geE= From: "Durand, Alain" To: , , Cc: , , X-OriginalArrivalTime: 20 Jan 2006 12:53:40.0983 (UTC) FILETIME=[89D26070:01C61DC0] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: base64 VGhlcmUgaXMgc29tZXRoaW5nIEkgbmV2ZXIgdW5kZXJzdG9vZCBhYm91dCB0aGUgZmxvdyBsYWJl bC4uLiBJbiB0aGUgY2FzZSBzb21lb25lIHdhbnRzIHRvIHVzZWQgaXQgd2hlbiBkZWVwIHBhY2tl dCBpbnNwZWN0aW9uIGlzIG5vdCBwb3NzaWJsZSBiZWNhdXNlIG9mIElQc2VjIGVuY3J5cHRpb24s IGhvdyBjYW4gb25lIHRydXN0IGl0IGFzIHRoaXMgZmllbGQgaXMgTk9UIHByb3RlY3RlZCBieSBJ UHNlYz8NCg0KV2hhdCBhbSBJIG1pc3Npbmc/DQoNCiAgIC0gQWxhaW4uDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZw0KVG86IEJy aWFuIEUgQ2FycGVudGVyOyBQZWtrYSBTYXZvbGENCkNDOiBCb3JhIEFreW9sOyBGcmVkIEJha2Vy OyB2Nm9wc0BvcHMuaWV0Zi5vcmcNClNlbnQ6IEZyaSBKYW4gMjAgMDE6NDg6NTMgMjAwNg0KU3Vi amVjdDogUkU6IEZsb3cgbGFiZWwgYW5kIGl0cyB1c2VzDQoNCkhpLA0KDQpJIGFncmVlIGZsb3ct bGFiZWwgaWYgdXNlZCBhcyBhIGRpcmVjdCBvbmUtdG8tb25lIG1hcHBpbmcgdG8gYSBmbG93DQoo cHJvdG9jb2wvIHBvcnRzKSBjYW4gYmUgb2YgdXNlLiANCg0KRXNwZWNpYWxseSBpbiBjYXNlcyB3 aGVyZSB0aGUgdXBwZXIgbGF5ZXIgaGVhZGVyIGNhbm5vdCBiZSBkZXJpdmVkIC0NCmVuY3J5cHRl ZCBpbnB1dCwgZnJhZ21lbnRzIGV0YyBhbmQgdGhlIGVuZC10by1lbmQgbmF0dXJlIG9mIGZsb3cg bGFiZWwNCmlzIHRoZXJlLiANCg0KVGhpcyBjb3VsZCBiZSB1c2VkIGFzIGEgc2VsZWN0b3IgaW5z dGVhZCBvZiBjcmVhdGluZyBhIG5ldyBTQSBpbnN0ZWFkIG9mDQpPUEFRVUUgZm9yIHRoZSBJUHNl YyBSRkM0MzAxIGNhc2UuIENoYW5nZXMgd291bGQgYmUgcmVxdWlyZWQgZm9yIFJGQzQzMDYNCmZv ciB0aGUgc2FtZSB0b28uIEkgYW0gc3VyZSB0aGluZ3MgbGlrZSBsb2FkIGJhbGFuY2luZyB3aGlj aCByZXF1aXJlDQpkZWVwZXIgcGFja2V0IGluc3BlY3Rpb24gY2FuIGFsc28gYmUgZG9uZS4NCg0K VGhhbmtzLA0KVmlzaHdhcw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG93bmVy LXY2b3BzQG9wcy5pZXRmLm9yZyBbbWFpbHRvOm93bmVyLXY2b3BzQG9wcy5pZXRmLm9yZ10gT24N CkJlaGFsZiBPZiBCcmlhbiBFIENhcnBlbnRlcg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTks IDIwMDYgNzo1MiBQTQ0KVG86IFBla2thIFNhdm9sYQ0KQ2M6IEJvcmEgQWt5b2w7IEZyZWQgQmFr ZXI7IHY2b3BzQG9wcy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IEZsb3cgbGFiZWwgYW5kIGl0cyB1 c2VzDQoNClBla2thIFNhdm9sYSB3cm90ZToNCj4gSGksDQo+IA0KPiBPbiBXZWQsIDE4IEphbiAy MDA2LCBCb3JhIEFreW9sIHdyb3RlOg0KPiANCj4+IEZyb20gYSBzd2l0Y2hpbmcgaGFyZHdhcmUg cGVyc3BlY3RpdmUsIGl0IHdvdWxkIGJlIG5pY2UNCj4+IHRvIGVpdGhlciBkZWZpbmUgdGhlIHVz ZSBvZiB0aGlzIGZpZWxkIGFzIC0tZW5kcG9pbnQgb25seS0tDQo+PiBvciBsYWJlbCBpdCAiUmVz ZXJ2ZWQuIg0KPj4NCj4+IFRoZXJlIGhhcyBiZWVuIHNpZ25pZmljYW50IHRpbWUgc2luY2UgUkZD MzY5NyBhbmQgdGhlIGxhY2sNCj4+IG9mIGFwcGxpY2F0aW9ucyBtYXkgaW5kaWNhdGUgdGhhdCB0 aGlzIGZpZWxkICh3aXRoDQo+PiB0aGUgZXhjZXB0aW9uIG9mIE5JTVJPRCkgbWF5IG5vdCBoYXZl IGEgdXNlIGF0IGFsbC4NCj4gDQo+IA0KPiBJJ3ZlIGJlZW4gd2F0Y2hpbmcgdGhpcyBkaXNjdXNz aW9uIHdpdGggbWlsZCBwdXp6bGVtZW50Lg0KPiANCj4gVGhlcmUgaXMgKGJhc2ljYWxseSkgbm90 aGluZyB0aGF0IHRoZSByb3V0ZXJzIG5lZWQgdG8gZG8gd2l0aCB0aGUgZmxvdw0KDQo+IGxhYmVs LiAgV2hhdGV2ZXIgdGhleSBtaWdodCBlbmQgdXAgZG9pbmcgd2l0aCBpdCB3b3VsZCBsaWtlbHkg bW9zdGx5IA0KPiBmYWxsIHVuZGVyIHRoZSBjb250cm9sIHBsYW5lLCBzbyBpdCBkb2Vzbid0IG5l ZWQgdG8gYmUgcHV0IGluIHRoZQ0KaGFyZHdhcmUuDQoNCk5vLCB0aGF0J3Mgd3JvbmcgaWYgaXQg Z2V0cyB1c2VkIGluIGxpbmUgc3BlZWQgUU9TIGNsYXNzaWZpZXJzLiBUaGF0J3MNCndoYXQgSSdk IGV4cGVjdCBpbiBsb2FkIGJhbGFuY2luZy4NCg0KICAgIEJyaWFuDQo+IA0KPiBTbyB3aGF0J3Mg dGhlIHByb2JsZW0/ICBEbyB5b3Ugd2FudCB0byB0cnkgdG8gcmV1c2UgdGhlICJiYXNpY2FsbHkg DQo+IHVudXNlZCAyMCBiaXRzIiBmb3Igc29tZSBsb2NhbCBwdXJwb3Nlcz8gIFRoYXQncyBub3Qg Z29pbmcgdG8gYmUNCmFsbG93ZWQuDQo+IA0KDQoNCg0K From owner-v6ops@ops.ietf.org Fri Jan 20 09:22:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ezx9L-0003vD-T9 for v6ops-archive@megatron.ietf.org; Fri, 20 Jan 2006 09:22:00 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16442 for ; Fri, 20 Jan 2006 09:20:31 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezx7e-000H5d-6S for v6ops-data@psg.com; Fri, 20 Jan 2006 14:20:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [195.212.29.135] (helo=mtagate2.uk.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ezx7d-000H51-21 for v6ops@ops.ietf.org; Fri, 20 Jan 2006 14:20:13 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id k0KEJOoM103526 for ; Fri, 20 Jan 2006 14:19:28 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0KEII5l171440 for ; Fri, 20 Jan 2006 14:18:18 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k0KEIHpC008560 for ; Fri, 20 Jan 2006 14:18:18 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k0KEIH9d008543; Fri, 20 Jan 2006 14:18:17 GMT Received: from zurich.ibm.com (sig-9-145-134-195.de.ibm.com [9.145.134.195]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA68552; Fri, 20 Jan 2006 15:18:16 +0100 Message-ID: <43D0F124.6060509@zurich.ibm.com> Date: Fri, 20 Jan 2006 15:18:12 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: "Durand, Alain" CC: Vishwas@sinett.com, pekkas@netcore.fi, bora@broadcom.com, fred@cisco.com, v6ops@ops.ietf.org Subject: Re: Flow label and its uses References: <6EEEACD9D7F52940BEE26F5467C02C73C2F202@PACDCEXCMB01.cable.comcast.com> In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C73C2F202@PACDCEXCMB01.cable.comcast.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit You're missing nothing. It's intrinsically forgeable. That is a limit on the useful use cases. See section 5.1 of RFC 3697. Brian Durand, Alain wrote: > There is something I never understood about the flow label... In the case someone wants to used it when deep packet inspection is not possible because of IPsec encryption, how can one trust it as this field is NOT protected by IPsec? > > What am I missing? > > - Alain. > > > -----Original Message----- > From: owner-v6ops@ops.ietf.org > To: Brian E Carpenter; Pekka Savola > CC: Bora Akyol; Fred Baker; v6ops@ops.ietf.org > Sent: Fri Jan 20 01:48:53 2006 > Subject: RE: Flow label and its uses > > Hi, > > I agree flow-label if used as a direct one-to-one mapping to a flow > (protocol/ ports) can be of use. > > Especially in cases where the upper layer header cannot be derived - > encrypted input, fragments etc and the end-to-end nature of flow label > is there. > > This could be used as a selector instead of creating a new SA instead of > OPAQUE for the IPsec RFC4301 case. Changes would be required for RFC4306 > for the same too. I am sure things like load balancing which require > deeper packet inspection can also be done. > > Thanks, > Vishwas > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Brian E Carpenter > Sent: Thursday, January 19, 2006 7:52 PM > To: Pekka Savola > Cc: Bora Akyol; Fred Baker; v6ops@ops.ietf.org > Subject: Re: Flow label and its uses > > Pekka Savola wrote: > >>Hi, >> >>On Wed, 18 Jan 2006, Bora Akyol wrote: >> >> >>>From a switching hardware perspective, it would be nice >>>to either define the use of this field as --endpoint only-- >>>or label it "Reserved." >>> >>>There has been significant time since RFC3697 and the lack >>>of applications may indicate that this field (with >>>the exception of NIMROD) may not have a use at all. >> >> >>I've been watching this discussion with mild puzzlement. >> >>There is (basically) nothing that the routers need to do with the flow > > >>label. Whatever they might end up doing with it would likely mostly >>fall under the control plane, so it doesn't need to be put in the > > hardware. > > No, that's wrong if it gets used in line speed QOS classifiers. That's > what I'd expect in load balancing. > > Brian > >>So what's the problem? Do you want to try to reuse the "basically >>unused 20 bits" for some local purposes? That's not going to be > > allowed. > > > > > From owner-v6ops@ops.ietf.org Fri Jan 20 13:38:39 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F019h-0004yE-7S for v6ops-archive@megatron.ietf.org; Fri, 20 Jan 2006 13:38:39 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08994 for ; Fri, 20 Jan 2006 13:37:10 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F016z-000CEi-UF for v6ops-data@psg.com; Fri, 20 Jan 2006 18:35:49 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.17] (helo=mms1.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F016y-000CEO-NH for v6ops@ops.ietf.org; Fri, 20 Jan 2006 18:35:49 +0000 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Fri, 20 Jan 2006 10:35:33 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 8636C67420; Fri, 20 Jan 2006 10:35:33 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 2B7A867420; Fri, 20 Jan 2006 10:35:33 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.5.6-GR) with ESMTP id CSZ81200; Fri, 20 Jan 2006 10:35:22 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id 6211A20501; Fri, 20 Jan 2006 10:35:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Fri, 20 Jan 2006 10:35:19 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36306FFD@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYdEsI2VWZJ1rPbTtifaRwoHtBVrwAeN0GAAA06geEAC8/pcA== From: "Bora Akyol" To: "Durand, Alain" , Vishwas@sinett.com, brc@zurich.ibm.com, pekkas@netcore.fi cc: fred@cisco.com, v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006012006; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230322E34334431324333332E303031392D412D; ENG=IBF; TS=20060120183535; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006012006_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FCFF2FF10G2846552-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 You are missing nothing. Frankly, I don't believe in using this field as a locally significant switching shortcut (like a label in MPLS). We have MPLS, we have VPLS, we have their ethernet variants using information from the Ethernet headers. I think we have enough tools to get the job done and we don't need another tool. This is why I think we should label this field as Reserved so that if we run out of bits in the header for other apps, we can use these 20 bits. Regards Bora > -----Original Message----- > From: Durand, Alain [mailto:Alain_Durand@cable.comcast.com]=20 > Sent: Friday, January 20, 2006 4:54 AM > To: Vishwas@sinett.com; brc@zurich.ibm.com; pekkas@netcore.fi > Cc: Bora Akyol; fred@cisco.com; v6ops@ops.ietf.org > Subject: Re: Flow label and its uses >=20 > There is something I never understood about the flow label...=20 > In the case someone wants to used it when deep packet=20 > inspection is not possible because of IPsec encryption, how=20 > can one trust it as this field is NOT protected by IPsec? >=20 > What am I missing? >=20 > - Alain. From owner-v6ops@ops.ietf.org Fri Jan 20 14:11:46 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F01fk-0001MZ-0x for v6ops-archive@megatron.ietf.org; Fri, 20 Jan 2006 14:11:46 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11421 for ; Fri, 20 Jan 2006 14:10:16 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F01en-000F8c-G2 for v6ops-data@psg.com; Fri, 20 Jan 2006 19:10:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [32.97.182.143] (helo=e3.ny.us.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F01em-000F8O-Lw for v6ops@ops.ietf.org; Fri, 20 Jan 2006 19:10:44 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k0KJAejx007909 for ; Fri, 20 Jan 2006 14:10:40 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VERS6.8) with ESMTP id k0KJAetw047000 for ; Fri, 20 Jan 2006 14:10:40 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k0KJAeBu002484 for ; Fri, 20 Jan 2006 14:10:40 -0500 Received: from cichlid.raleigh.ibm.com (sig-9-65-220-40.mts.ibm.com [9.65.220.40]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k0KJAcsV002189; Fri, 20 Jan 2006 14:10:39 -0500 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.1/8.12.5) with ESMTP id k0KJ9UAI009271; Fri, 20 Jan 2006 14:09:36 -0500 Message-Id: <200601201909.k0KJ9UAI009271@cichlid.raleigh.ibm.com> To: "Durand, Alain" cc: v6ops@ops.ietf.org Subject: Re: Flow label and its uses In-Reply-To: Message from "Durand, Alain" of "Fri, 20 Jan 2006 07:53:39 EST." <6EEEACD9D7F52940BEE26F5467C02C73C2F202@PACDCEXCMB01.cable.comcast.com> Date: Fri, 20 Jan 2006 14:09:30 -0500 From: Thomas Narten Sender: owner-v6ops@ops.ietf.org Precedence: bulk > There is something I never understood about the flow label... In the > case someone wants to used it when deep packet inspection is not > possible because of IPsec encryption, how can one trust it as this > field is NOT protected by IPsec? How would protecting that field with IPsec help any of the devices along the path, i.e., those devices that are using the flow label to classify packets? They most certainly will _not_ have an SA for those packets (and talk about a performance hit if routers actually tried to do this!!!) Thomas From owner-v6ops@ops.ietf.org Sat Jan 21 03:59:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Eb7-0004uf-04 for v6ops-archive@megatron.ietf.org; Sat, 21 Jan 2006 03:59:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14204 for ; Sat, 21 Jan 2006 03:58:21 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0EWK-0005ip-K3 for v6ops-data@psg.com; Sat, 21 Jan 2006 08:54:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.158] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0EWJ-0005id-U6 for v6ops@ops.ietf.org; Sat, 21 Jan 2006 08:54:51 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Sat, 21 Jan 2006 00:54:50 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYdvUtUBxUg6dq7TAuGwAMfr8QxkQAp6B9w From: "Vishwas Manral" To: "Brian E Carpenter" Cc: "Pekka Savola" , "Bora Akyol" , "Fred Baker" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, That is exactly what I am trying to say too. For cases where we need to do deep packet inspection, if we could guarantee the flow label is not mutable etc it could be used. Examples of which could be IPsec, though it is not currently done that way. Regarding Alain Durand's question, I agree the field is just as mutable as the DSCP field or any other field in the outer header. Currently in IPsec to identify an outgoing SA we could use the protocol as well as port numbers (an SA for an application) and in a few cases we may not have all the inner header information. Having a flow Label helps in this case. We could have protected it using AH. However for backward compatibility reasons this is not done (as has been pointed out earlier by Fred). Using flow label could make the work of on-path devices which do deeper packet inspection in some cases easier. Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 Sent: Friday, January 20, 2006 6:00 PM To: Vishwas Manral Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org Subject: Re: Flow label and its uses Vishwas Manral wrote: >... I am sure things like load balancing which require > deeper packet inspection can also be done. The whole point is that you will not need deep packet inspection if the flow label is set by the source. Brian From owner-v6ops@ops.ietf.org Sat Jan 21 06:54:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0HJq-00062j-Gy for v6ops-archive@megatron.ietf.org; Sat, 21 Jan 2006 06:54:10 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25194 for ; Sat, 21 Jan 2006 06:52:41 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0HHv-000G4P-I5 for v6ops-data@psg.com; Sat, 21 Jan 2006 11:52:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE autolearn=no version=3.1.0 Received: from [64.102.19.199] (helo=av-tac-rtp.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0HHu-000G4D-K2 for v6ops@ops.ietf.org; Sat, 21 Jan 2006 11:52:11 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k0LBq9j01515 for ; Sat, 21 Jan 2006 06:52:09 -0500 (EST) Received: from gvandeve-w2k01.cisco.com (sjc-vpn7-64.cisco.com [10.21.144.64]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id k0LBpqC22887 for ; Sat, 21 Jan 2006 12:51:52 +0100 (CET) Message-Id: <4.3.2.7.2.20060121124221.0330b898@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 21 Jan 2006 12:51:48 +0100 To: v6ops@ops.ietf.org From: "Gunter Van de Velde (gvandeve)" Subject: RE: Flow label and its uses In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-v6ops@ops.ietf.org Precedence: bulk So in an ideal world where everything behind the IPSec header is encrypted (if that ever would be the case) .... then how to do load-balancing as Brian suggest? Maybe the flow-label needs to be *just* an identifier without further meaning? In that case it does make sense that its unchanged between end-2-end. I don't see why it has to be an extension to DSCP? DSCP provides a mechanism to give an indication how the traffic would like to be treated while flow label could give an indication of flow without knowing the upper layer details. These are different operations i think. G/ At 00:54 21/01/2006 -0800, Vishwas Manral wrote: >Brian, > >That is exactly what I am trying to say too. For cases where we need to >do deep packet inspection, if we could guarantee the flow label is not >mutable etc it could be used. Examples of which could be IPsec, though >it is not currently done that way. > >Regarding Alain Durand's question, I agree the field is just as mutable >as the DSCP field or any other field in the outer header. Currently in >IPsec to identify an outgoing SA we could use the protocol as well as >port numbers (an SA for an application) and in a few cases we may not >have all the inner header information. Having a flow Label helps in this >case. > >We could have protected it using AH. However for backward compatibility >reasons this is not done (as has been pointed out earlier by Fred). > >Using flow label could make the work of on-path devices which do deeper >packet inspection in some cases easier. > >Thanks, >Vishwas >-----Original Message----- >From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >Sent: Friday, January 20, 2006 6:00 PM >To: Vishwas Manral >Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org >Subject: Re: Flow label and its uses > >Vishwas Manral wrote: > >... I am sure things like load balancing which require > > deeper packet inspection can also be done. > >The whole point is that you will not need deep packet inspection >if the flow label is set by the source. > > Brian From owner-v6ops@ops.ietf.org Sat Jan 21 09:28:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0Jim-0006Oe-Ti for v6ops-archive@megatron.ietf.org; Sat, 21 Jan 2006 09:28:05 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03383 for ; Sat, 21 Jan 2006 09:26:36 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0JfR-000PVH-4z for v6ops-data@psg.com; Sat, 21 Jan 2006 14:24:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, PRICES_ARE_AFFORDABLE autolearn=no version=3.1.0 Received: from [204.127.202.59] (helo=sccrmhc14.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0JfQ-000PV4-B6 for v6ops@ops.ietf.org; Sat, 21 Jan 2006 14:24:36 +0000 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (sccrmhc14) with SMTP id <2006012114243501400kk5a4e>; Sat, 21 Jan 2006 14:24:35 +0000 Message-ID: <04bc01c61e96$3bb47e10$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: Subject: Re: Flow label and its uses Date: Sat, 21 Jan 2006 08:23:21 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I'm out of the "deep packet inspection" business for now, but I did spend about 18 months building products in this space... Although in a perfect world it would be lovely to know that flow labels didn't change end-to-end, if that lovely thought requires a per-packet AH operation on middleboxes, it's probably beyond what people can build and sell at affordable prices now, and (since end-to-end AH would be using CPU at each endpoint, while a middlebox verifying AH has to use its own CPU for all the packets it processes), Moore's Law doesn't seem all that helpful in planning for the future, either. Maybe the RFC 3514 Security Bit from IPv4 should have an IPv6 counterpart that says, "I promise that this packet is AH protected and hasn't been dorked with, so you can believe the flow label"? That would help a lot... :-) Spencer From: "Vishwas Manral" To: "Brian E Carpenter" Cc: "Pekka Savola" ; "Bora Akyol" ; "Fred Baker" ; Sent: Saturday, January 21, 2006 2:54 AM Subject: RE: Flow label and its uses Brian, That is exactly what I am trying to say too. For cases where we need to do deep packet inspection, if we could guarantee the flow label is not mutable etc it could be used. Examples of which could be IPsec, though it is not currently done that way. Regarding Alain Durand's question, I agree the field is just as mutable as the DSCP field or any other field in the outer header. Currently in IPsec to identify an outgoing SA we could use the protocol as well as port numbers (an SA for an application) and in a few cases we may not have all the inner header information. Having a flow Label helps in this case. We could have protected it using AH. However for backward compatibility reasons this is not done (as has been pointed out earlier by Fred). Using flow label could make the work of on-path devices which do deeper packet inspection in some cases easier. Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Friday, January 20, 2006 6:00 PM To: Vishwas Manral Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org Subject: Re: Flow label and its uses Vishwas Manral wrote: >... I am sure things like load balancing which require > deeper packet inspection can also be done. The whole point is that you will not need deep packet inspection if the flow label is set by the source. Brian From owner-v6ops@ops.ietf.org Sun Jan 22 23:50:47 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0tfD-00043s-Ip for v6ops-archive@megatron.ietf.org; Sun, 22 Jan 2006 23:50:47 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14946 for ; Sun, 22 Jan 2006 23:49:18 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0tbV-0003WP-DL for v6ops-data@psg.com; Mon, 23 Jan 2006 04:46:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [63.197.255.158] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0tbU-0003Vp-Ja for v6ops@ops.ietf.org; Mon, 23 Jan 2006 04:46:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Sun, 22 Jan 2006 20:46:53 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYehGECC5E3lQ1GQxaZCfXl19VdRgBU65iw From: "Vishwas Manral" To: "Gunter Van de Velde \(gvandeve\)" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Gunter, Let me answer you, if I understand the questions you raise correctly. Currently Load Balancing could be done based on the 5-tuple fields in the packet. However in case the fields are not available we could fall to some default criteria. With the flow-label present, we could instead use the Source-IP, Destination-IP and the flow label. These would be present in all IP packets. I agree flow-label should be used as an identifier for a flow (as the name suggests). Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) Sent: Saturday, January 21, 2006 5:22 PM To: v6ops@ops.ietf.org Subject: RE: Flow label and its uses So in an ideal world where everything behind the IPSec header is encrypted (if that ever would be the case) .... then how to do load-balancing as Brian suggest? Maybe the flow-label needs to be *just* an identifier without further meaning? In that case it does make sense that its unchanged between end-2-end. I don't see why it has to be an extension to DSCP? DSCP provides a mechanism to give an indication how the traffic would like to be treated while flow label could give an indication of flow without knowing the upper layer details. These are different operations i think. G/ At 00:54 21/01/2006 -0800, Vishwas Manral wrote: >Brian, > >That is exactly what I am trying to say too. For cases where we need to >do deep packet inspection, if we could guarantee the flow label is not >mutable etc it could be used. Examples of which could be IPsec, though >it is not currently done that way. > >Regarding Alain Durand's question, I agree the field is just as mutable >as the DSCP field or any other field in the outer header. Currently in >IPsec to identify an outgoing SA we could use the protocol as well as >port numbers (an SA for an application) and in a few cases we may not >have all the inner header information. Having a flow Label helps in this >case. > >We could have protected it using AH. However for backward compatibility >reasons this is not done (as has been pointed out earlier by Fred). > >Using flow label could make the work of on-path devices which do deeper >packet inspection in some cases easier. > >Thanks, >Vishwas >-----Original Message----- >From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >Sent: Friday, January 20, 2006 6:00 PM >To: Vishwas Manral >Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org >Subject: Re: Flow label and its uses > >Vishwas Manral wrote: > >... I am sure things like load balancing which require > > deeper packet inspection can also be done. > >The whole point is that you will not need deep packet inspection >if the flow label is set by the source. > > Brian From owner-v6ops@ops.ietf.org Mon Jan 23 00:04:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F0tsp-0006oV-R5 for v6ops-archive@megatron.ietf.org; Mon, 23 Jan 2006 00:04:51 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15842 for ; Mon, 23 Jan 2006 00:03:22 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0ts1-0004Hu-Jf for v6ops-data@psg.com; Mon, 23 Jan 2006 05:04:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00, PRICES_ARE_AFFORDABLE autolearn=no version=3.1.0 Received: from [63.197.255.158] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F0ts1-0004Hh-1v for v6ops@ops.ietf.org; Mon, 23 Jan 2006 05:04:01 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Sun, 22 Jan 2006 21:04:00 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYem0Y8vnJS49DISUC5vZbqq7fvjABPbYag From: "Vishwas Manral" To: "Spencer Dawkins" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Spencer, I may be missing the point; however I would like to understand what you mean. In IPsec for the SG-to-SG assume a case where we get a plain packet. By processing fields in the packet (could be DSCP field, Source Destination address, protocol field, upper header message type etc) we decide the out going SA identified by an SPI. The packet reaches the tunnel tail end and using the SPI we identify the incoming tunnel and authenticate/ decrypt the packet. What I have been saying is that, just as we use fields in the plain packet to identify an outgoing SA, we could (instead of using a 5-tuple) use a flow label, which is available in all packets. The 5-tuple may not be available in all IP packets.=20 It would be nice to understand how this is equivalent to setting the "Security Bit"? Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Spencer Dawkins Sent: Saturday, January 21, 2006 7:53 PM To: v6ops@ops.ietf.org Subject: Re: Flow label and its uses I'm out of the "deep packet inspection" business for now, but I did spend=20 about 18 months building products in this space... Although in a perfect world it would be lovely to know that flow labels=20 didn't change end-to-end, if that lovely thought requires a per-packet AH=20 operation on middleboxes, it's probably beyond what people can build and sell at affordable prices now, and (since end-to-end AH would be using CPU=20 at each endpoint, while a middlebox verifying AH has to use its own CPU for=20 all the packets it processes), Moore's Law doesn't seem all that helpful in=20 planning for the future, either. Maybe the RFC 3514 Security Bit from IPv4 should have an IPv6 counterpart=20 that says, "I promise that this packet is AH protected and hasn't been=20 dorked with, so you can believe the flow label"? That would help a lot... :-) Spencer From: "Vishwas Manral" To: "Brian E Carpenter" Cc: "Pekka Savola" ; "Bora Akyol" ;=20 "Fred Baker" ; Sent: Saturday, January 21, 2006 2:54 AM Subject: RE: Flow label and its uses Brian, That is exactly what I am trying to say too. For cases where we need to do deep packet inspection, if we could guarantee the flow label is not mutable etc it could be used. Examples of which could be IPsec, though it is not currently done that way. Regarding Alain Durand's question, I agree the field is just as mutable as the DSCP field or any other field in the outer header. Currently in IPsec to identify an outgoing SA we could use the protocol as well as port numbers (an SA for an application) and in a few cases we may not have all the inner header information. Having a flow Label helps in this case. We could have protected it using AH. However for backward compatibility reasons this is not done (as has been pointed out earlier by Fred). Using flow label could make the work of on-path devices which do deeper packet inspection in some cases easier. Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Friday, January 20, 2006 6:00 PM To: Vishwas Manral Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org Subject: Re: Flow label and its uses Vishwas Manral wrote: >... I am sure things like load balancing which require > deeper packet inspection can also be done. The whole point is that you will not need deep packet inspection if the flow label is set by the source. Brian From owner-v6ops@ops.ietf.org Mon Jan 23 08:27:54 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F11je-0005Pc-Fw for v6ops-archive@megatron.ietf.org; Mon, 23 Jan 2006 08:27:54 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17473 for ; Mon, 23 Jan 2006 08:26:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F11gp-0001KI-Gt for v6ops-data@psg.com; Mon, 23 Jan 2006 13:24:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00, PRICES_ARE_AFFORDABLE autolearn=no version=3.1.0 Received: from [63.240.77.83] (helo=sccrmhc13.comcast.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F11go-0001Ju-D1 for v6ops@ops.ietf.org; Mon, 23 Jan 2006 13:24:58 +0000 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (sccrmhc13) with SMTP id <2006012313245701300gi1uje>; Mon, 23 Jan 2006 13:24:57 +0000 Message-ID: <082501c62020$39462b20$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: Subject: Re: Flow label and its uses Date: Mon, 23 Jan 2006 07:23:38 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Vishwas, The point I was trying to make was that since flow labels are unprotected, you can use them unless you must trust them. Having a device that alters flow labels for some random reason in the middle of the network basically says we couldn't use flow labels to correlate packet captures taken at two points in the network. If we could trust them (AH-protected), we could use them, but a per-packet AH operation to make sure we can trust them isn't reasonable, in our situation. Sorry if this wasn't clear. Spencer From: "Vishwas Manral" To: "Spencer Dawkins" ; Sent: Sunday, January 22, 2006 11:04 PM Subject: RE: Flow label and its uses Hi Spencer, I may be missing the point; however I would like to understand what you mean. In IPsec for the SG-to-SG assume a case where we get a plain packet. By processing fields in the packet (could be DSCP field, Source Destination address, protocol field, upper header message type etc) we decide the out going SA identified by an SPI. The packet reaches the tunnel tail end and using the SPI we identify the incoming tunnel and authenticate/ decrypt the packet. What I have been saying is that, just as we use fields in the plain packet to identify an outgoing SA, we could (instead of using a 5-tuple) use a flow label, which is available in all packets. The 5-tuple may not be available in all IP packets. It would be nice to understand how this is equivalent to setting the "Security Bit"? Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Spencer Dawkins Sent: Saturday, January 21, 2006 7:53 PM To: v6ops@ops.ietf.org Subject: Re: Flow label and its uses I'm out of the "deep packet inspection" business for now, but I did spend about 18 months building products in this space... Although in a perfect world it would be lovely to know that flow labels didn't change end-to-end, if that lovely thought requires a per-packet AH operation on middleboxes, it's probably beyond what people can build and sell at affordable prices now, and (since end-to-end AH would be using CPU at each endpoint, while a middlebox verifying AH has to use its own CPU for all the packets it processes), Moore's Law doesn't seem all that helpful in planning for the future, either. Maybe the RFC 3514 Security Bit from IPv4 should have an IPv6 counterpart that says, "I promise that this packet is AH protected and hasn't been dorked with, so you can believe the flow label"? That would help a lot... :-) Spencer From: "Vishwas Manral" To: "Brian E Carpenter" Cc: "Pekka Savola" ; "Bora Akyol" ; "Fred Baker" ; Sent: Saturday, January 21, 2006 2:54 AM Subject: RE: Flow label and its uses Brian, That is exactly what I am trying to say too. For cases where we need to do deep packet inspection, if we could guarantee the flow label is not mutable etc it could be used. Examples of which could be IPsec, though it is not currently done that way. Regarding Alain Durand's question, I agree the field is just as mutable as the DSCP field or any other field in the outer header. Currently in IPsec to identify an outgoing SA we could use the protocol as well as port numbers (an SA for an application) and in a few cases we may not have all the inner header information. Having a flow Label helps in this case. We could have protected it using AH. However for backward compatibility reasons this is not done (as has been pointed out earlier by Fred). Using flow label could make the work of on-path devices which do deeper packet inspection in some cases easier. Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Friday, January 20, 2006 6:00 PM To: Vishwas Manral Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org Subject: Re: Flow label and its uses Vishwas Manral wrote: >... I am sure things like load balancing which require > deeper packet inspection can also be done. The whole point is that you will not need deep packet inspection if the flow label is set by the source. Brian From 629farnham@about.com Wed Jan 25 22:40:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1xzX-0000hy-3E for v6ops-archive@megatron.ietf.org; Wed, 25 Jan 2006 22:40:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04263 for ; Wed, 25 Jan 2006 22:38:38 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F1y9I-00029V-DY for v6ops-archive@ietf.org; Wed, 25 Jan 2006 22:50:23 -0500 Received: from [221.165.140.110] (helo=221.165.140.110) by mx2.foretec.com with smtp (Exim 4.24) id 1F1xzK-0000p3-Sy for v6ops-archive@ietf.org; Wed, 25 Jan 2006 22:39:59 -0500 Message-ID: <53e001c6221f$bb01a0aa$eec9ff3a@about.com> From: "Steven A. Norman" <629farnham@about.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?Um9sZXggZm9yICQyNDkuOTU=?= Date: Thu, 26 Jan 2006 02:23:37 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_8463A5B2.7B407523" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 1.4 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 This is a multi-part message in MIME format. ------=_NextPart_000_0000_8463A5B2.7B407523 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_064719FF.5B19121F" ------=_NextPart_001_0001_064719FF.5B19121F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit REPLICA WATCH MODELS - exact copies of V.I.P. watches - perfect as a gift for your colleagues and friends - free gift box Rolex, Patek Philippe, Omega Cartier, Bvlgari, Franck Muller .. and 15 other most famous manufacturers. http://www.watches-vip.com All watches are for only $239.95 - $279.95! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_064719FF.5B19121F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
REPLICA WATCH MODELS

- exact copies of V.I.P. watches
- perfect as a gift for your colleagues and friends
- free gift box

Rolex, Patek Philippe, Omega
Cartier, Bvlgari, Franck Muller

.. and 15 other most famous manufacturers.

http://www.watches-vip.com

All watches are for only $239.95 - $279.95!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_064719FF.5B19121F-- ------=_NextPart_000_0000_8463A5B2.7B407523-- From owner-v6ops@ops.ietf.org Fri Jan 27 01:35:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2NCm-0003iU-D1 for v6ops-archive@megatron.ietf.org; Fri, 27 Jan 2006 01:35:32 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12322 for ; Fri, 27 Jan 2006 01:33:59 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2N8S-0009WT-HG for v6ops-data@psg.com; Fri, 27 Jan 2006 06:31:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, PRICES_ARE_AFFORDABLE,RCVD_IN_SORBS_WEB autolearn=no version=3.1.0 Received: from [63.197.255.131] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2N8Q-0009WA-4l for v6ops@ops.ietf.org; Fri, 27 Jan 2006 06:31:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Thu, 26 Jan 2006 22:30:59 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYgJVHP0JiwzkNBRZ6ENkee1G6TRAC5hmKQ From: "Vishwas Manral" To: "Spencer Dawkins" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Spencer, I agree relying on the Flow-label when it traverses the unprotected network may not be the best option.=20 However in the tunnel mode case, I do not think that issue will arise; besides at the tunnel tail egress we will not really check the flow-label to identify an SA, but an SPI. DSCP fields are used the same way already (we use it to identify an outgoing tunnel and don't use it for identifying an incoming one). Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Spencer Dawkins Sent: Monday, January 23, 2006 6:54 PM To: v6ops@ops.ietf.org Subject: Re: Flow label and its uses Hi, Vishwas, The point I was trying to make was that since flow labels are unprotected,=20 you can use them unless you must trust them. Having a device that alters flow labels for some random reason in the middle=20 of the network basically says we couldn't use flow labels to correlate=20 packet captures taken at two points in the network. If we could trust them=20 (AH-protected), we could use them, but a per-packet AH operation to make sure we can trust them isn't reasonable, in our situation. Sorry if this wasn't clear. Spencer From: "Vishwas Manral" To: "Spencer Dawkins" ; Sent: Sunday, January 22, 2006 11:04 PM Subject: RE: Flow label and its uses Hi Spencer, I may be missing the point; however I would like to understand what you mean. In IPsec for the SG-to-SG assume a case where we get a plain packet. By processing fields in the packet (could be DSCP field, Source Destination address, protocol field, upper header message type etc) we decide the out going SA identified by an SPI. The packet reaches the tunnel tail end and using the SPI we identify the incoming tunnel and authenticate/ decrypt the packet. What I have been saying is that, just as we use fields in the plain packet to identify an outgoing SA, we could (instead of using a 5-tuple) use a flow label, which is available in all packets. The 5-tuple may not be available in all IP packets. It would be nice to understand how this is equivalent to setting the "Security Bit"? Thanks, Vishwas -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Spencer Dawkins Sent: Saturday, January 21, 2006 7:53 PM To: v6ops@ops.ietf.org Subject: Re: Flow label and its uses I'm out of the "deep packet inspection" business for now, but I did spend about 18 months building products in this space... Although in a perfect world it would be lovely to know that flow labels didn't change end-to-end, if that lovely thought requires a per-packet AH operation on middleboxes, it's probably beyond what people can build and sell at affordable prices now, and (since end-to-end AH would be using CPU at each endpoint, while a middlebox verifying AH has to use its own CPU for all the packets it processes), Moore's Law doesn't seem all that helpful in planning for the future, either. Maybe the RFC 3514 Security Bit from IPv4 should have an IPv6 counterpart that says, "I promise that this packet is AH protected and hasn't been dorked with, so you can believe the flow label"? That would help a lot... :-) Spencer From: "Vishwas Manral" To: "Brian E Carpenter" Cc: "Pekka Savola" ; "Bora Akyol" ; "Fred Baker" ; Sent: Saturday, January 21, 2006 2:54 AM Subject: RE: Flow label and its uses Brian, That is exactly what I am trying to say too. For cases where we need to do deep packet inspection, if we could guarantee the flow label is not mutable etc it could be used. Examples of which could be IPsec, though it is not currently done that way. Regarding Alain Durand's question, I agree the field is just as mutable as the DSCP field or any other field in the outer header. Currently in IPsec to identify an outgoing SA we could use the protocol as well as port numbers (an SA for an application) and in a few cases we may not have all the inner header information. Having a flow Label helps in this case. We could have protected it using AH. However for backward compatibility reasons this is not done (as has been pointed out earlier by Fred). Using flow label could make the work of on-path devices which do deeper packet inspection in some cases easier. Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Friday, January 20, 2006 6:00 PM To: Vishwas Manral Cc: Pekka Savola; Bora Akyol; Fred Baker; v6ops@ops.ietf.org Subject: Re: Flow label and its uses Vishwas Manral wrote: >... I am sure things like load balancing which require > deeper packet inspection can also be done. The whole point is that you will not need deep packet inspection if the flow label is set by the source. Brian From necojp@citiz.net Sat Jan 28 00:43:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2irg-0002sr-VJ for v6ops-archive@megatron.ietf.org; Sat, 28 Jan 2006 00:43:12 -0500 Received: from a-net.ne.jp ([221.212.56.218]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28169 for ; Sat, 28 Jan 2006 00:41:36 -0500 (EST) Date: Sat, 28 Jan 2006 00:41:36 -0500 (EST) Message-Id: <200601280541.AAA28169@ietf.org> Received: from hxdkk2 (unknown [144.50.10.137]) by smtp11 (Coremail) with SMTP id RyWk8MJuu6m6ew5u.1 for ; Sat, 28 Jan 2006 14:43:33 +0800 (CST) X-Originating-IP: [144.50.10.137] Subject: =?iso-2022-jp?B?GyRCSGtMKTg3PGkkSyRGNGokJCReJDkbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: 7bit -　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　 突然ですが今まで出会い系サイトで確実に出会えたことありますか？ 当サイトは今までの出会い系サイトと違い高確立で出会う事ができます。 実績があるため、自信を持って推奨できるサイトになっています。 上記の様に穴場サイトになっている為あまり広めないで頂きたいと思っています。 きっと貴方様の今までの思いを叶えられる事でしょう。 存分に美味しい思いをして下さい。 きっと貴方様自身当サイトを誰にも教えたくなくなると思います。 完全無料なので一度お試しして頂く価値はかなりあると思います。 長々と長文失礼致しました。 最後まで読んで頂きありがとうございました。 -　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　-　 http://www.deai-style.net/casanova/?1926 メール不要な方はこちら↓ concept_net@yahoo.ca From necojp@citiz.net Sun Jan 29 20:58:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OJe-0002Rc-Is for v6ops-archive@megatron.ietf.org; Sun, 29 Jan 2006 20:58:50 -0500 Received: from a-net.ne.jp ([221.212.58.115]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16699 for ; Sun, 29 Jan 2006 20:57:13 -0500 (EST) Date: Sun, 29 Jan 2006 20:57:13 -0500 (EST) Message-Id: <200601300157.UAA16699@ietf.org> Received: from zai9 (unknown [102.191.132.204]) by smtp67 (Coremail) with SMTP id 3icWHjUobyBtcW3s.1 for ; Mon, 30 Jan 2006 10:58:51 +0800 (CST) X-Originating-IP: [102.191.132.204] Subject: =?iso-2022-jp?B?GyRCJCo0aiQkJEckLSReJDskcyQrISkbKEI=?= From: =?gb2312?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0044_01C61E06.DDF6BD90" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0044_01C61E06.DDF6BD90 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 今回、誠に勝手なご連絡をさせて頂きまして申し訳ありません。 ※イベント【秘密パーティ】の近日開催決定のご報告及び、 それに伴いまして、男性様・女性様の限定枠が不足しているため 急募依頼のお知らせで御座います。 ※イベントは既に、予定限定人数にて各地域開催予定会場を ピックアップ《男性13名様・女性8名様》の人数不足という現状 にあります。　注)各地域不足人数は異なります！ つきましては、貴方様に今回のご案内内容にご同意頂ける様であ れば【秘密パーティ】にご参加を頂きたく、イベント開催告知という形での ご連絡とさせて頂いております。 ◆ご賛同ご希望はこちら↓ http://www.deai-style.net/casanova/?1934 【秘密パーティ】のプログラムは以下の様になります。 ●独身女性20代前半〜45才迄の女性様方との個室お食事会 （男性様10名／女性様25名） ●お食事後30分間のフリータイム制 ●男女1対1のカップルに成られまして別室へ移動 　今後様々なお約束をお取次ぎ下さい。 ※この際男女カップルに成りそびれる事は決して無い様手配をさ せて頂きます ●お相手の女性様より、肉体関係のお相手として契約成立の際は貴方様 　への謝礼金を無条件にてお受け取り可能となっております。 　 ※貴方様への謝礼金は、女性様が貴方様へ感謝の気持ちで直接貴方 様へお渡しするので貴方様が全額受け取れます。 今回少数人数限定のご応募になっていますので定員数をオーバーさ れますとご賛同していただけましても【秘密パーティ】にご参加頂けない場 合も御座いますので予めご了承くださいます様お願いいたします。 その際は【秘密パーティ】と同様なイベントに【最優先】でご参加可能な 手続きを取らせていただきます。 http://www.deai-style.net/casanova/?1934 メール不要の方はこちら↓ concept_net@yahoo.ca ------=_NextPart_000_0044_01C61E06.DDF6BD90 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$B:#2s!"@?$K>!=1B$B"(%$%Y%s%H!ZHkL)%Q!<%F%#![$N6aF|3+:E7hDj$N$4Js9p5Z$S!"=1B(= B
=1B$B$=3D$l$KH<$$$^$7$F!"CK@-MM!&=3Dw@-MM$N8BDjOH$,ITB-$7$F$$$k$?$a=1B= (B
=1B$B5^Jg0MMj$N$*CN$i$;$G8f:B$$$^$9!#=1B(B
 
=1B$B"(%$%Y%s%H$O4{$K!"M=3DDj8BDj?M?t$K$F3FCO0h3+:EM=3DDj2q>l$r=1B= (B
=1B$B%T%C%/%"%C%W!TCK@-=1B(B13=1B$BL>MM!&=3Dw@-=1B(B8=1B$BL>MM!U$N?= M?tITB-$H$$$&8=3D>u=1B(B
=1B$B$K$"$j$^$9!#!!Cm=1B(B)=1B$B3FCO0hITB-?M?= t$O0[$J$j$^$9!*=1B(B
 
=1B$B$D$-$^$7$F$O!"5.J}MM$K:#2s$N$40FFbFbMF$K$4F10UD:$1$kMM$G$"=1B= (B
=1B$B$l$P!ZHkL)%Q!<%F%#![$K$4;22C$rD:$-$?$/!"%$%Y%s%H3+:E9pCN$H$$$&= 7A$G$N=1B(B
=1B$B$4O"Mm$H$5$;$FD:$$$F$*$j$^$9!#=1B(B
 
=1B$B"!$4;?F1$44uK>$O$3$A$i"-=1B(B
http://www.deai-style.n= et/casanova/?1934
 

=1B$B!ZHkL)%Q!<%F%#![$N%W%m%0%i%`$O0J2<$NMM$K$J$j$^$9!#=1B(B
= =1B$B!|FH?H=3Dw@-=1B(B20=1B$BBeA0H>!A=1B(B45=1B$B:MKx$N=3Dw@-MMJ}$H$N8D<<= $*?);v2q=1B(B
=1B$B!JCK@-MM=1B(B10=1B$BL>!?=3Dw@-MM=1B(B25=1B$BL>!K=1B= (B
 
=1B$B!|$*?);v8e=1B(B30=1B$BJ,4V$N%U%j!<%?%$%`@)=1B(B
 
=1B$B!|CK=3Dw=1B(B1=1B$BBP=1B(B1=1B$B$N%+%C%W%k$K@.$i$l$^$7$FJL<<$X0= \F0=1B(B
=1B$B!!:#8eMM!9$J$*LsB+$r$*
 
=1B$B"($3$N:]CK=3Dw%+%C%W%k$K@.$j$=3D$S$l$k;v$O7h$7$FL5$$MM=1B$B$;$FD:$-$^$9=1B(B
 
=1B$B!|$*Aj=1B$B!!$X$Nr7o$K$F$*=1B$B!!=1B(B
=1B$B"(5.J}MM$X$N@\5.J}=1B(B
=1B$BMM$X$*EO$7$9$k$N$G5.J}MM$,A43[
 
=1B$B:#2s>/?t?M?t8BDj$N$41~Jg$K$J$C$F$$$^$9$N$GDj0w?t$r%*!<%P!<$5=1B= (B
=1B$B$l$^$9$H$4;?F1$7$F$$$?$@$1$^$7$F$b!ZHkL)%Q!<%F%#![$K$4;22CD:$1= $J$$>l=1B(B
=1B$B9g$b8f:B$$$^$9$N$GM=3D$a$4N;>5$/$@$5$$$^$9MM$*4j$$$$$= ?$7$^$9!#=1B(B
=1B$B$=3D$N:]$O!ZHkL)%Q!<%F%#![$HF1MM$J%$%Y%s%H$K!Z:GM%= @h![$G$4;22C2DG=3D$J=1B(B
=1B$B
http://www.deai-style.n= et/casanova/?1934
 
 
 
 
 

=1B$B%a!<%kITMW$NJ}$O$3$A$i"-=1B(B
concept_net@yahoo.ca
------=_NextPart_000_0044_01C61E06.DDF6BD90-- From owner-v6ops@ops.ietf.org Sun Jan 29 21:03:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3OO2-00032W-Mm for v6ops-archive@megatron.ietf.org; Sun, 29 Jan 2006 21:03:23 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17170 for ; Sun, 29 Jan 2006 21:01:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3OJ0-0007TC-R5 for v6ops-data@psg.com; Mon, 30 Jan 2006 01:58:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3OIz-0007Sg-Pg for v6ops@ops.ietf.org; Mon, 30 Jan 2006 01:58:10 +0000 Received: from [10.10.10.101] by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001592877.msg for ; Mon, 30 Jan 2006 03:00:31 +0100 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Mon, 30 Jan 2006 02:57:56 +0100 Subject: Teredo assignements by IANA From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: Thread-Topic: Teredo assignements by IANA Thread-Index: AcYlQJaD1TiCGpEzEdqvOQANky3PwA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:060130:v6ops@ops.ietf.org::fJxHPj+3stomMs60:00000000000000000000000000000000000000000002wEb X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 30 Jan 2006 03:00:33 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, It seems that we missed this before ;-) IANA assigned for Teredo, on January 10th 2006: 2001:0000::/32 Also an IPv4 multicast address: 224.0.0.253 Teredo Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Jan 29 21:43:01 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3P0N-0000uu-7b for v6ops-archive@megatron.ietf.org; Sun, 29 Jan 2006 21:43:01 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19447 for ; Sun, 29 Jan 2006 21:41:14 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3OzR-0009Gp-90 for v6ops-data@psg.com; Mon, 30 Jan 2006 02:42:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from [213.136.24.43] (helo=purgatory.unfix.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3OzQ-0009G0-4t for v6ops@ops.ietf.org; Mon, 30 Jan 2006 02:42:00 +0000 Received: from [IPv6:2001:7b8:20d:0:20f:b5ff:fe92:159b] (unknown [IPv6:2001:7b8:20d:0:20f:b5ff:fe92:159b]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id B88E97F4C; Mon, 30 Jan 2006 03:41:56 +0100 (CET) Message-ID: <43DD7CB8.60909@unfix.org> Date: Mon, 30 Jan 2006 03:40:56 +0100 From: Jeroen Massar Organization: Unfix User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: jordi.palet@consulintel.es CC: "v6ops@ops.ietf.org" Subject: Re: Teredo assignements by IANA References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 OpenPGP: id=333E7C23; url=http://unfix.org/~jeroen/jeroen-unfix.org-pgpkey Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E8FB116BBC081C49AA781E2" Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E8FB116BBC081C49AA781E2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable JORDI PALET MARTINEZ wrote: [..] > IANA assigned for Teredo, on January 10th 2006: >=20 > 2001:0000::/32 Good catch as there indeed was no announcement of this afaik. What I am wondering though is what we can conclude from point 1 at http://www.iana.org/assignments/ipv6-unicast-address-assignmen= ts 8<------------ 2001:0000::/23 IANA 01 Jul 99 [1] [7] =2E.. [1] The prefix assigned to the IANA, 2001:0000::/23, is for assignment for testing, experimental and trial usage by IANA [RFC2928]. =2E.. [7] 2001:0000::/32 has been allocated for Teredo on 10 Jan 2006, see RFC-huitema-v6ops-teredo-05.txt. ------------>8 Does this mean that Teredo is 'testing, experimental, trial' or is it here to stay, just like 6to4? I hope it is the latter, even though it is meant for transition only. An unused prefix can always be reclaimed later in these cases. Now hope that operators of Teredo also start using 2001::/32 instead before 6/6/6 of course. Only 4 months left till the end of the 6bone... Greets, Jeroen --------------enig5E8FB116BBC081C49AA781E2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iD8DBQFD3Xy9KaooUjM+fCMRAlj4AJ9OhZ6NylcdVx952rifyrKJSth3ZgCdEbkw 9YCpvtcX0AHFn6J83IqO4l4= =Ekjd -----END PGP SIGNATURE----- --------------enig5E8FB116BBC081C49AA781E2-- From owner-v6ops@ops.ietf.org Sun Jan 29 23:29:19 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3QfG-0006oh-Nh for v6ops-archive@megatron.ietf.org; Sun, 29 Jan 2006 23:29:19 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24892 for ; Sun, 29 Jan 2006 23:27:44 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3Qd0-000DFa-I1 for v6ops-data@psg.com; Mon, 30 Jan 2006 04:26:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.0 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3Qcz-000DFO-SB for v6ops@ops.ietf.org; Mon, 30 Jan 2006 04:26:57 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Sun, 29 Jan 2006 20:26:56 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 20:26:56 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 20:26:56 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.88]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 20:26:56 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Teredo assignements by IANA Date: Sun, 29 Jan 2006 20:26:54 -0800 Message-ID: In-Reply-To: <43DD7CB8.60909@unfix.org> Thread-Topic: Teredo assignements by IANA thread-index: AcYlR0z4LbZyFCE3QEGZ/6TD5HJ0mQADbf0w From: "Christian Huitema" To: "Jeroen Massar" , Cc: X-OriginalArrivalTime: 30 Jan 2006 04:26:56.0249 (UTC) FILETIME=[6751A690:01C62555] Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > > IANA assigned for Teredo, on January 10th 2006: > > > > 2001:0000::/32 >=20 > Good catch as there indeed was no announcement of this afaik. I was waiting until the actual publication of the RFC, which should come pretty soon now. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Jan 30 02:50:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3To6-0007En-IL for v6ops-archive@megatron.ietf.org; Mon, 30 Jan 2006 02:50:38 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04188 for ; Mon, 30 Jan 2006 02:49:02 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3Tlr-000LTz-VZ for v6ops-data@psg.com; Mon, 30 Jan 2006 07:48:19 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID,SPF_HELO_PASS,SPF_PASS,UNPARSEABLE_RELAY autolearn=no version=3.1.0 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3Tlr-000LTj-0z for v6ops@ops.ietf.org; Mon, 30 Jan 2006 07:48:19 +0000 Received: from miguelangel01 by consulintel.es (MDaemon.PRO.v8.0.1.R) with ESMTP id md50001593049.msg for ; Mon, 30 Jan 2006 08:50:40 +0100 Message-ID: <03fd01c62571$81487760$0a00a8c0@consulintel.es> From: "Miguel Angel Diaz" To: References: <43DD7CB8.60909@unfix.org> <03cf01c62570$64bc8880$0a00a8c0@consulintel.es> Subject: Re: Teredo assignements by IANA Date: Mon, 30 Jan 2006 08:48:01 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2670 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-RFC2646: Format=Flowed; Response X-Authenticated-Sender: miguelangel.diaz@consulintel.es X-HashCash: 1:20:060130:v6ops@ops.ietf.org::qlhntYHj3Tm8BCZU:00000000000000000000000000000000000000000003pDg X-MDRemoteIP: 85.48.128.87 X-Return-Path: miguelangel.diaz@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: miguelangel.diaz@consulintel.es X-MDAV-Processed: consulintel.es, Mon, 30 Jan 2006 08:50:42 +0100 Sender: owner-v6ops@ops.ietf.org Precedence: bulk > Jeroen Massar wrote: > > JORDI PALET MARTINEZ wrote: > [..] >> IANA assigned for Teredo, on January 10th 2006: >> >> 2001:0000::/32 > [................................] > > Now hope that operators of Teredo also start using 2001::/32 instead > before 6/6/6 of course. The point here is that both Teredo Servers/Relays and mainly Teredo Clients need to be updated to support such a new prefix. I guess the new Windows Vista will do but what about the current Windows XP users? A new service pack will be needed to update the Teredo Client but not sure all the users upgrade their O.S. Regards Miguel ********************************************** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Mon Jan 30 14:24:40 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3edk-0002TG-Ot for v6ops-archive@megatron.ietf.org; Mon, 30 Jan 2006 14:24:40 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19547 for ; Mon, 30 Jan 2006 14:23:04 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3eac-0000oN-WC for v6ops-data@psg.com; Mon, 30 Jan 2006 19:21:27 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.17] (helo=mms1.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3eac-0000oB-A5 for v6ops@ops.ietf.org; Mon, 30 Jan 2006 19:21:26 +0000 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Mon, 30 Jan 2006 11:21:17 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 981F167424; Mon, 30 Jan 2006 11:21:13 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 01E5E67432; Mon, 30 Jan 2006 11:21:04 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CUX91470; Mon, 30 Jan 2006 11:20:59 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id C7E2820501; Mon, 30 Jan 2006 11:20:59 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Mon, 30 Jan 2006 11:20:59 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36357F44@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYgJVHP0JiwzkNBRZ6ENkee1G6TRAC5hmKQALGzvQA= From: "Bora Akyol" To: "Vishwas Manral" , "Spencer Dawkins" , v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006013007; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230322E34334445363539452E303032322D412D; ENG=IBF; TS=20060130192118; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006013007_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FC0B8A610G5740649-03-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > However in the tunnel mode case, I do not think that issue=20 > will arise; besides at the tunnel tail egress we will not=20 > really check the flow-label to identify an SA, but an SPI.=20 > DSCP fields are used the same way already (we use it to=20 > identify an outgoing tunnel and don't use it for identifying=20 > an incoming one). >=20 Hi Does this mean that you are using the flow label in lieu of the regular IPSEC SP match? Thanks Bora From owner-v6ops@ops.ietf.org Tue Jan 31 05:12:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3sUa-0001cK-EN for v6ops-archive@megatron.ietf.org; Tue, 31 Jan 2006 05:12:12 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01645 for ; Tue, 31 Jan 2006 05:10:25 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3sQg-000FCo-SH for v6ops-data@psg.com; Tue, 31 Jan 2006 10:08:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_WEB autolearn=no version=3.1.0 Received: from [63.197.255.131] (helo=sinett.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F3sQg-000FCc-65 for v6ops@ops.ietf.org; Tue, 31 Jan 2006 10:08:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Flow label and its uses Date: Tue, 31 Jan 2006 02:08:05 -0800 Message-ID: Thread-Topic: Flow label and its uses Thread-Index: AcYgJVHP0JiwzkNBRZ6ENkee1G6TRAC5hmKQALGzvQAAHo0isA== From: "Vishwas Manral" To: "Bora Akyol" , "Spencer Dawkins" , Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Bora, > Does this mean that you are using the flow label in lieu > of the regular IPSEC SP match? All I am saying is just as we can have local and remote ports as selectors; we can instead use Flow Labels along with the IP addresses for the same purpose, if some assumptions can be made for the flow label.=20 Is my understanding wrong? Thanks, Vishwas -----Original Message----- From: Bora Akyol [mailto:bora@broadcom.com]=20 Sent: Tuesday, January 31, 2006 12:51 AM To: Vishwas Manral; Spencer Dawkins; v6ops@ops.ietf.org Subject: RE: Flow label and its uses =20 > However in the tunnel mode case, I do not think that issue=20 > will arise; besides at the tunnel tail egress we will not=20 > really check the flow-label to identify an SA, but an SPI.=20 > DSCP fields are used the same way already (we use it to=20 > identify an outgoing tunnel and don't use it for identifying=20 > an incoming one). >=20 Hi Does this mean that you are using the flow label in lieu of the regular IPSEC SP match? Thanks Bora From 0anu@access-one.com Tue Jan 31 11:56:45 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F3yo9-0005AV-Ij for v6ops-archive@megatron.ietf.org; Tue, 31 Jan 2006 11:56:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06441 for ; Tue, 31 Jan 2006 11:55:09 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F3yz8-00034C-Ci for v6ops-archive@ietf.org; Tue, 31 Jan 2006 12:08:07 -0500 Received: from c-68-36-194-174.hsd1.nj.comcast.net ([68.36.194.174] helo=pcp04443300pcs.verona01.nj.comcast.net) by mx2.foretec.com with smtp (Exim 4.24) id 1F3yo5-00012i-8b for v6ops-archive@ietf.org; Tue, 31 Jan 2006 11:56:43 -0500 Message-ID: From: Michael Smith <0anu@access-one.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?NCBwaWxscyAtIEZSRUUh?= Date: Tue, 31 Jan 2006 16:40:41 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_D85F91EF.28895D54" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express V6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.4 (++++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a This is a multi-part message in MIME format. ------=_NextPart_000_0000_D85F91EF.28895D54 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_EB8B259A.665ED944" ------=_NextPart_001_0001_EB8B259A.665ED944 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Viagra - Cialis - Levitra http://www.powerfulpills.net Lowest prices! Featured: Get several pills of each brand in 1 pack. P.S. Amazing bonus: Get 4 FREE Viagra pills with any order!! ________________________________ To change your mail preferences, go here ________________________________ ------=_NextPart_001_0001_EB8B259A.665ED944 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Viagra - Cialis - Levitra
http://www.powerfulpills.net

Lowest prices!
Featured: Get several pills of each brand in 1 pack.

P.S. Amazing bonus: Get 4 FREE Viagra pills with any order!!


________________________________
To change your mail preferences, go here
________________________________

------=_NextPart_001_0001_EB8B259A.665ED944-- ------=_NextPart_000_0000_D85F91EF.28895D54-- From owner-v6ops@ops.ietf.org Tue Jan 31 13:19:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F405r-0001hD-KI for v6ops-archive@megatron.ietf.org; Tue, 31 Jan 2006 13:19:13 -0500 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14961 for ; Tue, 31 Jan 2006 13:17:23 -0500 (EST) Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F402g-000EdQ-IM for v6ops-data@psg.com; Tue, 31 Jan 2006 18:15:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.0 Received: from [216.31.210.17] (helo=mms1.broadcom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F402d-000EdA-Jl for v6ops@ops.ietf.org; Tue, 31 Jan 2006 18:15:47 +0000 Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Tue, 31 Jan 2006 10:15:37 -0800 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id 62CF567422; Tue, 31 Jan 2006 10:15:37 -0800 (PST) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 0D88F67421; Tue, 31 Jan 2006 10:15:37 -0800 (PST) Received: from mail-sj1-12.sj.broadcom.com (mail-sj1-12.sj.broadcom.com [10.16.128.215]) by mail-irva-8.broadcom.com (MOS 3.7.3a-GA) with ESMTP id CVC79693; Tue, 31 Jan 2006 10:15:36 -0800 (PST) Received: from NT-SJCA-0751.brcm.ad.broadcom.com (nt-sjca-0751 [10.16.192.221]) by mail-sj1-12.sj.broadcom.com (Postfix) with ESMTP id AE43220501; Tue, 31 Jan 2006 10:15:36 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Flow label and its uses Date: Tue, 31 Jan 2006 10:15:35 -0800 Message-ID: <03235919BBDE634289BB6A0758A20B36358030@NT-SJCA-0751.brcm.ad.broadcom.com> Thread-Topic: Flow label and its uses Thread-Index: AcYgJVHP0JiwzkNBRZ6ENkee1G6TRAC5hmKQALGzvQAAHo0isAARYglg From: "Bora Akyol" To: "Vishwas Manral" , v6ops@ops.ietf.org X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006013106; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230342E34334446413742332E303032352D412D; ENG=IBF; TS=20060131181538; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006013106_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6FC176C310G5999195-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Flow label is not a field that is protected by IPSEC hence I do not think you can use this as a selector. Unless you do modifications to IKEv2, you can not also let the other end know what exactly the SP (security policy) is based on. Frankly, use of flow label as a selector would be a hack to get around the problem of the full security policy lookup in IPSEC at high speeds. The truth is that this has not been a problem for at least 4-5 years now as long as the selectors themselves are TCAM friendly. Bora > -----Original Message----- > From: Vishwas Manral [mailto:Vishwas@sinett.com]=20 > Sent: Tuesday, January 31, 2006 2:08 AM > To: Bora Akyol; Spencer Dawkins; v6ops@ops.ietf.org > Subject: RE: Flow label and its uses >=20 > Bora, >=20 > > Does this mean that you are using the flow label in lieu of the=20 > > regular IPSEC SP match? > All I am saying is just as we can have local and remote ports=20 > as selectors; we can instead use Flow Labels along with the=20 > IP addresses for the same purpose, if some assumptions can be=20 > made for the flow label.=20 >=20 > Is my understanding wrong? >=20 > Thanks, > Vishwas