- lir-wg - mailman.ripe.net

Refuse een assignment because it 'cannot' be routed?
by Herbert Baerten 02 Mar '01

02 Mar '01

Dear colleagues, in the discussion about assigning fixed address space to residential always-on customers, I concluded that most ISPs are eager to provide their customers with this service, even using it as a weapon in the competition battle. However in some countries apparently the contrary is going on. All ISPs there offer 2 classes of DSL service: cheap subscriptions (low traffic, dynamic ip, no options) on one hand and an expensive 'pro' contract (high traffic volume, static ip, router etc.) on the other. Now a customer would like to get a static ip but does not want the router, large volume etc so he does not want to pay 4 times as much per month (real-life example) just to get a static ip. If the customers sends a RIPE-141 request to the ISP, can the ISP assign a range but not route it to the customer? Can it refuse the request on the grounds that it cannot route the assigned range to a dynamic ip? Or is the ISP obliged to assign a range and route it (no matter how, presumably by assigning the customer a static ip anyway) ? With or without additional (reasonable?) cost to the customer? tia best regards, Herbert -- HB5351 Herbert Baerten Network Manager HostIT Benelux

4 7

RE: RIPE: last call for comments RPSL transition
by Christian Panigl, ACOnet/VIX/UniVie 01 Mar '01

01 Mar '01

Hi Joachim, well I'd say go for it. But let me kindly ask for the following thingies: since the RIPE-NCC is now in charge of the maintenance of the RAtoolset please make sure that there's a release available (specifically RTconfig) which is fully compatible with the RIPE RPSL server by mid of March 2001 latest. It appears that this might be available already (since Feb20 ?), however, the link to "RtConfig Patch for the RAToolSet" of the "RPSL Migration" homepage is broken. In addition, any clear links to concise How2do documents on RAToolSet and RtConfig would be appreciated. Thanks and kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl(a)CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---

2 1

RE: RIPE: last call for comments RPSL transition
by Lu, Ping 01 Mar '01

01 Mar '01

Hi, Joachim, We had a lively discussion about the RPSL transition during the RIPE-38 meeting. Well, if we can't fight them then the best thing to do is to join them. With the company's support behind us, we (Cable & Wireless Global) as a legacy LIR (used to be MCI) would like to work with RIPE to help the RPSL transition. CW will adopt a similar schedule as RIPE's to transform our Routing Registry into the new RPSL format. This will probably make all the mirroring LIRs' job much easier and hopefully all the downstream ISPs happier (only the RPSL format to deal with). So GO FOR IT. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu(a)cw.net > -----Original Message----- > From: SchmitzJo(a)aol.com [mailto:SchmitzJo@aol.com] > Sent: Friday, February 16, 2001 6:46 PM > To: routing-wg(a)ripe.net; db-wg(a)ripe.net; lir-wg(a)ripe.net; > local-ir(a)ripe.net > Cc: andrei(a)ripe.net; joao(a)ripe.net; hph(a)a.sol.no; > woeber(a)cc.univie.ac.at; schmitzjo(a)aol.com > Subject: RIPE: last call for comments RPSL transition > Importance: Low > > > Hello all, > > as you are aware, we are preparing the migration of the RIPE database > software to support and deploy the new RPSL format. The required steps > have been discussed in depth on various occassions (for references, > see end of mail). > > We are now preparing the most important step, really > transitioning from > old > RIPE-181 to new RPSL format: > > proposed transition date is 23-Apr-2001. > > This step, once taken, will not be reversed. The majority of the user > community takes a neutral role, while some want an earlier, > and a few a > later > date for migration. During the joint session of Routing and DB WG at > RIPE38, > the chairmen of both WGs were tasked to file a last call for > comments on > that > date, in particular whether there are serious, unresolvable > technical or > operational problems which would benefit from a slightly > longer warning > period. > > According to consensus at the session: If you are convinced that the > transition date as proposed would lead to significant operational > problems, please explain and justify why within the next 2 weeks: > > deadline for transition comments: 1-Mar-2001 > > Only well founded reasoning (including an educated guess > about the time > and resources required to resolve the issue) shall be accepted by the > community in order to consider postponing the transition. > > With the discussion about the migration going on for quite > some time, and > information available from various places, we do not expect a > delay, but > we would want to give everybody a last opportunity to comment. > > To summarize the dates, we are looking at: > > o 23-Apr-2001: switching to the RPSL database > - All objects are automatically converted to RPSL format > - Queries return RPSL only > - Mirroring follows new format and rules at > whois.ripe.net, port 4444 > - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net > - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, > but are autmatically converted to RPSL > - RFC2725 (Routing Policy Security System) rules apply throughout > > o 14-May-2001: exchanging mail addresses for submitting > RIPE181 and RPSL- > formatted updates > - auto-dbm(a)ripe.net only accepts RPSL updates > - RIPE-181 updates are still possible but now go to > auto-181(a)ripe.net > and are automatically converted to RPSL (again, > RFC2725 rules apply > here as well) > > o 15-Oct-2001: RIPE-181 updates are no longer accepted > > For further reading, please refer to the migration web page > http://www.ripe.net/rpsl > or for the discussion during the joint session of the DB/Routing WGs > please review the minutes. > > For technical specifications of RPSL please refer to > - rfc2622: "Routing Policy Specification Language (RPSL)" > Status: PROPOSED STANDARD, > - rfc2650: "Using RPSL in Practice" > Status: INFORMATIONAL > - rfc2725: "Routing Policy System Security" > Status: PROPOSED STANDARD > > Thanks a lot - the RIPE NCC and the chairmen of > Routing: Joachim Schmitz > DB: Wilfried Woeber > LIR: Hans Peter Holen > >

2 1

LIR Charging Publications
by Roberto Pezzile 28 Feb '01

28 Feb '01

Hello to all colleagues, I am Roberto Pezzile, network and telecommunications manager of Seven, in Castelfranco Veneto, Italy. We have recently become a new LIR. In the documentation given, I have a few questions regarding the publication of "Charging by Local Internet Registries" - precisely, ripe-152.txt; where "5. Recommendations" urges all registries to publish operating procedures, service details,and relative charges. In my working experience, mostly in Italy, but occasionally in the US, Brasil, Germany, France and China, I have never seen such Charging Information published at all, by anyone. Perhaps I've missed something somewhere. Even reference documents ripe-104 and ripe-112 did not offer additional information . I would like to know: 1. Is there a form to fill out and send to RIPE for eventual publication ? 2. Is there another LIR in our area which can show us an example of their charging policies and procedures ? 3. What is intended by ".....achieving consensus within the community served regarding the disposal of any surplus revenues"? I look forward to receiving information on the above, based on the practical working experiences of those kind enough to give me a hand. Thankyou very much Roberto

1 0

Re: Refuse een assignment because it 'cannot' be routed?
by Wilfried Woeber, UniVie/ACOnet 27 Feb '01

27 Feb '01

> > >> Now a customer would like to get a static ip but does not want > > ONE static IP address? PA, I assume? > > Yes, PA. > > > > >> If the customers sends a RIPE-141 request to the ISP, can the > > ISP assign a > > >> range but not route it to the customer? I guess, formally, the answer is YES. Because when the customer can document his/her need, then the LIR *may* assign addresses But, holding a block of addresses does not in any way "guarantee" connectivity... > > > > ... which would be extremely useful for ??? routing can be very different things: - distribute the announcement for that address space only within the ISPs IGP - distribute the announcement to direct EGP peers, but with "no-propagate", i.e. for providing access to a particaular server, or to suppoort dual-homing/mutual backup - make the address block (potentially) visible from "everywhere", by announcing the encopmpassing aggregate and/or the particular (more specific) prefix. The usefulness is subject to effects of aggregation and filtering - ... > In order to force the customer to buy a more expensive service which > includes fixed ip! Formally, definition of prodcut packages and charging for services is outside the scope of the rules for address assignment - with the exception that the address space itself must not be sold. > Please understand that nor I nor my employer is doing this or even > advocating this practice. To the contrary: I'm just observing that it > happens and am so displeased about this that I am looking for ways to > counter it. As I said in a different thread, this should be discussed in the frame-work of a BCP, either within RIPE or somewhere else. We might also want to leave it to competition to eventually deal with that (don't hold your breath ;-) > > >> Can it refuse the request on the grounds that it cannot route > > the assigned > > >> range to a dynamic ip? > > > > ... so, you want to rent a house and put a security guard on the entrance > > door not allowing people who bought it to move in. Interesting ... > > I think it is more appropriate to state that someone is looking for a house > but all landlords he meets will move his front door every day unless he pays > tripple rent. > > I suppose the question can be phrased more theoretically as: > > "If a LIR is obliged to assign address space (is it?), No, it is not. An IPS's LIR may have very good reasons (financial, security, AUP...) *not* to assign addresses to an entity wanting to become connected and obtain services, and even become a customer :-) > wouldn't it make > sense to oblige a provider to route it" No. That's what contracts are invented for, either implicitely by subscribing to a service or explicitely by negotiating ToS/QoS. > or the other way'round: > > "If an address space request is made, is the non-willingness of an ISP to > route it sufficient grounds to deny the request?" I think so. Unless there are other valid reasons for an LIR to perform an address assignment for a customer or peer (i.e. PI space, that is *not* accepted by the IPSs routing layer, but may be used on other links of the customer). > > Well, there is no formal policy obligation for you to route the addresses > > you assigned, but what would those addresses then be good for? > > That's the point. Can the customer somehow (e.g. by submitting a ripe-141) > force the ISP to assign him a static ip address? Or will it get him nowhere? It depends what the definition of "customer" looks like in that case. When the ISP does offer a package that includes the privilege to obtain service from the ISP's LIR, then the customer can probably (try to) use force (legal measures or refusing to pay fees). Trying to throw a 141 form at some free dial-in service provider would probably "get you nowhere" :-) But in general I would try to find a different ISP... ______________________________________________________________________ =Hi, = = This is a very interesting problem. = = As far as I am aware there is no obligation to assign IP space =when someone becomes a customer of an entity served by a LIR. Again, I share this view. = Possible problems when submitting a RIPE-141 document: = =- There is no obligation to process the request True =- The LIR may charge for processing the request True =- The LIR may charge for the assignment Not really. This is seen as "selling" addresses! =- The provider may charge for the routing True = You could opt to ask RIPE for a PI allocation, You could find an LIR that is willing to process PI requests, either for a charge or for free, or you can build your own LIR ;-) =but noone is required to route it for you. True, and for both, PI *and* PA =Regards, = =- marcel Regards, Wilfried.

2 1

IPv6 representation in perl
by Guy Vegoda 26 Feb '01

26 Feb '01

On an entirely different point, I would like to start a separate thread about the best way to represent IPv6 numbers in Perl. I have the following thoughts. Possible ways may be: (1) Using a 128 element binary array, and writing all the binary maths yourself to manipulate that. (2) Using a 4 element array storing four hex characters from 0 to F. Probably far slower than the above method, but smaller for storing many IPs. I know that Perl can natively think in hex, so maybe it would be faster than I think. (3) Having a complex structure, where the IP number is stored in parts - the top /48 (in any of several formats), with variable structure subnets underneath that. Could be tricky for the maths, if the variable bits are badly thought out. (4) Storing four "IPv4-esque" decimal strings in an array, or as part of an object. Then do the maths on each of those separately. Probably fast. (5) Storing a single parant /48 object (in any format) and have child objects with only the bottom parts of the IP to worry about. I wonder how that would work. -------- When I have gone away and read more of Mastering Algorithms with Perl, I will come back and maybe make some more comments. Just as a disclaimer - I am in no way making any comments on Manuel's already excellent libraries. I have already spoken to him about them, and would not want to appear to "go behind his back". This is an entirely intellectual exercise only. In fact, I would very much like to see Manuel post his own thoughts and real world experiences on the subject (of which I have none). I wish every one well, Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

Re: IP Management Tool - Minimum Requirements
by 'guy＠sirius-cybernetics-corporation.com' 26 Feb '01

26 Feb '01

> Yes I know about asused. It is a good tool for determining overlap > status or some missing attributes/contact informations and to get some > statistical information. I think it will be usefull to access asused from > IPMT. But my main concern was also whether we can find such a > criteria/metric that can be used both RIR's and LIR's ? Here are some > metrics I have thought; > > - Possible largest allocation left in the totall allocation of LIR > - How fragmented the allocation space (may be mapped to above one) > - How summarizable are the address space assigned to a customer. > - How summarizable are total allocations ? > > > Summarizability issues seem to conflict with RIR policies. However > I think that it is a fact of routing world. > > Regards > arif I do not think there is anything wrong with detailed reporting. I think that maybe the program needs a specification before we can really use metrics to measure anything. I too would like to see IPMT eventually give verbose output on the state of the registry. However, will this not to some extent duplicate functionality of programs such as asused-public that already exist? Please clarify what you would like, because I think I am still confused. I think that Maldwyn's comments would be useful here. Guy -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

1 0

RE: IP Management Tool - Minimum Requirements
by Arif OKTAY 26 Feb '01

26 Feb '01

Hi all, I was thinking whether it may be possible -usefull ?- to add some criteria for how succesfull the adress space managed. Regards, arif ao189-ripe -----Original Message----- From: Guy Vegoda To: lir-wg(a)ripe.net Sent: 2/26/01 1:50 PM Subject: Re: IP Management Tool - Minimum Requirements Other than adding that it should be useable simulteniously by multiple users without data corruption, shall I go away and write it now? Guy (Since no one else seems interested) > Hi, > > Following a presentation of an IP Management Tool by Guy Vegoda at the > last RIPE Meeting Tools BOF, interest was expressed in the development > of an Open Source version of such a tool and I agreed to use the lirwg > list to try and draw up Requirements for this. Hopefully this can be > refined into something that we can then begin writing Specifications > for. > > Please remember that these are *Requirements* - i.e. what the users > want the tool to do. Please confine remarks to this area and avoid > mixing in the *Specifications* - i.e. how those requirements will be > met - which we will come to, in good time. > > It should also be emphasised that we would at this stage like to > concentrate on _minimum_ requirements for a simple tool, such that it > would be useful to a large number of LIRs. I think we can use these > Minimum Requirements to produce something that may or may not include > more advanced features as well, knowing that we would at least have > covered the basic needs. > > Comments on this process and the document are most welcome, and > we would also like a good name. > > Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in > drawing up this document, and especially to Guy for presenting his > tool. > > Cheers, > > Maldwyn Morris > Software Manager > RIPE NCC > > -- > > Minimum Requirements for an IP Management Tool > ---------------------------------------------- > > 0. Introduction > > Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 > [1]. This document is an attempt to specify the minimum requirements > for a similar tool, with the aim of producing an Open Source version > for anyone who wants to use it. > > Below, I address 1. General Points about the project, 2. The > Requirements themselves, 3. External Constraint that must be > considered, and 4. A list of References. > > > 1. General Points > > Name: > > Let's use IPMT ( IP Management Tool ) as a placeholder for now. > > Users: > > We will target as users 'The Hostmaster staff of Local Internet > Registries which are Customers of the RIPE NCC and who need to manage > their IP Allocations and Assignments and the requests for same that > they send to the RIPE NCC' [phew]. We will call one of these people a > 'LIRHostmaster' and their organisation an 'LIR'. It may also be > useful to other people in other organisations to do other things, but > that will not influence the requirements. > > Open Source: > > We will release this software under the LGPL licence [2]. > We use this instead of GPL [3] because this means we will remain able > to using non-GPL'ed libraries, should that prove necessary. > > The RIPE NCC is happy to support this project, but of course its Open > Source nature means anyone else can use the code to begin their own > Open Source project. We are also happy about that. > > IPV6: > > We would be foolish not to consider the possibility of using this tool > for managing IPV6 addresses and writing it such that this is possible, > but we think it will be useful even if it does not and do not consider > IPV6 support a requirement. > > > 2. Requirements > > General functionality: > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 allocations. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 assignments. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > User Interface: > > LIRHostmasters should be able to conveniently access IPMT functions > from a wide range of Desktop Operating Systems, possibly including > non-modern, non-Unix-like ones. A GUI interface is the minimal > acceptable convenience level. > > A less-convenient interface to IPMT for more complex functions and > administration is acceptable. > > > 3. External constraints > > The RIPE NCC only accepts requests for new IPv4 Assignments and > Allocations via email to hostmaster(a)ripe.net and replies only via > email [4]. > > IPV4 Assignment requests must be in RIPE 141 format [5]. > Requests for new IPV4 Allocations have no special format. > > LIRHostmasters handle customer requests for Assignments via telephone, > email and web pages. > > IPMT must have access to the RIPE DB [6] or a local mirror thereof. > > > 4. References > > [1] http://www/ripe/meetings/archive/ripe-38/index.html > [2] http://www.gnu.org/copyleft/lesser.html > [3] http://www.gnu.org/copyleft/gpl.html > [4] http://www.ripe.net/ripencc/mem-services/registration/status.html > [5] http://www.ripe.net/ripe/docs/ripe-141.html > [6] http://www.ripe.net/ripencc/pub-services/db/ > > -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

IP Management Tool - Minimum Requirements
by Maldwyn Morris 26 Feb '01

26 Feb '01

Hi, Following a presentation of an IP Management Tool by Guy Vegoda at the last RIPE Meeting Tools BOF, interest was expressed in the development of an Open Source version of such a tool and I agreed to use the lirwg list to try and draw up Requirements for this. Hopefully this can be refined into something that we can then begin writing Specifications for. Please remember that these are *Requirements* - i.e. what the users want the tool to do. Please confine remarks to this area and avoid mixing in the *Specifications* - i.e. how those requirements will be met - which we will come to, in good time. It should also be emphasised that we would at this stage like to concentrate on _minimum_ requirements for a simple tool, such that it would be useful to a large number of LIRs. I think we can use these Minimum Requirements to produce something that may or may not include more advanced features as well, knowing that we would at least have covered the basic needs. Comments on this process and the document are most welcome, and we would also like a good name. Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in drawing up this document, and especially to Guy for presenting his tool. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Minimum Requirements for an IP Management Tool ---------------------------------------------- 0. Introduction Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 [1]. This document is an attempt to specify the minimum requirements for a similar tool, with the aim of producing an Open Source version for anyone who wants to use it. Below, I address 1. General Points about the project, 2. The Requirements themselves, 3. External Constraint that must be considered, and 4. A list of References. 1. General Points Name: Let's use IPMT ( IP Management Tool ) as a placeholder for now. Users: We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC' [phew]. We will call one of these people a 'LIRHostmaster' and their organisation an 'LIR'. It may also be useful to other people in other organisations to do other things, but that will not influence the requirements. Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Requirements General functionality: IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. User Interface: LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level. A less-convenient interface to IPMT for more complex functions and administration is acceptable. 3. External constraints The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster(a)ripe.net and replies only via email [4]. IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format. LIRHostmasters handle customer requests for Assignments via telephone, email and web pages. IPMT must have access to the RIPE DB [6] or a local mirror thereof. 4. References [1] http://www/ripe/meetings/archive/ripe-38/index.html [2] http://www.gnu.org/copyleft/lesser.html [3] http://www.gnu.org/copyleft/gpl.html [4] http://www.ripe.net/ripencc/mem-services/registration/status.html [5] http://www.ripe.net/ripe/docs/ripe-141.html [6] http://www.ripe.net/ripencc/pub-services/db/

3 2

Re: Fixed Boundary (/29) Assignments
by Judith Heffernan 18 Feb '01

18 Feb '01

As an employee of a large broadband provider, I agree with the recommendation of allowing ISPs the ability to provide residential subscribers multiple IP addresses without having the subscriber provide usage-based requirements. It doesn't scale to extend the rules that apply to commercial end users to residential subscribers. This would be equivalent to a tier 1 ISP having to manage the justification of IP address requests of 3million tier 2 ISPs. It doesn't scale. The subscriber should not just be assigned /29 worth of address space when they sign up for the service whether they need it or not. However, if the subscriber sign's up for the service requesting 2 or 3 CPE addresses, they shouldn't have to submit a RIPE-141 form or provide some other justification. It should simply be a service that the ISP can provide. We have many subscribers with multiple CPE addresses - however, that doesn't necessarily mean they have their own subnet. In a broadband cable environment, the subscribers off of the same downstream shares the same broadcast domain. The downstream is assign /24 which the subscribers are addressed out of. A subscriber with two CPE's may not have consecutive IP addresses. Would this mean the subscriber would have to register each /32? Or that the ISP has to ensure that the subscriber gets consecutive addresses (that would be a huge operational overhead for the ISP). The ISP should be responsible of ensuring the /24 is being effectively utilized. And this can be done the same way it is today for one CPE as it can for multiple. -Judith

2 1