From cfriacas at fccn.pt Mon Jun 1 10:13:36 2009 From: cfriacas at fccn.pt (Carlos Friacas) Date: Mon, 1 Jun 2009 09:13:36 +0100 (WEST) Subject: [IPv6] Re: www.apache.org with IPv6, not reachable ? In-Reply-To: <20090530113704.GO2776@Space.Net> References: <20090528092711.GP19455@home.opsec.eu> <4A1E59A3.9020403@spaghetti.zurich.ibm.com> <4A1E9151.4030302@surfnet.nl> <20090530113704.GO2776@Space.Net> Message-ID: On Sat, 30 May 2009, Gert Doering wrote: > Hi, > > On Thu, May 28, 2009 at 03:27:45PM +0200, Wim Biemolt wrote: >> Last time we mentiond this issue to them they replied >> >> === >> >> Yes, we have moved services back to XXXXXX (which doesn't have IPv6 >> right now :( ), because we are upgrading xxxxxx.apache.org, the >> machine that normally hosts the website. >> >> === > > IPv6 *is* "Rocket Science", after all... like "removing AAAA entries > when you know the machine will be down for a week"... > > *sigh* > > Gert Doering > -- NetMaster > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > Maybe DNS is "Rocket Science"... ;-) Cheers, Carlos From marks at bit.nl Tue Jun 2 09:26:19 2009 From: marks at bit.nl (Mark Schouten) Date: Tue, 02 Jun 2009 09:26:19 +0200 Subject: [IPv6] Re: www.apache.org with IPv6, not reachable ? In-Reply-To: <20090530113704.GO2776@Space.Net> References: <20090528092711.GP19455@home.opsec.eu> <4A1E59A3.9020403@spaghetti.zurich.ibm.com> <4A1E9151.4030302@surfnet.nl> <20090530113704.GO2776@Space.Net> Message-ID: <1243927579.24715.2.camel@maximus> On Sat, 2009-05-30 at 13:37 +0200, Gert Doering wrote: > IPv6 *is* "Rocket Science", after all... like "removing AAAA entries > when you know the machine will be down for a week"... Come on, you can't expect the guys behind apache.org to understand everything about the internets! ;) -- Mark Schouten, Unix/NOC-engineer BIT BV | info at bit.nl | +31 318 648688 MS8714-RIPE | B1FD 8E60 A184 F89A 450D A128 049B 1B19 9AD6 17FF From hardenrm at uiuc.edu Tue Jun 2 20:57:24 2009 From: hardenrm at uiuc.edu (Ryan Harden) Date: Tue, 02 Jun 2009 13:57:24 -0500 Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) Message-ID: <4A257614.3080805@uiuc.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In a conversation with my DNS admin, he brought up the fact that RFC3513 seems to forbid using a subnet size other than /64 AS WELL as using anything other than EUI-64 to determine the host ID of an address. In RFC3513: http://www.ietf.org/rfc/rfc3513.txt Section 2.5.4 Paragraph 2: "All global unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in section 2.5.1. Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field." Given 2001::/8 and 2620::/8 fit this criteria, it seems that the interface ID or HOST portion of an IPv6 address must be 64-bits long and formatted in accordance to section 2.5.1. Section 2.5.1 Paragraph 3: "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." The way I read it seems to imply staticly assigned IPv6 addresses are forbidden. Which puts a damper on securing the coveted DEAD:BEEF address for my workstation. I have not understood this to be true and have experienced practice where this is absolutely not met. I see /126s for p-t-p links, static DNS servers, static web servers, etc, etc. Am I reading this wrong? Is this RFC out of date? What is the intent of these sections in the RFC? At the very least they are unclear and/or misleading. RFC3587 Section 3, Paragraph 2 seems to confirm this: "[ARCH] also requires that all unicast addresses, except those that start with binary value 000, have Interface IDs that are 64 bits long and to be constructed in Modified EUI-64 format." /Ryan - -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 630-363-0365 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign University of Illinois - ICCN -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkoldhEACgkQtuPckBBbXbqycACgu7wfR1jM9c9VyzZU4b2rUhp7 5FAAoME1yBwmRm/DuZ8jeZuSGluWc+da =9mMt -----END PGP SIGNATURE----- From ek at google.com Tue Jun 2 21:15:29 2009 From: ek at google.com (Erik Kline) Date: Tue, 2 Jun 2009 12:15:29 -0700 Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) In-Reply-To: <4A257614.3080805@uiuc.edu> References: <4A257614.3080805@uiuc.edu> Message-ID: <2e8c64260906021215n1bb51a3fsa3da201c0ff88011@mail.gmail.com> This is really just for "Interface IDs". It's basically saying that if you're going to use Interface IDs and Stateless Address Autoconfiguration (SLAAC) and all that stuff you need to be using 64bit IIDs. That's it. IIDs != IPv6 addresses, just one way to form them. You can statically assign dead:beef, 1337:cafe, ... and put then in DNS all you want. You can have /80s, /112s, whatever. Also: 3513 was obsoleted by http://tools.ietf.org/html/rfc4291 (one reason I prefer the tools.ietf.org links). 2009/6/2 Ryan Harden > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > In a conversation with my DNS admin, he brought up the fact that RFC3513 > seems to forbid using a subnet size other than /64 AS WELL as using > anything other than EUI-64 to determine the host ID of an address. > > In RFC3513: http://www.ietf.org/rfc/rfc3513.txt > Section 2.5.4 Paragraph 2: > > "All global unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as > described in section 2.5.1. Global unicast addresses that start with > binary 000 have no such constraint on the size or structure of the > interface ID field." > > Given 2001::/8 and 2620::/8 fit this criteria, it seems that the > interface ID or HOST portion of an IPv6 address must be 64-bits long and > formatted in accordance to section 2.5.1. > > Section 2.5.1 Paragraph 3: > "For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." > > The way I read it seems to imply staticly assigned IPv6 addresses are > forbidden. Which puts a damper on securing the coveted DEAD:BEEF address > for my workstation. > > I have not understood this to be true and have experienced practice > where this is absolutely not met. I see /126s for p-t-p links, static > DNS servers, static web servers, etc, etc. > > Am I reading this wrong? Is this RFC out of date? What is the intent of > these sections in the RFC? At the very least they are unclear and/or > misleading. > > RFC3587 Section 3, Paragraph 2 seems to confirm this: > "[ARCH] also requires that all unicast addresses, except those that > start with binary value 000, have Interface IDs that are 64 bits long > and to be constructed in Modified EUI-64 format." > > /Ryan > - -- > Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 > CITES - Network Engineering Cell: 630-363-0365 > 2130 Digital Computer Lab Fax: 217-244-7089 > 1304 W. Springfield email: hardenrm at illinois.edu > Urbana, IL 61801 > > University of Illinois at Urbana/Champaign > University of Illinois - ICCN > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkoldhEACgkQtuPckBBbXbqycACgu7wfR1jM9c9VyzZU4b2rUhp7 > 5FAAoME1yBwmRm/DuZ8jeZuSGluWc+da > =9mMt > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090602/948ce9b0/attachment.html From swmike at swm.pp.se Tue Jun 2 21:18:57 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 2 Jun 2009 21:18:57 +0200 (CEST) Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) In-Reply-To: <2e8c64260906021215n1bb51a3fsa3da201c0ff88011@mail.gmail.com> References: <4A257614.3080805@uiuc.edu> <2e8c64260906021215n1bb51a3fsa3da201c0ff88011@mail.gmail.com> Message-ID: On Tue, 2 Jun 2009, Erik Kline wrote: > Also: 3513 was obsoleted by http://tools.ietf.org/html/rfc4291 (one > reason I prefer the tools.ietf.org links). >From 2.5.4 in RFC4291: "All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as described in Section 2.5.1. Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field." This still seems to imply that you really have to have a 64bit interface ID field in there, formatted per 2.5.1. So how does /126 fit into that? -- Mikael Abrahamsson email: swmike at swm.pp.se From bmanning at vacation.karoshi.com Tue Jun 2 21:41:29 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 2 Jun 2009 19:41:29 +0000 Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) In-Reply-To: References: <4A257614.3080805@uiuc.edu> <2e8c64260906021215n1bb51a3fsa3da201c0ff88011@mail.gmail.com> Message-ID: <20090602194129.GA29505@vacation.karoshi.com.> On Tue, Jun 02, 2009 at 09:18:57PM +0200, Mikael Abrahamsson wrote: > On Tue, 2 Jun 2009, Erik Kline wrote: > > >Also: 3513 was obsoleted by http://tools.ietf.org/html/rfc4291 (one > >reason I prefer the tools.ietf.org links). > > >From 2.5.4 in RFC4291: > > "All Global Unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as > described in Section 2.5.1. Global Unicast addresses that start with > binary 000 have no such constraint on the size or structure of the > interface ID field." > > This still seems to imply that you really have to have a 64bit interface > ID field in there, formatted per 2.5.1. So how does /126 fit into that? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se kind of points out that the folks who did the RFC's lost touch with operational reality some time ago. --bill From merike at doubleshotsecurity.com Tue Jun 2 21:42:40 2009 From: merike at doubleshotsecurity.com (Merike Kaeo) Date: Tue, 2 Jun 2009 12:42:40 -0700 Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) In-Reply-To: References: <4A257614.3080805@uiuc.edu> <2e8c64260906021215n1bb51a3fsa3da201c0ff88011@mail.gmail.com> Message-ID: <9F56BE69-6BE6-4118-B824-F5D1C38DCE1F@doubleshotsecurity.com> Are you going to start the /126 vs /64 pt-to-pt discussion again? :) :) Enough people do /126s and most products support it that I've come across. Although someone once did tell me "If you want to make sure it works use /64s". I typically look at what products do and while most try and conform to RFCs there's plenty of deviations. - merike On Jun 2, 2009, at 12:18 PM, Mikael Abrahamsson wrote: > On Tue, 2 Jun 2009, Erik Kline wrote: > >> Also: 3513 was obsoleted by http://tools.ietf.org/html/rfc4291 >> (one reason I prefer the tools.ietf.org links). > >> From 2.5.4 in RFC4291: > > "All Global Unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), > formatted as > described in Section 2.5.1. Global Unicast addresses that start > with > binary 000 have no such constraint on the size or structure of the > interface ID field." > > This still seems to imply that you really have to have a 64bit > interface ID field in there, formatted per 2.5.1. So how does /126 > fit into that? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From jako.andras at eik.bme.hu Tue Jun 2 21:48:19 2009 From: jako.andras at eik.bme.hu (JAKO Andras) Date: Tue, 2 Jun 2009 21:48:19 +0200 (CEST) Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) In-Reply-To: <4A257614.3080805@uiuc.edu> References: <4A257614.3080805@uiuc.edu> Message-ID: > Section 2.5.1 Paragraph 3: > "For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." > > The way I read it seems to imply staticly assigned IPv6 addresses are > forbidden. Which puts a damper on securing the coveted DEAD:BEEF address > for my workstation. Read also paragraph 4. Staticly assigned addresses are OK. Andras From gordon.stratton at oregonstate.edu Tue Jun 2 21:15:01 2009 From: gordon.stratton at oregonstate.edu (Gordon Stratton) Date: Tue, 2 Jun 2009 12:15:01 -0700 Subject: All Subnets must be /64, all hosts must use EUI-64? (According to RFC3513) In-Reply-To: <4A257614.3080805@uiuc.edu> References: <4A257614.3080805@uiuc.edu> Message-ID: <20090602191501.GA11761@3oh1.uhds.oregonstate.edu> Ryan Harden wrote: > Section 2.5.1 Paragraph 3: > "For all unicast addresses, except those that start with binary value > 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." Check out RFC 4291[1], appendix A for more information on constructing those identifiers. Long story short, creation from a 48-bit MAC identifier is just one way of doing it. You are also free to choose your own, as long as it is unique on the subnet prefix. [1] http://tools.ietf.org/html/rfc4291 From ryan at u13.net Sat Jun 6 03:29:38 2009 From: ryan at u13.net (Ryan Rawdon) Date: Fri, 05 Jun 2009 21:29:38 -0400 Subject: [IPv6] Re: www.apache.org with IPv6, not reachable ? In-Reply-To: <1243927579.24715.2.camel@maximus> References: <20090528092711.GP19455@home.opsec.eu> <4A1E59A3.9020403@spaghetti.zurich.ibm.com> <4A1E9151.4030302@surfnet.nl> <20090530113704.GO2776@Space.Net> <1243927579.24715.2.camel@maximus> Message-ID: <4A29C682.1090801@u13.net> It looks like the broken AAAA for www.apache.org has finally been removed. Hopefully they'll get the v6 access working again eventually. On 6/2/09 3:26 AM, Mark Schouten wrote: > On Sat, 2009-05-30 at 13:37 +0200, Gert Doering wrote: > >> IPv6 *is* "Rocket Science", after all... like "removing AAAA entries >> when you know the machine will be down for a week"... >> > > Come on, you can't expect the guys behind apache.org to understand > everything about the internets! ;) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090605/6fe36b4a/attachment.html From steve at ibctech.ca Sat Jun 6 03:36:53 2009 From: steve at ibctech.ca (Steve Bertrand) Date: Fri, 05 Jun 2009 21:36:53 -0400 Subject: [IPv6] Re: www.apache.org with IPv6, not reachable ? In-Reply-To: <4A29C682.1090801@u13.net> References: <20090528092711.GP19455@home.opsec.eu> <4A1E59A3.9020403@spaghetti.zurich.ibm.com> <4A1E9151.4030302@surfnet.nl> <20090530113704.GO2776@Space.Net> <1243927579.24715.2.camel@maximus> <4A29C682.1090801@u13.net> Message-ID: <4A29C835.9020301@ibctech.ca> Ryan Rawdon wrote: > It looks like the broken AAAA for www.apache.org has finally been > removed. Hopefully they'll get the v6 access working again eventually. Most importantly, hopefully they can provide a documentation trail as to exactly what had happened. I've found many ways to break connectivity by fiddling, taking servers off-line, changing DNS records, etc... A traceback from such an organization would be fantastic if it would help others prevent such a situation. Steve -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3233 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20090605/558e6c54/attachment.bin From ek at google.com Sat Jun 20 03:32:25 2009 From: ek at google.com (Erik Kline) Date: Fri, 19 Jun 2009 18:32:25 -0700 Subject: Factors, actions influencing the possibility/timing of IDR for IPv6-basedrouting domains? In-Reply-To: References: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net> <3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk> Message-ID: <2e8c64260906191832nb0d4b0ma457e017673a1347@mail.gmail.com> > But, those farms know the same thing Google knows, which is that > eventually there's going to be IPv6-only clients out there, and > they don't want those clients complaining to their own customers, > and their own customers perhaps leaving without even saying anything. > Plus, you never know exactly what Google is going to use as search > criteria. ?Google is spending big bucks on their own IPv6 deployment, > and it wouldn't be farfetched to imagine that Google might one day > quietly slip "Reachable by both IPv4 and IPv6" on to their list of > items that increase your page ranking. One thing we try to consider is that the only thing you can assume about the IP connectivity of a user making a request is the protocol over which the request was made. In other words, if a request comes in over IPv4 you can assume the user effectively has v4 access, and similarly for v6. Right now you can be *statistically* assured that a user making a v6 request has v4, but that is not 100% true now, nor will it always remain even a strong likelihood. (Of course, in theory, you can correlate several out-of-band factors to increase the accuracy of any guess about non-request-protocol availability, but why go to all that work.) So if a request comes in over v6 we serve v6 cache links in the response (bugs not withstanding :). It's theoretically possible that if the IPv4 web corpus and the IPv6 web corpus become significantly divergent that some accommodation might be made. It might be more akin to search results in a language that wasn't your detected native language, though. Too early to tell. On a different note: one thing that will be nice when v6 becomes popular with hosting providers: everyone can get a static v6 address and hence an SSL cert (i.e. we won't need SNI). -Erik From ipv6-ops at arbitraryconstant.com Wed Jun 24 07:17:23 2009 From: ipv6-ops at arbitraryconstant.com (Anthony Roberts) Date: Tue, 23 Jun 2009 23:17:23 -0600 Subject: Factors, actions influencing the possibility/timing of IDR for IPv6-basedrouting =?UTF-8?Q?domains=3F?= In-Reply-To: <2e8c64260906191832nb0d4b0ma457e017673a1347@mail.gmail.com> References: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net> <3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk> <2e8c64260906191832nb0d4b0ma457e017673a1347@mail.gmail.com> Message-ID: <39bd4837e6e9a4bf5aef9bf1c4697bdd@localhost> On Fri, 19 Jun 2009 18:32:25 -0700, Erik Kline wrote: > One thing we try to consider is that the only thing you can assume > about the IP connectivity of a user making a request is the protocol > over which the request was made. In other words, if a request comes > in over IPv4 you can assume the user effectively has v4 access, and > similarly for v6. Right now you can be *statistically* assured that a > user making a v6 request has v4, but that is not 100% true now, nor > will it always remain even a strong likelihood. (Of course, in > theory, you can correlate several out-of-band factors to increase the > accuracy of any guess about non-request-protocol availability, but why > go to all that work.) So if a request comes in over v6 we serve v6 > cache links in the response (bugs not withstanding :). > > It's theoretically possible that if the IPv4 web corpus and the IPv6 > web corpus become significantly divergent that some accommodation > might be made. It might be more akin to search results in a language > that wasn't your detected native language, though. Too early to tell. > > On a different note: one thing that will be nice when v6 becomes > popular with hosting providers: everyone can get a static v6 address > and hence an SSL cert (i.e. we won't need SNI). It's a bit of a catch-22. Websites aren't going to go AAAA-only until the clients lost by doing so are negligible, and IPv6 clients aren't going to give up v4 connectivity until the utility of v4 is negligible. If true, that means v4 will be the lowest common denominator until v6 is common enough to take over. In turn, that implies v6-only content will only be significant after a great deal of the migration is complete. Mitigation like SNI will be needed long before then. When things get bad enough, I bet we'll even see VPS/colo providers offering v4 reachable layer 7 proxies for customers who can't afford public v4 IPs. The thing I find encouraging are the NAT64 drafts, as they explicitly acknowledge and address the fact that v4 may be with us for some time to come. That may cause a problem for Google cache links though; you'll see v4 connections, and send back links with v4 IPs, but the clients will be relying on DNS translation that won't happen for web links with raw IPs. Good times. :) Regards, -Anthony From ek at google.com Thu Jun 25 00:13:01 2009 From: ek at google.com (Erik Kline) Date: Wed, 24 Jun 2009 15:13:01 -0700 Subject: Factors, actions influencing the possibility/timing of IDR for IPv6-basedrouting domains? In-Reply-To: <39bd4837e6e9a4bf5aef9bf1c4697bdd@localhost> References: <04BBB069-AF1B-4B20-8A0B-1B94F528147C@pch.net> <3E8BEB47BAAC4480A53CE6AF3D3FDC08@tedsdesk> <2e8c64260906191832nb0d4b0ma457e017673a1347@mail.gmail.com> <39bd4837e6e9a4bf5aef9bf1c4697bdd@localhost> Message-ID: <2e8c64260906241513h41030fb0g929b1a1e7324c118@mail.gmail.com> > The thing I find encouraging are the NAT64 drafts, as they explicitly > acknowledge and address the fact that v4 may be with us for some time to > come. That may cause a problem for Google cache links though; you'll see v4 > connections, and send back links with v4 IPs, but the clients will be > relying on DNS translation that won't happen for web links with raw IPs. > Good times. :) I'm not sure of this being a real problem, at least not the situation you describe. In your example a client has IPv6-only, and gets to IPv4 via NAT64 at some point in the network path. I think in this scenario we would just serve AAAAs to these IPv6-only networks and side-step the whole issue. From berni at birkenwald.de Mon Jun 29 23:44:38 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Mon, 29 Jun 2009 23:44:38 +0200 Subject: Testers wanted: isatapd Debian package Message-ID: <4A4935C6.7040401@birkenwald.de> Hi everyone, this is borderline off-topic, please don't hit reply-to-all if not necessary. Since version 2.6.25 Linux has integrated support for ISATAP (RFC5214) in the kernel. Unfortunately, without manual userspace configuration it doesn't do anything useful (as client). Sascha Hlusiak has written a small userspace configuration daemon that takes care of DNS resolution, router solicitation and periodic refresh. It is available at http://www.saschahlusiak.de/linux/isatap.htm . During the last few weeks I've been building and testing a Debian/Ubuntu package for this daemon, the results are available in my Ubuntu PPA at https://launchpad.net/~berni/+archive/ppa . Although it is labeled "jaunty" the package should install/work just fine on Debian stable and Ubuntu Intrepid or newer. If your network has a relay running on the "Windows-Standard" isatap. it should work out-of-the-box without any configuration, otherwise you need to edit /etc/default/isatapd. If you happen to run an ISATAP relay in your network please consider testing this package. If you are somewhat more experienced in the whole Debian packaging process I would be very happy if you could have a look at it and point out any errors. The package is also up on mentors.debian.net, the ultimate goal is to have it included in the Debian repository some day. Thanks a lot, Bernhard From paul.hoffman at vpnc.org Fri Jun 26 16:40:14 2009 From: paul.hoffman at vpnc.org (Paul Hoffman) Date: Fri, 26 Jun 2009 07:40:14 -0700 Subject: Request to review draft-ietf-ipsecme-ikev2-ipv6-config-01.txt Message-ID: Greetings again. I am sending this as one of the co-chairs of the IPsecME WG. We have a document, "IPv6 Configuration in IKEv2 ", draft-ietf-ipsecme-ikev2-ipv6-config-01.txt, which has just gone into WG Last Call. The document has only been lightly reviewed in the WG, and we would really like more IPv6-clued folks to look at it. The WG Last Call announcement is at . Please feel free to send comments to the mailing list, even if they are short. I really do want to be sure that some folks have read the document and that we're not overlooking something obvious. --Paul Hoffman, Director --VPN Consortium