Re: Independence of Deprecation (Was: Re: Moving forward onSite-Local and Local Addressing)
I look forward to reading an ID describing a set of necessary (not sufficient!) requirements fulfilled by scoped unicast addressing - i.e. the problems which cannot be solved by *any other* mechanism. personally I'm not interested in having this group spend any time trying to justify a feature which we already know is unworkable. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
Geoff Huston wrote: At 06:30 PM 6/08/2003 +1000, Aidan Williams wrote: I can't see significant differences in process between globally unique local address allocation and a globally unique PI address allocation. I'd offer the view that there's a lot of difference. OK, I can see how registries could have problems implementing centrally assigned random allocation as described in the draft. Is non-aggregable to registries and random selection inside those blocks a feasible alternative? A further comment: your document speaks positively of a rental service model for local addresses with non-payment causing the block to return to a pool. With a local address block, can that be made to stick? Having received an address allocation, where is the incentive to keep paying? Why not just default and keep using your allocated address.. Given the random selection process, reuse is unlikely and given that the address is local, noticable breakage is unlikely too. - aidan IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Real life scenario - requirements (local addressing)
A 'real life' deployment scenario. (a) I set up a local network. I currently have no ISP, but I want my network to 'just work' out of the box. This network consists of (initially) three routers, plus other infrastructure. (b) Sometime later I decide I want internet connectivity, so I connect to an ISP. I add my ISP provided address to my network in addition to the address/es that are there already. For argument's sake, let's say the ISP doesn't have IPv6 capability, so I use a 6to4 address. I do not want my internal addressing exposed outside the network, so I filter my addresses. I do use the ISPs addresses for external connectivity. (c+d) Meanwhile, my friend has done the same thing, except that his ISP DOES offer IPv6, so he has a 'real' IPv6 address. (e) We connect our two local networks together (either by VPN tunnel or a wireless link - doesn't matter). We can now send local traffic to each other, and out either ISP. (f) Sometime later I disconnect my ISP, and we use just his ISP. (g) Sometime later I disconnect my network from his. (h) Sometime later I register with a new ISP, and get a new IPv6 prefix. Salient points: (1) At points (a), (c) and (g) we have networks that are standalone and have no connection to an ISP or the global internet. Further, the networks in (a) and (c) have never had such a connection. The users don't want to have to register to get an address that works. (2) In (b), the external (6to4) prefix is unstable. Many ISPs allocate a temporary IPv4 internet address, and change these frequently. (3) The set of global prefixes valid for the network changes over time. (a) None (b) #1 (my 6to4) (e) #1 and #2 (friend's v6) (f) #2 (g) None (h) #3 (my new v6) (4) The only 'reliable' address that the hosts in my network have is the local one they started with. This example is quite similar to Tony's research ship example, with the possible caveat that a research ship might be big and organised enough to register with an ISP to get an address space plus connectivity they never intend to use. Consequences: - I need some form of local addressing that is not dependent on anyone or anything connected to the global internet. - I need this local addressing unique enough that I can safely join my network and my friend's network together and allow them to swap prefixes. - I want hosts in my network to prefer my local address scheme when talking to other hosts in my network. I want hosts in my network to prefer one of the local schemes when talking to hosts in my friend's network (since I don't want the packets to leave 'our' network). I want hosts in my network to prefer global addresses when talking externally. - I want my local addresses filtered at appropriate borders, preferably without having to set it up myself. - The ISPs probably want my local addresses filtered too. Looks suspiciously like the filtered local address proposal, doesn't it? -- Andrew White IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Real life scenario - requirements (local addressing)
On Thu, 7 Aug 2003, Andrew White wrote: Just responding to a few points.. On Thu, 7 Aug 2003, Andrew White wrote: When that 6to4 address goes away, I don't want my persistent sessions to be forced to maintain a stale address. Why not? There's no problem with that, really. You can continue using bogus addresses as long as you want, the problems only start appearing when you reconnect. Real example: My ISP's DSL connection decides to drop the connection and reconnect (with a new IPv4 address, and thus 6to4 prefix) every 1-3 hours. I'd rather not subject my internal network to that if I don't have to. Switch ISP or complain to them. I certainly wouldn't bear with that kind of behaviour. If that kind of ISP techniques are commonplace, we may need to do something. But I'm not sure if that's the case. Experiences? Note: consider how many of these techniques are used to prevent people from keeping servers at their home systems (i.e., does the ISP consider the changing address a bug or feature). Also consider how the situation would change (if any) with IPv6 provided by the ISP. Real example: at home, I use DHCP on DSL to get addresses. During 1 year, the addresses have changed _once_ (the ISP changed the prefix from which it allocated the DSL users' addresses). That's good enough for me, and I even manually glue all the IPv4 and resulting 6to4 addresses in my configuration files, filters etc. I've made a counter point several times, and some probably agree, but really think ANY solution which promises automatic filtering is a non-starter. It seems totally bogus to create an assumption that someone upstream will just do it and rely on that. YOU CAN'T RELY ON THAT. Agreed. Which is why my border router ALSO implements the same REQUIRED filter, no? *shrug* The application does not know such a filter is implemented, hence it cannot assume security properties on specific kind of addresses. It's whether an application can assume that global addresses are never filtered, and the answer is that it can't. Ergo, global addresses are also scoped addresses. There is a difference of a couple of degrees of magnitude here. Absolute yes/no are irrelevant (because there is always some filtering); it's more important to figure out the probability which results in the highest percentage of getting it right at the first try, a good percentage of doing well at the second if really needed etc. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
Michael, For a change I mostly agree (will detail below what I don't like) with what you just posted, especially: Michael Thomas wrote: so even these small sensible steps that you propose nonetheless seem grave in their global implications. and But I'm sorry, if NAT's become a de-facto necessity for v6 native networks (putting aside the need for v4/v6 NAT's), then I find the entire premise of ipv6's utility deeply undermined. Quite possibly fatally. The same is true if we create a swamp again and allow individual /48s in the global routing table. Then IPv6 will become IPv4 with more bits, and in the current economy the net result will be more NAT-aware apps. I'm sorry to say it bluntly, but today IPv4 is unavoidable and if the only edge IPv6 has is a bigger address space I'm afraid it won't be enough to cut it. I welcome some debunking on the following assertions: 1. Even if we say that NATv6 is evil, there is little we can do to prevent it from happening except providing a solution that would bring somehow similar advantages. 2. Even if we say that individual /48s in the global routing table are evil, there is little we can do to prevent it from happening except providing a solution that would bring somehow similar advantages. However, 3. If we say that NAT is acceptable, half-acceptable, maybe OK in the short term (or whatever) it WILL happen and there will be no way back. 4. If we say that individual /48s in the global routing table are acceptable, half-acceptable, maybe OK in the short term (or whatever) they WILL happen and there will be no way back. In other words, it IPv6 becomes IPv4 with the same NAT crap and the same BGP stability issues due to an oversized routing table, it ain't part of my network designs. Back to what I disagree with, you seem to blend the PI issue and the SL issue into the same problem. They are unrelated. Michel IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Real life scenario - requirements (local addressing)
Hi Mark, Thanks for the long reply; I found it very interesting. A few more comments in-line.. (hopefully this won't drift too far off-topic..) On 7 Aug 2003, Mark Smith wrote: On Thu, 2003-08-07 at 17:47, Pekka Savola wrote: On Thu, 7 Aug 2003, Andrew White wrote: Just responding to a few points.. Real example: My ISP's DSL connection decides to drop the connection and reconnect (with a new IPv4 address, and thus 6to4 prefix) every 1-3 hours. I'd rather not subject my internal network to that if I don't have to. Switch ISP or complain to them. I certainly wouldn't bear with that kind of behaviour. If that kind of ISP techniques are commonplace, we may need to do something. But I'm not sure if that's the case. Experiences? [...] Since the realisation that dial-up was a dying technology, a lot of the dial up ISPs are providing ADSL, wholesaling it from Telstra. According to this page (http://www.broadbandchoice.com.au/isp-list.cfm), there are currently 149 residential ISPs in Australia, which is probably quite a lot for a country with only 20 million or so people. Ok, that's a lot: how many of these is typically available in a geographical area? That is, when you live in city X, how many possible ISP's are there? That is, do the ISPs have any incentive to be competitive about the customers? I.e. if one ISP provided static addresses for free (or something) but still the regular bandwith caps, would that possibly spark some interest for people to change to that model (and in turn, perhaps encourage the other ISPs to also change their IP assignment model..) A typical residential ADSL service is : * Single IPv4 address, so you have to use NAT if you want more than one machine (although at least one enlightened ISP allows up to 8 PPP(oE|oA) logins at once on a single ADSL service) This is no problem in itself (IMO).. [...] * The single IPv4 address can change over time. Most ISPs don't specify the time period, and it varies, but I expect that having the same single IPv4 address for a week is starting to be an an exception, rather than a rule. .. but this might be. Do all (or most) of the ISPs changing the address also provide premium static IP service? I assume your home PC (based on your description) is always on, so that these changes are not causes by e.g. reboots or DHCP lease expirations? [snip a lot of interesting detail] A lot of these ISPs also want to provide business ADSL over the same wholesaled ADSL infrastructure. They typically do this by : * Guaranteeing a single IPv4 address, that won't change. * Optionally routing a prefix for the customer LAN ie. no NAT. A lot of small business customers probably don't take this up, probably because they are told about the security using NAT. I'd suspect in most cases not having to change internal IPv4 addressing is not even a NAT or not consideration. Is it significantly more costly to obtain e.g. the static IPv4 address as a premium service? For homes? Note: consider how many of these techniques are used to prevent people from keeping servers at their home systems (i.e., does the ISP consider the changing address a bug or feature). Certainly a feature. ISPs quickly learnt not to filter incoming TCP / UDP ports to prevent people running servers, http or otherwise, so they use the reliability of the single IPv4 address they allocate as a dis-incentive to running a server. One might be able to make up a few legimate reasons for unnecessarily changing IP addresses, but I think the real reason is possibly the business case, and developing IPv6 might not actually help the situation that much.. Also consider how the situation would change (if any) with IPv6 provided by the ISP. I'd suspect they would probably allocate periodically changing /128s to their residential ADSL users. Let's hope not. Real example: at home, I use DHCP on DSL to get addresses. During 1 year, the addresses have changed _once_ (the ISP changed the prefix from which it allocated the DSL users' addresses). That's good enough for me, and I even manually glue all the IPv4 and resulting 6to4 addresses in my configuration files, filters etc. So what is the weather like in Finland ? I might consider moving :-) At the moment it's nice, but Winters here are _real_, not like there Down Under... :-) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Moving forward on Site-Local and Local Addressing
A) Deprecate Site-Local addresses independently from having an alternative solution available. This would mean that the working group should treat the deprecation, and requirements and solution documents outlined above independently from each other. If there was no consensus on an alternative a replacement would not happen. It is my understanding (and I am obviously not alone in this) that the WG has already selected the course of action outlined above. Mat IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-01.txt
Peter Barany wrote: Hi, Two questions about this I-D: (1) In Section 3.2.3 Sample Code for Pseudo-Random Global ID Algorithm, step (1) of the algorithm states: Obtain the current time of day in 64-bit NTP format (NTP) Question: Would it be possible to have the I-D specify that how the current time of day is obtained is beyond the scope of this document? What is specified is the format, not the source. It's necessary to specify a format in order to specify an algorithm. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards Technology, IBM NEW ADDRESS [EMAIL PROTECTED] PLEASE UPDATE ADDRESS BOOK IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Real life scenario - requirements (local addressing)
On Thu, 2003-08-07 at 21:00, Pekka Savola wrote: Hi Mark, Thanks for the long reply; I found it very interesting. Thanks for reading it. A few more comments in-line.. (hopefully this won't drift too far off-topic..) Hopefully. On 7 Aug 2003, Mark Smith wrote: On Thu, 2003-08-07 at 17:47, Pekka Savola wrote: On Thu, 7 Aug 2003, Andrew White wrote: Just responding to a few points.. snip [...] Since the realisation that dial-up was a dying technology, a lot of the dial up ISPs are providing ADSL, wholesaling it from Telstra. According to this page (http://www.broadbandchoice.com.au/isp-list.cfm), there are currently 149 residential ISPs in Australia, which is probably quite a lot for a country with only 20 million or so people. Ok, that's a lot: how many of these is typically available in a geographical area? That is, when you live in city X, how many possible ISP's are there? There are only 8 major cities in Australia, with the majority of the population living in them. I live in Adelaide, which as a population of about 1.2 million people, the forth largest city after Sydney, population 4 million. According to the Adelaide page on at the same site (http://www.broadbandchoice.com.au/), there are 97 ISPs ! (I'm a little surprised ... that is a lot.) A number of them are national though, pretty much only because they use Telstra's national ADSL network. That is, do the ISPs have any incentive to be competitive about the customers? You'd think :-) It seems that most of them follow Telstra's retail product lead - there isn't all that much difference between plans. Most of the smaller ISPs seem to win and / or keep business because of better, more responsive customer service, not product differentiation. There seems to be enough demand that maintaining the status quo is a good business plan. I.e. if one ISP provided static addresses for free (or something) but still the regular bandwith caps, would that possibly spark some interest for people to change to that model (and in turn, perhaps encourage the other ISPs to also change their IP assignment model..) I don't think so. Some of them are, it doesn't seem to have made much of a difference. I'm under a contract at moment, and fixed IPv4 addresses has only been introduced within roughly the last 12 months. For those of us that care about running a server, primarily in my case an SMTP server, the dynamic dns services are a pretty effective work around. Initially I didn't like the idea of dynamic dns, then I though hey, IPv6 is designed with the assumption of changing network layer addresses, so as long as the domain name stays constant, the IPv4 address changing occasionally shouldn't matter that much either :-) I've had some concerns email not being delivered because I dropped off of the net temporarily due to an IPv4 address change, but sending SMTP servers will try to deliver incoming mail for a few days, I should be back up and running within that time period. A typical residential ADSL service is : * Single IPv4 address, so you have to use NAT if you want more than one machine (although at least one enlightened ISP allows up to 8 PPP(oE|oA) logins at once on a single ADSL service) This is no problem in itself (IMO).. I don't know, we all know how NAT is breaking the Internet :-) I follow and contribute to the Networking forum (plus a few others) on this web site (http://forums.whirlpool.net.au/), it is quite common to see people asking how they get their p2p apps working through their NATting ADSL routers. (as a related side note, have a read of this thread for an example of what a commonly known ADSL router vendor is telling their end-users about IPv4 NAT - http://forums.whirlpool.net.au/forum-replies.cfm?t=103689) [...] * The single IPv4 address can change over time. Most ISPs don't specify the time period, and it varies, but I expect that having the same single IPv4 address for a week is starting to be an an exception, rather than a rule. .. but this might be. Do all (or most) of the ISPs changing the address also provide premium static IP service? Usually those ISPs call them their Business ADSL plans. I assume your home PC (based on your description) is always on, so that these changes are not causes by e.g. reboots or DHCP lease expirations? I'd guess most of the time it is ISP policy, sometimes equipment reboots at their end. [snip a lot of interesting detail] A lot of these ISPs also want to provide business ADSL over the same wholesaled ADSL infrastructure. They typically do this by : * Guaranteeing a single IPv4 address, that won't change. * Optionally routing a prefix for the customer LAN ie. no NAT. A lot of small business customers probably don't take this up, probably because they are told about the security using NAT. I'd suspect in most cases not having to change internal IPv4
RE: Real life scenario - requirements (local addressing)
Andrew, Would you mind if we put this sequence in the requirements doc? Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew White Sent: Wednesday, August 06, 2003 6:55 PM To: IPng Subject: Real life scenario - requirements (local addressing) A 'real life' deployment scenario. (a) I set up a local network. I currently have no ISP, but I want my network to 'just work' out of the box. This network consists of (initially) three routers, plus other infrastructure. (b) Sometime later I decide I want internet connectivity, so I connect to an ISP. I add my ISP provided address to my network in addition to the address/es that are there already. For argument's sake, let's say the ISP doesn't have IPv6 capability, so I use a 6to4 address. I do not want my internal addressing exposed outside the network, so I filter my addresses. I do use the ISPs addresses for external connectivity. (c+d) Meanwhile, my friend has done the same thing, except that his ISP DOES offer IPv6, so he has a 'real' IPv6 address. (e) We connect our two local networks together (either by VPN tunnel or a wireless link - doesn't matter). We can now send local traffic to each other, and out either ISP. (f) Sometime later I disconnect my ISP, and we use just his ISP. (g) Sometime later I disconnect my network from his. (h) Sometime later I register with a new ISP, and get a new IPv6 prefix. Salient points: (1) At points (a), (c) and (g) we have networks that are standalone and have no connection to an ISP or the global internet. Further, the networks in (a) and (c) have never had such a connection. The users don't want to have to register to get an address that works. (2) In (b), the external (6to4) prefix is unstable. Many ISPs allocate a temporary IPv4 internet address, and change these frequently. (3) The set of global prefixes valid for the network changes over time. (a) None (b) #1 (my 6to4) (e) #1 and #2 (friend's v6) (f) #2 (g) None (h) #3 (my new v6) (4) The only 'reliable' address that the hosts in my network have is the local one they started with. This example is quite similar to Tony's research ship example, with the possible caveat that a research ship might be big and organised enough to register with an ISP to get an address space plus connectivity they never intend to use. Consequences: - I need some form of local addressing that is not dependent on anyone or anything connected to the global internet. - I need this local addressing unique enough that I can safely join my network and my friend's network together and allow them to swap prefixes. - I want hosts in my network to prefer my local address scheme when talking to other hosts in my network. I want hosts in my network to prefer one of the local schemes when talking to hosts in my friend's network (since I don't want the packets to leave 'our' network). I want hosts in my network to prefer global addresses when talking externally. - I want my local addresses filtered at appropriate borders, preferably without having to set it up myself. - The ISPs probably want my local addresses filtered too. Looks suspiciously like the filtered local address proposal, doesn't it? -- Andrew White IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
Bob Hinden wrote: A) Deprecate Site-Local addresses independently from having an alternative solution available. A. -- Dean C. Strik Eindhoven University of Technology [EMAIL PROTECTED] | [EMAIL PROTECTED] | http://www.ipnet6.org/ This isn't right. This isn't even wrong. -- Wolfgang Pauli IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
apps people?
The few self-described apps people I've seen take a stand have to my recollection been strongly against dealing with locally scoped addresses . Have I missed anybody? It seems to me that people with strong app and/or host kernel background ought to be given a disproportionate voice in the consensus here as this is really their ox who's being gored. Mike IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Real life scenario - requirements (local addressing)
Pekka Savola wrote: On Thu, 7 Aug 2003, Andrew White wrote: It's whether an application can assume that global addresses are never filtered, and the answer is that it can't. Ergo, global addresses are also scoped addresses. There is a difference of a couple of degrees of magnitude here. Absolute yes/no are irrelevant (because there is always some filtering); it's more important to figure out the probability which results in the highest percentage of getting it right at the first try, a good percentage of doing well at the second if really needed etc. Imagine a parallel universe where *all* addresses are global. We can assume that there will be plenty of global addresses that are filtered to reduce their range of communication for the same reasons as people filter their networks today. So, the *probability* of a random global address being usable for communication will drop as a consequence of not partitioning the local ones in their own little pig pen. Worse still, there will be *no possibility* of receiving a hint that any particular global address an application uses may be useless for communication outside a local network. Why would you choose to have no information? - aidan IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Real life scenario - requirements (local addressing)
Pekka Savola wrote: Just responding to a few points.. On Thu, 7 Aug 2003, Andrew White wrote: When that 6to4 address goes away, I don't want my persistent sessions to be forced to maintain a stale address. Why not? There's no problem with that, really. You can continue using bogus addresses as long as you want, the problems only start appearing when you reconnect. Real example: My ISP's DSL connection decides to drop the connection and reconnect (with a new IPv4 address, and thus 6to4 prefix) every 1-3 hours. I'd rather not subject my internal network to that if I don't have to. I've made a counter point several times, and some probably agree, but really think ANY solution which promises automatic filtering is a non-starter. It seems totally bogus to create an assumption that someone upstream will just do it and rely on that. YOU CAN'T RELY ON THAT. Agreed. Which is why my border router ALSO implements the same REQUIRED filter, no? *shrug* But this particular issue isn't about whether local addresses are filtered. It's whether an application can assume that global addresses are never filtered, and the answer is that it can't. Ergo, global addresses are also scoped addresses. -- Andrew White IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Fourth alternative [was Re: Moving forward ....]
On Wed, 6 Aug 2003, Michael Thomas wrote: [...] I really don't want to drag this into a meta argument about the merits of various solutions, but only to point out that the entire document is structured in a way that the answer is foregone. [...] Exactly. Some others have also voiced concerns on this. For example, Rob Austein made a similar comment at the Vienna meeting (I was already walking to the queue but he got there first :-). At least I interpreted it like that. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Moving forward on Site-Local and Local Addressing
I prefer option (B), but I would find option (A) acceptable. Margaret IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
