Re: v6 subnet size for DSL & leased line customers
--- nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: From: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> On Thu, 27 Dec 2007 18:08:10 -0800 "Scott Weeks" <surfer@mauigateway.com> wrote:
I am thinking of a /56 for everyone and a /48 on request.
Out of curiosity, what in form would a request for a /48 need to be? A checkbox on the application form, or some sort of written justification? Remember that with an initial RIR allocation of a /32, you've got 65K /48s ... so they're pretty cheap to give away. --------------------------------------------------------------- I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers. scott
Scott Weeks wrote: [..]
I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers.
Thus why didn't you request a larger prefix from ARIN then? Clearly you can justify it. Then again, if you are going to provide /56's to home users, nobody will think you are a bad person and most people will be quite happy already. In your case I would then reserve (probably topdown) /48's, for the larger sites/businesses and start allocating bottom-up for /56's to endusers. Greets, Jeroen
On Sun, 30 Dec 2007 12:08:34 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
Scott Weeks wrote: [..]
I have about 100K DSL customers at this time and most all are households. 65K wouldn't cover that. At this point, I doubt that I'd require much more than just asking and making sure the person is understanding what they're asking for. Mostly, that'd be the leased line customers.
Thus why didn't you request a larger prefix from ARIN then? Clearly you can justify it.
Then again, if you are going to provide /56's to home users, nobody will think you are a bad person and most people will be quite happy already.
In your case I would then reserve (probably topdown) /48's, for the larger sites/businesses and start allocating bottom-up for /56's to endusers.
Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time. Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time.
As stated, that approach has really negative implications for the number of routes you carry in your IGP.
Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length.
Regards, Mark.
On Mon, 31 Dec 2007 13:18:41 -0800 Joel Jaeggli <joelja@bogus.com> wrote:
Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time.
As stated, that approach has really negative implications for the number of routes you carry in your IGP.
Well, for 120K+ customers, I doubt you're using an IGP for anything much more than BGP loopbacks - and you'd have to be aggregating routes at a higher layer in your routing hierarchy anyway, to cope with 120K routes, regardless of what method you use to dole out /48s or /56s to end-sites.
Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length.
Regards, Mark.
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On Tue, 1 Jan 2008 10:27:50 +1030 Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Mon, 31 Dec 2007 13:18:41 -0800 Joel Jaeggli <joelja@bogus.com> wrote:
Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48. If you started out with a /30 or /31 RIR block , by the time you run out of /48s, you can either start using up the subsequent /56s out of the first /48, as it's likely that the first /56 customer out of the /48 would have needed the /48 by that time.
As stated, that approach has really negative implications for the number of routes you carry in your IGP.
Well, for 120K+ customers, I doubt you're using an IGP for anything much more than BGP loopbacks - and you'd have to be aggregating routes at a higher layer in your routing hierarchy anyway, to cope with 120K routes, regardless of what method you use to dole out /48s or /56s to end-sites.
It being New Year's Day and my brain not working right yet ... you'd probably divide your RIR block up across your PoPs, and then could use this technique within each PoP, with the PoP being the route aggregation boundary.
Alternatively you might have become more comfortable with giving each customer a /48, and wouldn't require any of them to renumber - they'd just have to shorten their prefix length.
Regards, Mark.
--
"Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On 31 dec 2007, at 1:24, Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48.
Right, so you combine the downsides of both approaches. It doesn't work when ARIN does it: * 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.48.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.64.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.80.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.96.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.112.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.128.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.144.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.160.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.176.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.192.0/19 4.68.1.166 0 0 3356 6453 11290 i * 24.122.224.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.240.0/20 4.68.1.166 0 0 3356 6453 11290 i And it's unlikely to work here: for those standard size blocks, you really don't want any per-user config: you want those to be assigned automatically. But for the /48s you do need per-user config, if only that this user gets a /48. So these two block sizes can't realistically come from the same (sub-) range.
On Tue, 1 Jan 2008 12:57:17 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 31 dec 2007, at 1:24, Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48.
Right, so you combine the downsides of both approaches.
It doesn't work when ARIN does it:
Well, ARIN aren't running the Internet route tables. If they were, I'd assume they'd force AS6453 to do the right thing and aggregate their address space.
* 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.48.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.64.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.80.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.96.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.112.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.128.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.144.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.160.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.176.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.192.0/19 4.68.1.166 0 0 3356 6453 11290 i * 24.122.224.0/20 4.68.1.166 0 0 3356 6453 11290 i * 24.122.240.0/20 4.68.1.166 0 0 3356 6453 11290 i
And it's unlikely to work here: for those standard size blocks, you really don't want any per-user config: you want those to be assigned automatically. But for the /48s you do need per-user config, if only that this user gets a /48. So these two block sizes can't realistically come from the same (sub-) range.
Maybe I'm not understanding this correctly. Are you saying that customers who have a /56 would get dynamic ones i.e. a different one each time they reconnect? If they've got a routed downstream topology, with multiple routers and subnets (because of course, they've got 256 of them), I don't think customers will be very happy about having to renumber top /56 bits if e.g. they have a DSL line sync drop out and get a different /56. Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset). Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On Jan 1, 2008 8:29 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Tue, 1 Jan 2008 12:57:17 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 31 dec 2007, at 1:24, Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48.
Right, so you combine the downsides of both approaches.
It doesn't work when ARIN does it:
Well, ARIN aren't running the Internet route tables. If they were, I'd assume they'd force AS6453 to do the right thing and aggregate their address space.
11920 - cogeco who I presume (just guessing) is doing this either because they have not aggregated by mistake or have to shed load and load-balance). I don't think teleglobe (6453) is at fault here... out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
* 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i
Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that end-users get dynamic assignments from a local (to the PE device) pool, similar to ipv4. I suppose you could do static assignments, but there's a management payment there that might not fit within the ISP's cost plan. I presume that something accepting PD would be smart enough to let the end-hosts/lans know when their top 56 bits changed... and v6 includes auto-renumbering for 'free' right? So all solved? (yes some of that is joking... or at the very least pointing out a gotcha) -Chris
On Wed, 2 Jan 2008 00:42:59 -0500 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Jan 1, 2008 8:29 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Tue, 1 Jan 2008 12:57:17 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 31 dec 2007, at 1:24, Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48.
Right, so you combine the downsides of both approaches.
It doesn't work when ARIN does it:
Well, ARIN aren't running the Internet route tables. If they were, I'd assume they'd force AS6453 to do the right thing and aggregate their address space.
11920 - cogeco who I presume (just guessing) is doing this either because they have not aggregated by mistake or have to shed load and load-balance). I don't think teleglobe (6453) is at fault here...
out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
* 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i
Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that end-users get dynamic assignments from a local (to the PE device) pool, similar to ipv4.
IPv6 is different to IPv4, don't assume things are to be done the same. Some things are, some things can be, somethings shouldn't be. Why was dynamic addressing for residential customers in IPv4 put in in the first place? Occasional dial up access would be my guess as to the root reason - it was wasting IPv4 addresses if your infrastructure couldn't handle all of your customers dialing up at once. Broadband has of course changed that, when you sell a broadband service, you have to assume that the customer will be connected 24x7, so you need as many IPv4 addresses as you've got customers - and the same will apply for IPv6. Why do dynamic when you don't need to?
I suppose you could do static assignments, but there's a management payment there that might not fit within the ISP's cost plan. I presume that something accepting PD would be smart enough to let the end-hosts/lans know when their top 56 bits changed... and v6 includes auto-renumbering for 'free' right? So all solved?
(yes some of that is joking... or at the very least pointing out a gotcha)
-Chris
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
Broadband has of course changed that, when you sell a broadband service, you have to assume that the customer will be connected 24x7, so you need as many IPv4 addresses as you've got customers - and the same will apply for IPv6. Why do dynamic when you don't need to?
There are several other arguments for dynamic addresses, for instance: - Dynamic addresses often make it easier to perform bulk moves of large numbers of customers. - Dynamic addresses for residential customers is a way to justify higher cost (and profit) for a "business" type service with static addresses. Given that many service providers find dynamic addresses for residential customers extremely convenient, *independent of the number of available addresses*, is there any reason to believe this will change with IPv6? Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On Wed, 2 Jan 2008 00:42:59 -0500 "Christopher Morrow" <morrowc.lists@gmail.com> wrote:
On Jan 1, 2008 8:29 AM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
On Tue, 1 Jan 2008 12:57:17 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 31 dec 2007, at 1:24, Mark Smith wrote:
Another idea would be to give each non-/48 customer the first /56 out of each /48.
Right, so you combine the downsides of both approaches.
It doesn't work when ARIN does it:
Well, ARIN aren't running the Internet route tables. If they were, I'd assume they'd force AS6453 to do the right thing and aggregate their address space.
11920 - cogeco who I presume (just guessing) is doing this either because they have not aggregated by mistake or have to shed load and load-balance). I don't think teleglobe (6453) is at fault here...
Yeah, you're right, I missed the line wrapped AS_PATH.
out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
* 24.122.32.0/20 4.68.1.166 0 0 3356 6453 11290 i
Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that end-users get dynamic assignments from a local (to the PE device) pool, similar to ipv4. I suppose you could do static assignments, but there's a management payment there that might not fit within the ISP's cost plan. I presume that something accepting PD would be smart enough to let the end-hosts/lans know when their top 56 bits changed... and v6 includes auto-renumbering for 'free' right? So all solved?
(yes some of that is joking... or at the very least pointing out a gotcha)
-Chris
-- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On 2 jan 2008, at 6:42, Christopher Morrow wrote:
out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
AS path prepending, local preference, that kind of thing...
Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that end-users get dynamic assignments from a local (to the PE device) pool, similar to ipv4. I suppose you could do static assignments, but there's a management payment there that might not fit within the ISP's cost plan.
There is no "static" and "dynamic", only points along a line... Obviously you don't want your customers to renumber every day and twice on sunday, but you also don't want to keep configurations specific for each customer. A good DHCP server will keep giving you the same address until it's forced to give that address to someone else when you're not using it, or until it loses its assignment history. I assume something similar will happen here for most customers.
I presume that something accepting PD would be smart enough to let the end-hosts/lans know when their top 56 bits changed...
Cisco routers can change their RAs based on a new PD prefix and even align the lifetimes so the renumbering happens very smoothly.
and v6 includes auto-renumbering for 'free' right?
Yes, that must be why IPv6-capable firewalls are still hard to find. :-)
On 2-Jan-2008, at 10:21, Iljitsch van Beijnum wrote:
On 2 jan 2008, at 6:42, Christopher Morrow wrote:
out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
AS path prepending, local preference, that kind of thing...
Common practice with IPv4 seems to suggest that those knobs aren't sufficient in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance :-) I imagine that the same practice will continue (is continuing?) with IPv6, to the extent that peoples' bogon filters allow it to have any practical effect. Joe
in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance There's a big difference between deaggregating a couple of bits for TE
purposes and announcing 64 /24's from your /18 :) We need to decide what's acceptable as a community and then enforce it as a community. If someone starts announcing dozens of prefixes in v6 then they get blocked they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it). -Don
We need to decide what's acceptable as a community and then enforce it as a community. If someone starts announcing dozens of prefixes in v6 then they get blocked they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it). I really need to fix my my terminal settings- that should have read:
If someone starts announcing dozens of prefixes in v6 then they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it). Sorry for the grammar failure. -Don
Donald Stahl wrote:
in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance There's a big difference between deaggregating a couple of bits for TE purposes and announcing 64 /24's from your /18 :)
We need to decide what's acceptable as a community and then enforce it as a community. If someone starts announcing dozens of prefixes in v6 then they get blocked they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it).
On this note: In the v6 world when multihoming, what size network block is the minimum recommended allocation? In the v4 Internet, most major networks I've seen do not accept anything longer than /24 and this is what is allocated to customers with their own AS when multihoming regardless of the usage of the /24. I'm just curious if this is currently outlined somewhere already as what was decided. Are we going to see /64's, /56's or /48's polluting the v6 routing table just as /24's are today on the v4 table? I understand most of that pollution is not because of multihoming, but rather TE or negligence/lack of clue. With the advent of 32 bit ASN's, this could possibly become a concern however... that and people trying to do TE with their v6 space as they did with v4. I agree with the above reply that this needs to be ironed out as a community and was curious how multihoming customer networks fit into this equation. -- Vinny Abello Network Engineer vinny@tellurian.com (973)940-6100 (NOC) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "There is no objective reality. Only that which is measured exists. We construct reality, and only in the moment of measurement or observation." -- Niels Bohr
I'm glad to see more people are starting to look at this issue. If you are just now beginning to look into the IPv6 Multihoming issue I would start with reading a few strings on IETF, NANOG and ARIN mail lists and the following document posted 2 years ago at: http://www.nro.org/documents/pdf/MultihomeIPv6procon.pdf Decisions need to be made soon and all kinds of policy can effect that. Their are dueling issues at hand on this matter and we need to find a balance. Traffic Engineering and Multihoming is an Engineering requirement. Not exploding the tables is also a requirement. Right now policy only inadvertently supports PI to be used for Multihoming and policy inadvertently does not support TE or Multihoming. Not permitting TE or Multihoming on large networks is not going to be accepted by the large networks as an answer. So it would be a "good thing" if our community could work out a balance that permits TE and Multihoming on a managed scale. Otherwise those networks will just start doing whatever they want or need. Cheers! Marla -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Vinny Abello Sent: Wednesday, January 02, 2008 10:53 AM To: Donald Stahl Cc: Joe Abley; Iljitsch van Beijnum; Christopher Morrow; NANOG list Subject: Re: v6 subnet size for DSL & leased line customers Donald Stahl wrote:
in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance There's a big difference between deaggregating a couple of bits for TE purposes and announcing 64 /24's from your /18 :)
We need to decide what's acceptable as a community and then enforce it as a community. If someone starts announcing dozens of prefixes in v6 then they get blocked they either get blocked or they get a filter that restricts them to their covering route (or blocks them if they don't have it).
On this note: In the v6 world when multihoming, what size network block is the minimum recommended allocation? In the v4 Internet, most major networks I've seen do not accept anything longer than /24 and this is what is allocated to customers with their own AS when multihoming regardless of the usage of the /24. I'm just curious if this is currently outlined somewhere already as what was decided. Are we going to see /64's, /56's or /48's polluting the v6 routing table just as /24's are today on the v4 table? I understand most of that pollution is not because of multihoming, but rather TE or negligence/lack of clue. With the advent of 32 bit ASN's, this could possibly become a concern however... that and people trying to do TE with their v6 space as they did with v4. I agree with the above reply that this needs to be ironed out as a community and was curious how multihoming customer networks fit into this equation. -- Vinny Abello Network Engineer vinny@tellurian.com (973)940-6100 (NOC) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "There is no objective reality. Only that which is measured exists. We construct reality, and only in the moment of measurement or observation." -- Niels Bohr
On Jan 2, 2008 1:05 PM, Joe Abley <jabley@ca.afilias.info> wrote:
On 2-Jan-2008, at 10:21, Iljitsch van Beijnum wrote:
On 2 jan 2008, at 6:42, Christopher Morrow wrote:
out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
AS path prepending, local preference, that kind of thing...
Common practice with IPv4 seems to suggest that those knobs aren't sufficient in real life; people still find it necessary to carve up their aggregates and announce more-specifics in strategic directions. I would suggest that not *all* observed instances of such deaggregation are due to operator ignorance :-)
I think this goes back to my point about DHCP, today there is a business practice and set of business requirements that work for a host of reasons. Expecting that in v6 these requirements will evaporate is not wise. There will have to be some useful TE knobs, I think the operations community would probably like to see those knobs NOT be 'deaggragate' so what other options are there for someone with a single prefix (especially when that prefix is very large). -chris
On 2-Jan-2008, at 15:30, Christopher Morrow wrote:
I think this goes back to my point about DHCP, today there is a business practice and set of business requirements that work for a host of reasons. Expecting that in v6 these requirements will evaporate is not wise. There will have to be some useful TE knobs, I think the operations community would probably like to see those knobs NOT be 'deaggragate' so what other options are there for someone with a single prefix (especially when that prefix is very large).
The community who would like the knob not to be "deaggregate" are the same ones that are doing the deaggregation, which I think is as it should be from a macro level (an organism whose behaviour is harmful to itself will presumably, eventually, learn) even if it's still problematic at a micro level (the individual ASes doing the deaggregation enjoy all the benefit with only a tiny fraction of the collective cost). As to "there must be better knobs" I think it may be a little late for that; by design (or as a consequence of it) the set of IPv6 knobs is the same as the set of IPv4 knobs. Joe
The community who would like the knob not to be "deaggregate" are the same ones that are doing the deaggregation, which I think is as it should be from a macro level (an organism whose behaviour is harmful to itself will presumably, eventually, learn) even if it's still problematic at a micro level (the individual ASes doing the deaggregation enjoy all the benefit with only a tiny fraction of the collective cost).
As to "there must be better knobs" I think it may be a little late for that; by design (or as a consequence of it) the set of IPv6 knobs is the same as the set of IPv4 knobs.
Is there anything inherently harmful with suggesting that filtering at RIR boundaries should be expected, but those that accept somewhat more lenient boundaries are nice guys??? When the nice guys run out of resources, they can filter at RIR boundaries and say they are doing so as a security upgrade :_). Right now there isn't a hardware contention (that I'm aware of) that creates a real incentive to block deagg. But I think all of us have TE talks with ourselves and customers talking about how TE deagg w/o a covering announcement may be a bad thing (and not work for 100% of the internet, etc). Now that a number of platforms are near their IPv4 limits, lots of these deaggs are being dropped by various entities (mostly outside of their native RIR). Is there anything wrong with continuing this??? This gives preference to networks that accept deaggs from their customers (but don't leak them, etc, etc) and allows more flexibility until hardware limits rear their ugly heads again. Deepak
On Wed, 2 Jan 2008, Deepak Jain wrote:
Is there anything inherently harmful with suggesting that filtering at RIR boundaries should be expected, but those that accept somewhat more lenient boundaries are nice guys??? When the nice guys run out of resources, they can filter at RIR boundaries and say they are doing so as a security upgrade :_).
So how would this work for large companies? In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should only get at most a /48 from each RIR. How should they handle region offices, Especially mutihomed ones? -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.
Simon Lyall wrote:
On Wed, 2 Jan 2008, Deepak Jain wrote:
Is there anything inherently harmful with suggesting that filtering at RIR boundaries should be expected, but those that accept somewhat more lenient boundaries are nice guys??? When the nice guys run out of resources, they can filter at RIR boundaries and say they are doing so as a security upgrade :_).
So how would this work for large companies?
In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should only get at most a /48 from each RIR.
How should they handle region offices, Especially mutihomed ones?
First thing you will have to define here is 'multihomed'. Do you mean that they have 1 prefix and multiple upstreams, or do you mean that they have multiple upstreams and multiple prefixes? This is actually a problem for every organization that does have multiple distributed offices/sites but doesn't have the capability/core-business of setting up connectivity between all of them and moving the bits for all of them. Nevertheless the current 'solution' to this problem (1 org, distributed sites, no own network between those sites) will be: option 1) - Every site gets a /48 from their local ISP - Internet connectivity happens using the ISP prefix - Communications between sites happen using the ISP prefix - Site Firewalling happens on the ISP prefix (multiple entries needed, lets hope they don't change or that an auto-update system is in place) option 2) - Every site gets a /48 from their local ISP - $org gets a prefix from RIR - Every site gets a /48 from the $org prefix - Every site setup a VPN to every other site where needed - Internet connectivity happens using the ISP prefix - Communications between sites happen using the org prefix - Firewalling happens on the $org prefix Option 2 has one small problem though: source address selection. Fortunately if one can deploy RFC3484 properly this should not be a big problem. Also mostly a source address is chosen based on it being 'closest' to the destination prefix*. Greets, Jeroen * = which is why when 2003::/16 started to get deployed, 6to4 (2002::/16) was being preferred over 2001::/16 source addresses ;)
On 3 Jan 2008, at 06:29, Simon Lyall wrote: [...]
So how would this work for large companies?
Note that RIR policies tend to refer to end-sites rather than end- users. This implies (or I infer) that the intention is for addressing to follow topology.
In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should only get at most a /48 from each RIR.
per site.
How should they handle region offices, Especially mutihomed ones?
PI assignments? Regards, Leo
Thus spake "Simon Lyall" <simon@darkmere.gen.nz>
On Wed, 2 Jan 2008, Deepak Jain wrote:
Is there anything inherently harmful with suggesting that filtering at RIR boundaries should be expected, but those that accept somewhat more lenient boundaries are nice guys??? When the nice guys run out of resources, they can filter at RIR boundaries and say they are doing so as a security upgrade :_).
So how would this work for large companies?
In theory multinationals like Morgan Stanley, Wall-Mart or HSBC should only get at most a /48 from each RIR.
In what theory? They'd get at _minimum_ a /48 from each RIR that has approved PIv6. If they needed more, they merely have to fill out the appropriate paperwork showing justification. If they operate in regions where the RIR hasn't approved PIv6, they'd route around the failure there and use space assigned by other RIRs. (Not saying I approve of that, but it's reality.) Currently ARIN is approving all requests for more than a /48 since there is no definition of what "justify" means in that context. Ebay, which is hardly the size of the companies you listed, got a /41. That obviously needs fixing, but the problem is the opposite of the one you seem to be theorizing.
How should they handle region offices, Especially mutihomed ones?
Announce their prefix from all locations, with more-specifics for TE purposes. Presumably their upstreams would carry the more-specifics since they're being paid to, but folks further away would filter them and only see the covering aggregate, which is good enough. (Note this assumes they have an internal network; if they didn't, each disconnected part would be a "site" and qualify for a /48 on its own. That's a suboptimal solution, though, for reasons too numerous to list.) S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On 2 jan 2008, at 22:34, Joe Abley wrote:
The community who would like the knob not to be "deaggregate" are the same ones that are doing the deaggregation, which I think is as it should be from a macro level
More precise: the two sets of people are part of the same community. I'm not sure if there's much overlap between the really bad deaggregators and those who are strongly pro-knob, though.
As to "there must be better knobs" I think it may be a little late for that; by design (or as a consequence of it) the set of IPv6 knobs is the same as the set of IPv4 knobs.
The trouble is that BGP doesn't have a meaningful inter-AS metric. (Although there is something that is called that.) If I want to increase my path length by 10% through a certain neighboring AS, I don't get to do that. I only get to double or triple it. (Unless I was doing very heavy prepending to begin with.) This is easy to fix by adding a new metric to BGP that is increased by 10 or 100 or 1000 at each hop by default, but which can also be increased by a larger or smaller amount as desired. In essence, this would make the AS path a lot more granular. Obviously this only works if a fairly large set of ASes implements this. However, word on the street is that in order to get a new BGP attribute defined in the IETF idr wg, you need assurances up front that people are actually going to implement and use that new attribute.
On 2-Jan-2008, at 18:09, Iljitsch van Beijnum wrote:
However, word on the street is that in order to get a new BGP attribute defined in the IETF idr wg, you need assurances up front that people are actually going to implement and use that new attribute.
Tony Li and I went through that process with AS_PATHLIMIT, which has received an early code-point assignment from the IANA. The idr wg chairs followed the prescribed process to the letter, which is perhaps where perceptions of trouble come from, but the process was not unreasonable or particularly difficult (and for AS_PATHLIMIT the chairs were prompt and efficient in doing their part). (The reason AS_PATHLIMIT hasn't progressed since is a lack of follow- through from those who had expressed interest in the implementation; one of these days I will find time to enquire after progress from various people, and perhaps it can be resurrected. Note that I'm not suggesting that AS_PATHLIMIT is a magic bullet for anybody :-) Joe
I think this goes back to my point about DHCP, today there is a business practice and set of business requirements that work for a host of reasons. Expecting that in v6 these requirements will evaporate is not wise.
changing the business model and freeing the customer from the "evil greedy bastard isps" (yes, that was the term used) was an often explicit goal of many of ipv6's core designers. in some ways, i sympathize with this. many aspects of our business models are forced into contortions by the address/routing model, bgp limitations, ... but, indeed, expecting radical change when there is not even a transition plan is, shall we be kind and say, overly idealistic. randy
On Jan 2, 2008 10:21 AM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 2 jan 2008, at 6:42, Christopher Morrow wrote:
out of curiousity how is this sort of thing supposed to be done in v6? (traffic engineering given the '1 prefix per ISP' standard mantra)
AS path prepending, local preference, that kind of thing...
there is only one prefix so this amounts to, essentially, on/off for a peer/transit/customer. (you can distance yourself from all of a provider directly connected or none...)
Static assignments of /56 to customers make sense to me, and that's the assumption I've made when suggesting the addressing scheme I proposed. Once you go static with /56s, you may as well make it easy for both yourself and the customer to move to a /48 that encompasses the original /56 (or configure the whole /48 for them from the outset).
I think the assumption most folks make with DSL/cable is that end-users get dynamic assignments from a local (to the PE device) pool, similar to ipv4. I suppose you could do static assignments, but there's a management payment there that might not fit within the ISP's cost plan.
There is no "static" and "dynamic", only points along a line... Obviously you don't want your customers to renumber every day and twice on sunday, but you also don't want to keep configurations specific for each customer. A good DHCP server will keep giving you the same address until it's forced to give that address to someone else when you're not using it, or until it loses its assignment history. I assume something similar will happen here for most customers.
So, sure a dhcp server can do some of the work, but you may end up with situations where customerX moves from pop1 to pop2 and if you aggragated on pop boundaries you'll have to plan on leakages across the boundaries, bloating your IGP some... or plan on the customer being 'broken' until they call and get new address space. With a 'dynamic' (each login you get a randomly assigned PD from the local pool) you'd avoid this and avoid the hassles when customerX leaves and you all of a sudden have to deconflict customerX from new-customer-Z... Cleanup classically has been a difficult art to master :( (costly)
I presume that something accepting PD would be smart enough to let the end-hosts/lans know when their top 56 bits changed...
Cisco routers can change their RAs based on a new PD prefix and even align the lifetimes so the renumbering happens very smoothly.
well see, we are almost half way there :) good think cisco bought linksys, do linksys devices do v6? and PD and RA?
and v6 includes auto-renumbering for 'free' right?
Yes, that must be why IPv6-capable firewalls are still hard to find. :-)
define 'capable' :)
Anyone have any experience with software that will track both IPv4 and IPv6 assignments in the OSS world? Any recommendations? Thanks in advance, DJ
On 1/2/2008 at 12:32 PM, Deepak Jain <deepak@ai.net> wrote:
Anyone have any experience with software that will track both IPv4
and
IPv6 assignments in the OSS world? Any recommendations?
I would think if you find something that tracks IPv6, that's all you need. You can represent the whole IPv4 space with IPv4-mapped IPv6 addresses, :ffff:a.b.c.d. B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
I would think if you find something that tracks IPv6, that's all you need. You can represent the whole IPv4 space with IPv4-mapped IPv6 addresses, :ffff:a.b.c.d.
This is certainly true. Let's not forget that a simple thing that strips the :ffff: and converts the remaining bits from hex to decimal (at least visually) would be needed to keep the clue impaired up and running. :) The point remains, IPv6 is clearly becoming an operational topic for NANOG so the standard suite of tools we've finally gotten to some level of decency need to be upgraded or adjusted to support v6. DJ
Deepak Jain wrote:
I would think if you find something that tracks IPv6, that's all you need. You can represent the whole IPv4 space with IPv4-mapped IPv6 addresses, :ffff:a.b.c.d.
This is certainly true. Let's not forget that a simple thing that strips the :ffff: and converts the remaining bits from hex to decimal (at least visually) would be needed to keep the clue impaired up and running. :)
Any application which is visualizing IPv4 adresses using either ::ffff:x.x.x.x or ::x.x.x.x is wrong(tm). Those addresses should never ever be shown to the user or used in any way as a textual representation (that includes for instance logfiles, XML files, and other such things). Using them for internal storage (thus so that you only need a 128bit item in your structs) is of course perfectly fine and most likely a smart thing to do. If you find an application which does this, don't hesitate to kick the coders to fix their stuff.
The point remains, IPv6 is clearly becoming an operational topic for NANOG so the standard suite of tools we've finally gotten to some level of decency need to be upgraded or adjusted to support v6.
As for the tool do to this, the best tool is the one you will write yourself and which fully integrates into your existing management setup (people do have those I hope for them, the point for IT after all is to make our work less by creating a lot of stuff ;) Greets, Jeroen
Jeroen Massar <jeroen@unfix.org> 1/2/2008 2:40 PM >>> Deepak Jain wrote:
I would think if you find something that tracks IPv6, that's all you need. You can represent the whole IPv4 space with IPv4-mapped IPv6 addresses, :ffff:a.b.c.d.
This is certainly true. Let's not forget that a simple thing that strips the :ffff: and converts the remaining bits from hex to decimal (at least visually) would be needed to keep the clue impaired up and running. :)
Any application which is visualizing IPv4 adresses using either ::ffff:x.x.x.x or ::x.x.x.x is wrong(tm). Those addresses should never ever be shown to the user or used in any way as a textual representation (that includes for instance logfiles, XML files, and other such
If you find an application which does this, don't hesitate to kick
things). I'll freely admit to only dabbling in IPv6 on my home network and having done a very little bit of nosing around in the KAME codebase, so I could you give some references for this stance. Some RFCs or other docs delivered from the mount saying users are never supposed to see these? The fact that the RFCs specify special presentation formats for these addresses kind of just made me assume that they were meant for humans to see and use. But we all know assumptions can be way off. the
coders to fix their stuff.
OK, so, is this, $ netstat -an | fgrep ::ffff: tcp 0 48 ::ffff:207.88.152.51:22 ::ffff:207.88.153.67:3376 ESTABLISHED $ uname -srvmo Linux 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:14 EDT 2006 i686 GNU/Linux On a plain ol' dual stack Linux box living on an IPv4-only network kosher? Or does kicking need to be done? B¼information contained in this e-mail message is confidential, intended only for the use of the individual or entity named above. If the reader of this e-mail is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any review, dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please contact postmaster@globalstar.com
$ netstat -an | fgrep ::ffff: tcp 0 48 ::ffff:207.88.152.51:22 ::ffff:207.88.153.67:3376 ESTABLISHED $ uname -srvmo Linux 2.6.17-1.2142_FC4 #1 Tue Jul 11 22:41:14 EDT 2006 i686 GNU/Linux
On a plain ol' dual stack Linux box living on an IPv4-only network kosher? Or does kicking need to be done? No, kicking needs to be done.
-Don
Distirbution For software that tracks v4, v6 and ASN look at www.internetassociatesllc.com It handles /64 EUI-64 and Random as well as /127, /128 assignments and any size block allocation from /0 - /126. John (ISDN) Lee Deepak Jain wrote:
Anyone have any experience with software that will track both IPv4 and IPv6 assignments in the OSS world? Any recommendations?
Thanks in advance,
DJ
On Jan 3, 2008 9:23 PM, John L Lee <johnllee@mindspring.com> wrote:
Distirbution
For software that tracks v4, v6 and ASN look at www.internetassociatesllc.com
It handles /64 EUI-64 and Random as well as /127, /128 assignments and any size block allocation from /0 - /126.
John (ISDN) Lee
IMHO, that's a standalone product better suited for the enterprise. Post merger Lucent Alcatel, Lucent QIP was renamed VitalQIP and it does support both v4 and v6. http://www.alcatel-lucent.com/wps/DocumentStreamerServlet?LMSG_CABINET=Docs_and_Resource_Ctr&LMSG_CONTENT_FILE=Brochures/VitalQIP__DNS_DHCP_and_IP_Management_Software_for_your_Enterprise_Brochure.pdf Not for the small (budget) minded. Best, Marty
Marty, Its (IPal) main deployment has been with Service Providers and Government agencies doing v6 deployment since it support multiple vendors DNS and DHCP servers and has XML integration with OSS and NMS systems. As a previous user of VitalQIP they were re-archit5ecting it to support Web based services and v6 but in the US they did an agreement with Infoblox to be the front / backend interface with Qip being the central database. John (ISDN) Lee Martin Hannigan wrote:
On Jan 3, 2008 9:23 PM, John L Lee <johnllee@mindspring.com> wrote:
Distirbution
For software that tracks v4, v6 and ASN look at www.internetassociatesllc.com
It handles /64 EUI-64 and Random as well as /127, /128 assignments and any size block allocation from /0 - /126.
John (ISDN) Lee
IMHO, that's a standalone product better suited for the enterprise.
Post merger Lucent Alcatel, Lucent QIP was renamed VitalQIP and it does support both v4 and v6.
Not for the small (budget) minded.
Best,
Marty
On Jan 4, 2008 2:37 AM, John L Lee <johnllee@mindspring.com> wrote:
Marty,
Its (IPal) main deployment has been with Service Providers and Government agencies doing v6 deployment since it support multiple vendors DNS and DHCP servers and has XML integration with OSS and NMS systems. As a previous user of VitalQIP they were re-archit5ecting it to support Web based services and v6 but in the US they did an agreement with Infoblox to be the front / backend interface with Qip being the central database.
John (ISDN) Lee
John, I literally utilized each link on IA's website and did not see any of that functionality. Regardless, my personal opinion is that it's more suited for the enterprise. There are many tools that call themselves carrier class or OSS capable, but many fall short. In my mind, QIP is a proven app who's only downside is the cost. I don't see the IP tool that you are talking about competing apples for apples or even peer to peer with QIP, to be honest. They are two different classes of application. Last question. Are you affiliated with the company that develops and sells the software that you are recommending? I found someone named John L. Lee referenced as "SVP Business Development". If not, I apologize in advance. If you are, I would appreciate a tad bit more candor in our discussions here. Best Regards, -M<
Marty, I am not quibbling, but I did not recommend IPal but suggested that that DJ look at the IA web site at IPal because of the question he posed. "Anyone have any experience with software that will track both IPv4 and IPv6 assignments in the OSS world? Any recommendations? While at EBS as the Director of Network Engineering we had copies of VitalQIP running including the DNS and DHCP portions. IPal a next generation IPAM does not compete with QIP buts sits in front of it with its IP Address Lifecycle Model with Engineered IP Addresses. IPal can drive both IPAM, DHCP and DNS vendors software such as QIP and other vendors supporting multiple complete v4, v6 and ASN space under management, any size block allocation with multiple allocation algorithms including /64 EUI-64 and random. It supports multiple vendors IPAM, DHCP and DNS from one version of software. You are on the NANOG mailing list committee and I was trying to be very careful in my wording not to cross over the line into sales and marketing activities on a technical list. Having known Dorn Hetzel and Randy Bush for over twenty years and having been on this list for a number of years, I assumed you knew my affiliation with IA and I use my personal business e-mail account not my "official" IA account even though IA does several network engineering projects with high performance optical and IP networks. (We need to meet at the next beer and gear.) IA was started in 2002 because of a lack of complete IP address life cycle solutions since only point tools that did some IPAM, DNS and DHCP were available. IPal was introduced in 2003 at an AFCEA conference supporting v4, v6 and ASN aggregate trees, multiple routing domains. Engineered IP Addresses are valid CIDR addresses that are unique within a given routing domain. The IP Address Lifecycle Model was developed to support allocation, assignment, aggregation, automatic reclamation of IP space while maintaining the accuracy and integrity of the Engineered IP Addresses. There are several patents awarded and multiple ones pending in NA, Europe and Asia for this next generation technology. IPals patent pending technology allows organization to manage multiple complete v4 domains with multiple RFC1918 space and multiple complete v6 domains supporting equipment, connections (circuits and LANs i.e. point to point or multi-point) with bi-directional XML/SOAP interfaces connecting to OSS, NMS, IDS and IPS systems. IPal is currently the only solution that US Government agencies are using to develop their v6 address plans to meet the June 2008 deadline for passing v6 traffic on their backbones. Best Regards, John (ISDN) Lee CTO, Internet Associates, LLC SME on IP Address Management & IP Address Management Tools and Solutions for two or three IPv6 Organizations Background - I started pre-Ethernet with modems, Pascal, ADA, Modula II, ISDN, PDP 7, 8's and 11's, Ethernet, TCP/IP, ATM, Frame, VoATM (video and voice), VTC,. Optical switching, MPLS, T1, T3s, SONET/SDH, VoIP, etc... Disclaimer: The views expressed in this e-mail are those of the author and do not reflect the official position of any commercial or Government organization or agency. Martin Hannigan wrote:
On Jan 4, 2008 2:37 AM, John L Lee <johnllee@mindspring.com> wrote:
Marty,
Its (IPal) main deployment has been with Service Providers and Government agencies doing v6 deployment since it support multiple vendors DNS and DHCP servers and has XML integration with OSS and NMS systems. As a previous user of VitalQIP they were re-archit5ecting it to support Web based services and v6 but in the US they did an agreement with Infoblox to be the front / backend interface with Qip being the central database.
John (ISDN) Lee
John, I literally utilized each link on IA's website and did not see any of that functionality. Regardless, my personal opinion is that it's more suited for the enterprise. There are many tools that call themselves carrier class or OSS capable, but many fall short. In my mind, QIP is a proven app who's only downside is the cost.
I don't see the IP tool that you are talking about competing apples for apples or even peer to peer with QIP, to be honest. They are two different classes of application.
Last question. Are you affiliated with the company that develops and sells the software that you are recommending? I found someone named John L. Lee referenced as "SVP Business Development". If not, I apologize in advance. If you are, I would appreciate a tad bit more candor in our discussions here.
Best Regards,
-M<
On Jan 2, 2008 12:32 PM, Deepak Jain <deepak@ai.net> wrote:
Anyone have any experience with software that will track both IPv4 and IPv6 assignments in the OSS world? Any recommendations?
we've been using IPPlan <http://iptrack.sf.net/> recently and have been pretty satisfied with it (standard LAMP stack), but it doesn't appear to support v6. This app (japanese only at the moment, it looks like) looks pretty promising: http://www.ipv6style.jp/en/tryout/20041224/index.shtml -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
Scott Francis wrote:
On Jan 2, 2008 12:32 PM, Deepak Jain <deepak@ai.net> wrote:
Anyone have any experience with software that will track both IPv4 and IPv6 assignments in the OSS world? Any recommendations?
we've been using IPPlan <http://iptrack.sf.net/> recently and have been pretty satisfied with it (standard LAMP stack), but it doesn't appear to support v6. This app (japanese only at the moment, it looks like) looks pretty promising: http://www.ipv6style.jp/en/tryout/20041224/index.shtml
Anyone have an idea of what it would take to create an English language set for it? (like a cost figure to get a bilingual person drunk long enough to do the job?) ;) DJ
On Jan 4, 2008 1:31 PM, Deepak Jain <deepak@ai.net> wrote:
Scott Francis wrote:
On Jan 2, 2008 12:32 PM, Deepak Jain <deepak@ai.net> wrote:
Anyone have any experience with software that will track both IPv4 and IPv6 assignments in the OSS world? Any recommendations?
we've been using IPPlan <http://iptrack.sf.net/> recently and have been pretty satisfied with it (standard LAMP stack), but it doesn't appear to support v6. This app (japanese only at the moment, it looks like) looks pretty promising: http://www.ipv6style.jp/en/tryout/20041224/index.shtml
Anyone have an idea of what it would take to create an English language set for it? (like a cost figure to get a bilingual person drunk long enough to do the job?) ;)
request went out from one of the project developers to the IETF v6 mailing list a while ago for translation help; my knowledge of Japanese is essentially nil, so I can't help much there. -- darkuncle@{gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key
participants (20)
-
Azinger, Marla -
Christopher Morrow -
Crist Clark -
Deepak Jain -
Donald Stahl -
Iljitsch van Beijnum -
Jeroen Massar -
Joe Abley -
Joel Jaeggli -
John L Lee -
Leo Vegoda -
Mark Smith -
Martin Hannigan -
Randy Bush -
Scott Francis -
Scott Weeks -
Simon Lyall -
Stephen Sprunk -
sthaug＠nethelp.no -
Vinny Abello