Re: Real life scenario - requirements (local addressing)
Keith Moore wrote: > > > - I need some form of local addressing that is not dependent on anyone > > or anything connected to the global internet. > > no, you need some form of globally unique address that isn't dependent > on having an external internet connection. Nor on needing an external registration procedure. I'd like to be able to turn my router on and have it all just work. (Side point: hence why I favour using the router's MAC rather than my birthday and current system time to generate the network prefix. The former is hard-coded into the router and unique - the latter requires user intervention). > > - 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. > > agreed. > > > - I want hosts in my network to prefer my local address scheme when > > talking to other hosts in my network. > > you've not shown any justification for that. what do you care what > addresses are used as long as the traffic doesn't escape and/or the > hosts that you don't want to be accessible from outside your > network, aren't accessible from outside your network? When that 6to4 address goes away, I don't want my persistent sessions to be forced to maintain a stale address. > > 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). > > again, you haven't show any justification for that. it's far easier to > filter global addresses than to filter local ones. *boggle* Am I the only one that finds this claim nonsensical? > > I want hosts in my network to prefer global addresses when talking > > externally. > > why not have them use global addresses whenever possible? it makes the > applications MUCH simpler... Because (in the current context) there's no such thing? A local address is an address that promises to be filtered. A global address is an address that makes no promises. > > - I want my local addresses filtered at appropriate borders, > > preferably without having to set it up myself. > > sorry, that's not going to happen. how are the routers supposed to know > which borders are appropriate without being configured to know? you've > already suggested you'd like the same set of "local" addresses to > be routed between your network and your friend's network. On my 'home router / gateway' I have one port coloured red and placed on one side of the box. This says 'uplink'. The other ports are on the other side of the box and are labelled 'internal'. The rest follows from there. Especially since all my 'home router / gateway' boxes are using a common prefix for generating their internal addresses (say FD00::/8). Note that I either don't have or don't use the 'uplink' port on internal routers. It's not REALLY that difficult. -- 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)
Just responding to a few points.. On Thu, 7 Aug 2003, Andrew White wrote: > > > - I need some form of local addressing that is not dependent on anyone > > > or anything connected to the global internet. > > > > no, you need some form of globally unique address that isn't dependent > > on having an external internet connection. > > Nor on needing an external registration procedure. I'd like to be able to > turn my router on and have it all just work. [...] Sure, I'd not object to that either, but I could live with a registration procedure, especially if it's made simple. We're not talking about the registration procedure similar to obtaining e.g. an IPv4 /26-/29 from a RIR, i.e. a huge amount of headache and pain (for those who are not familiar with the procedures, at least). > > you've not shown any justification for that. what do you care what > > addresses are used as long as the traffic doesn't escape and/or the > > hosts that you don't want to be accessible from outside your > > network, aren't accessible from outside your network? > > 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. > > > I want hosts in my network to prefer global addresses when talking > > > externally. > > > > why not have them use global addresses whenever possible? it makes the > > applications MUCH simpler... > > Because (in the current context) there's no such thing? A local address is > an address that promises to be filtered. A global address is an address > that makes no promises. 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. So the only reasonable approach is provisioning the filtering yourself (of course, it won't hurt if you contract the ISP to also do it .. when you filter yourself, you can easily check from filter counters whether the ISP did it or not). -- 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: 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: Real life scenario - requirements (local addressing)
> - I need some form of local addressing that is not dependent on anyone > or anything connected to the global internet. no, you need some form of globally unique address that isn't dependent on having an external internet connection. > - 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. agreed. > - I want hosts in my network to prefer my local address scheme when > talking to other hosts in my network. you've not shown any justification for that. what do you care what addresses are used as long as the traffic doesn't escape and/or the hosts that you don't want to be accessible from outside your network, aren't accessible from outside your 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). again, you haven't show any justification for that. it's far easier to filter global addresses than to filter local ones. > I want hosts in my network to prefer global addresses when talking > externally. why not have them use global addresses whenever possible? it makes the applications MUCH simpler... > - I want my local addresses filtered at appropriate borders, > preferably without having to set it up myself. sorry, that's not going to happen. how are the routers supposed to know which borders are appropriate without being configured to know? you've already suggested you'd like the same set of "local" addresses to be routed between your network and your friend's network. > - The ISPs probably want my local addresses filtered too. then the ISPs can filter them. IETF IPng Working 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 reque
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.. > > > > > > > [...] > > 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 t
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: 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: Real life scenario - requirements (local addressing)
Tony Hain wrote: > > Andrew, > > Would you mind if we put this sequence in the requirements doc? Not at all - my pleasure. -- 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)
At Thu, 07 Aug 2003 14:25:18 +1000, Andrew White wrote: > Keith Moore wrote: > > > it's far easier to filter global addresses than to filter local ones. > > *boggle* Am I the only one that finds this claim nonsensical? I wouldn't phrase it as Keith did, but I think that I end up in the same place: it's easier to filter just global addresses than it is to filter both global and local addresses, particularly when there are so many inventive ways of combining different kinds of addresses to make still more addresses (eg, 6to4 + rfc 1918). Oh, you thought I -trusted- hosts with several thousand executable programs on them running who knows what to get this stuff right? Heck, I filter the NFS ports on boxes that have NFS disabled at compile time. Never trust any machine more complicated than a spoon. IETF IPng Working 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 Pekka, 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? > Here in Australia, the former government monopoly, now pseudo-government (50.(something)%) / private (49.(something)%) telco, Telstra, owns the CAN, which is used for pretty much all residential (at least probably 99%) ADSL. Telstra use the ADSL network for both their own retail residential customers, as well as wholesaling it to other ISPs, large and small. 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. 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) * A download cap eg 1000MB, 4000MB, etc. per month, with extra MB charged at around $0.15 each etc * 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. Some ISPs have introduced "unlimited" download plans, where, over a rolling period, the more you download, the less priority your packets get against other customers traffic. 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. * Providing a different helpdesk ph#, with shorter response times. * Providing much lower download caps, to make more revenue on business users downloading data. Of course, they also charge a lot more for the business service, typically twice as much or more, than the residential ADSL service. Apparently, a lot of small businesses are going with residential plans, as they don't find the business plan differences to be worth the money. (http://whirlpool.net.au/article.cfm?id=1165&show=replies) A lot of residential users, such as myself, get around some of the changing IPv4 address issues by using dynamic DNS services, such as http://www.dyndns.org. I run a client on my linux server, which watches the ppp0 interface. When the IPv4 address changes, it goes and updates the corresponding DNS RR with the new IPv4 address information. The TTL on the RRs is 60s. It would seem that a lot of residential ADSL users want to have domain names to the point where some ADSL router vendors are even building dynamic DNS clients into their devices. (ps, being a purist (or just enlightened maybe) I don't run NAT. I only have one PC that I want connected to the Internet, though, so I don't need to either.) > 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". "Uploads" typically aren't capped, so you could run a heavily trafficed server, with only the client's TCP Acks contributing to your download quota. Of course TCP Acks are pretty small, you can fit a lot of them within a monthly quota of 1000 or 4000 MB. 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. Of course, 6to4 is a way around that, but it probably won't take them long to wise up and start filtering that. > 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 man
Re: Real life scenario - requirements (local addressing)
Agree with Tony that Andrew's real-life deployment scenario sequence (a) thru (h) is of interest for the requirements doc. Fred [EMAIL PROTECTED] Tony Hain wrote: 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] IETF IPng Working 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: .. but this might be. Do all (or most) of the ISPs changing the address also provide "premium" static IP service? *Indeed* they do. What is interesting is that some of these "premium" services are fabrications, and they end up changing your so-called static IP address, anyway. Now there's frustration. Eliot IETF IPng Working 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 10:17, Pekka Savola wrote: > > 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? This is a business decision taken by many ISPs - in fact, many ISPs who use dynamic addressing are starting to deliberately lower lease times for dynamic IPs (1-3 days seem to be common these days, 1-3 hours does seem on the short side), and implement mechanisms in their back-end systems to be sure the user will NOT be able to renew a lease for the same IP, but rather always be given a new one after this 1-3 day period expires. This way, you force any users who require permanent addressing (typically users who wish to run servers on their home connections) to buy your "premium" service rather than your $29.99/month-for-2Mbps low-end product. After all, you don't want your $29.99/mo users to actually USE 2Mbps, since then you will be selling your product with a loss (yes. really.), so you force the users most likely to actually use your bandwidth, to pay more for it. If you happen to be the incumbent or through other means have near-monopoly in the local market, this becomes even more attractive, as you don't need to worry that much about users switching providers rather than upgrading to your premium product. /leg IETF IPng Working 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 Fri, 8 Aug 2003, Aidan Williams wrote: > >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. Ok.. > 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. Maybe so, but then the communication will fail *anyway*, because all addresses are blocked. It's more of a question "why are you trying to reach a node which has chosen not communicate with you?" and "why did the person publish the address of the node which he wishes doesn't communicate with others in the first place?" > 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? An ICMP unreachable message could be that hint. You seem to assume that it's a problem if you try to communicate with a random node and it refuses to talk to you. It's not, it's a feature (if the non-communication is intended). You should not be getting that address from anywhere (e.g. DNS) without reference to an application it should work with. If you do, that's the problem with the system administrator -- but the app can fail in any case so that's not a problem. On the other hand, if you just wanted to manually look up some address, and try to use it but fail, there's no problem as you should have expected the communication to fail (or at least, didn't have a high hope of success, and trying was your best bet anyway). -- 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: Real life scenario - requirements (local addressing)
Pekka Savola <[EMAIL PROTECTED]> wrote: |On Thu, 7 Aug 2003, Andrew White wrote: [...] |> 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. It isn't clear that there will always be another ISP to switch to... |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? I've brought up the notion of getting ISPs to change this business model before. Since the IETF can't mandate business models, any pressure would have to come from the technical side. |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). Given that forcing the address changes often requires extra work on the part of the ISP (and you occasionally see requests from ISP folks for better ways to shorten the address cycle :() I would assume that most of this activity is designed either to discourage servers or simply to create additional artificial levels of service. |Also consider how the situation |would change (if any) with IPv6 provided by the ISP. Why should it change at all? Similarly, why should the number of addresses provided change? ISPs that currently seek to detect and prevent NAT activity are not doing so out of a sense of architectural purity. Dan Lanciani [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: Real life scenario - requirements (local addressing)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why do this example give me the feeling that we are arguing over sacrificing the functionality for the majority for a few special cases. The real problem is a long-term scalable private address solution. There are other WG(s) looking at that. - - kurtis - On torsdag, aug 7, 2003, at 03:54 Europe/Stockholm, Andrew White wrote: > 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] > -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkYgaarNKXTPFCVEQJGPQCfQyCGGvUIDc62X8dV6GUgd6eec/sAoKX1 QpWklU58OMWlsP71UNC/j6Z0 =FArS -END PGP SIGNATURE- IETF IPng Working 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)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On torsdag, aug 7, 2003, at 06:25 Europe/Stockholm, Andrew White wrote: > Because (in the current context) there's no such thing? A local > address is > an address that promises to be filtered. Where? What determines the cope? Configuration? Then it's easier filtering global addresses. - - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 iQA/AwUBPzkZb6arNKXTPFCVEQLfnACdE+4Of0Q9Sm1q2sgYDcLnAduMYO8AmgOH aU8pwyUyaDmpSuGy9MYUrTHh =mXDA -END PGP SIGNATURE- IETF IPng Working 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)
Kurt Erik Lindqvist wrote: > > Why do this example give me the feeling that we are arguing over > sacrificing the functionality for the majority for a few special cases. It's a special case that potentially includes most home users, SOHO users, and personal area networks. Surely there won't be more than a few hundred of them? (removes tongue from cheek) -- 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]
