From fink@es.net Mon Apr 5 01:40:56 1999 From: fink@es.net (Bob Fink) Date: Sun, 04 Apr 1999 16:40:56 -0800 Subject: 6bone Prequalification for Sub-TLA assignment Message-ID: <4.1.19990330090417.009b2400@imap2.es.net> 6bone Folk, At the recent Minneapolis IETF meetings, the three RIR registries (APNIC, ARIN and RIPE-NCC) had meetings with various groups about their recent draft proposal for policies regarding the assignment of production IPv6 Sub-TLA address prefixes. One of the most difficult aspects of their policy (for them and for the IPv6 community) is to figure out how to go safely between the two extremes of either giving Sub-TLAs away too easily, or making it too difficult to get them. If Sub-TLAs are given away too easily, they will be encouraging non-ipv6 providers to get theirs now, i.e., the land rush model which could easily fill up the TLA/Sub-TLA space with networks, sites, and organizations that simply want to make sure they have a TLA/Sub-TLA, even if they don't need one now or really qualify (i.e., they have no intent on putting up IPv6 service and/or are simply not higher level transits). Alternatively, if Sub-TLAs are too hard to get, especially in the early days of IPv6 deployment, it will discourage providers from putting up IPv6 service, may give the impression that IPv6 doesn't help the address space problem at all, thus greatly impeding the progress of IPv6 deployment and transition, and even pose a legal risk to the registries. During the meetings and discussions with the registries during the IETF week, the idea of potentially using the 6bone as some sort of prequalification for getting Sub-TLAs from the RIRs was proposed. This could be especially useful during the "bootstrap" phase of IPv6 deployment and address assignement (say 6 months to 24 months max). This idea was well received by the RIRs, the IAB, the IPv6 co-chairs and various folk in the IPv6 community. Thus the idea was pursued with a first draft reviewed by the IAB, the RIRs and the IPv6 co-chairs. Now it is time for getting comments from the 6bone community, which is the purpose of this email. An overview of the idea is that a network wanting a Sub-TLA would go through the process of joining the 6bone to become a pTLA (for which rules and procedures are in place, and soon to be reworked based on the 6bone hardening effort now underway), and after spending 3 months as a pTLA would ask for a "fitness report" from the 6bone community (actually a small oversight group) to be made to the relevant RIR so that a Sub-TLA could be assigned (thought it will still be the RIR making the actual decision and assignment). Note that the RIRs will soon reissue a draft incorporating other ideas and comments from various sources, and will continue to have Sub-TLA prequalification criteria independent of the ideas presented here. Also note that the RIRs will still be the folk in charge of deciding who gets TLA/Sub-TLAs. Our processes, if adopted, will only be advisory to the RIRs. So, please review this carefully and send your comments to the full list above (unless you have some reason to say something in private to someone!). This will be open for discussion until 19 April '99, at which time the IAB, RIRs and IPv6 co-chairs will decide whether to move forward on an agreement about this or not, based on comments received. Thanks, Bob ------------------ 6bone Prequalification for Sub-TLA Assignment - draft 2, April 4, 1999 - Bob Fink The following is a draft to describe how the 6bone might be used as a prequalification step during the "bootstrap" phase of Sub-TLA assignment by the Regional Internet Registries (RIRs): It is predicated on the following facts: F1. the 6bone community represents the world-wide IPv6 operational networking community as of early 1999, including all existing IPv6 providers and users in the world, operating under the only IPv6 address allocation and authority in place at that time, i.e., the 3FFE::/16 allocation to the 6bone under RFC 2471 ("IPv6 Testing Address Allocation") . F2. the 6bone has a well defined address structure underneath the RFC 2471 allocation for high-level (top tier) transit service providers, know as a Pseudo-TLA (pTLA), that all the known top level IPv6 transit providers are part of. See for documentation of the pTLA structure. The pTLA structure is modeled on the TLA structure and serves as a proving/testing ground for those structures. F3. the 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and accepted by the 6bone community. See Section 7 for Guidelines for 6Bone pTLA sites. It has just been made Informational RFC 2546. F4. the 6bone community as a whole is willing to provide their knowledge, experience and opinions as part of a process to help "bootstrap" the Sub-TLA (sTLA) address allocation process for the RIRs. === 6bone Prequalification for Sub-TLAs S1. the sTLA requestor (sTR) places their Sub-TLA request with the appropriate RIR and declares that they intend to use the 6bone prequalification process (6PP). S2. the sTR (and the RIR?) notifies the 6bone list of their intent to use the 6PP. S3. the sTR follows the published process for becoming a pTLA (This will change by the end of the OSLO IETF meetings as the 6bone hardening process is approved by the NGtrans 6bone community). At the present time this process is documented by [RFC 2546] Section 7. This process currently requires 2-3 months minimum, based on this current practice, from the time of first joining the 6bone as a end-site network. S4. after the sTR has been approved as a pTLA, and operating as a pTLA for 3 months with at least y customers (either lower level transits or end-sites) (recommend 3 customers), the pTR petitions the 6bone mailing list for support of its request for a Sub-TLA based on its performance as a pTLA, providing relevant proof or statement of how and/or why they believe they have met current 6bone backbone practices (currently as in RFC 2546). S5. a 6bone steering group (consisting of 3-5 persons established by 6bone participant consensus) prepares a short 6bone fitness report report (6FR) based on input received from 6bone participants (note this means members of pTLAs, pNLAs or end-sites organizations, not just mailing list subscribers) and factual information of compliance with established pTLA rules extant at the time (currently RFC 2546) and submits this report (the 6FR) to the appropriate regsitry (will need a well established contact point for the three IRRs). S6. if after the minimum time for the steps above, plus 1 (2?) month(s), the sTR may protest to the appropriate RIR of non-responsiveness and revert to another qualification process per RIR rules (unrelated to the 6PP). S7. after assignment of an sTLA to the sTR (by the RIR), the sTR may optionally renumber from the 6bone pTLA prefeix to the sTLA prefix, or continue use of their pTLA. If the pTLA space becomes over subscribed, the most likely networks to be asked to surrender their pTLA would be those holding production number space. === Misc. Notes: N1. currently the RFC 2546 doc is being reworked under the 6bone hardening process now underway, which will almost certainly yield a stronger set of rules on what it takes to become a pTLA. N2. the current RFC 2546 doc does not specify a prequalification time as a pNLA or end-site 6bone site prior to requesting a pTLA, so it is recommended that a minimum of 2 months be specified (prior to the new rules being published after Oslo). N3. in S6. above, the total time from start of the 6PP until a protest could be made to the RIR, would be in the 6-8 months minimum (2-3 mos. while becoming a pTLA, 3 mos. while a pTLA, plus 1-2 mos.). N4. we need a way to handle existing pTLA sites that should not really have an sTLA as they are not production networks, rather they were created to "bootstrap" the 6bone or help a specific testing user community. This might include sites like INNER, TELEBIT, VIAGENIE, CISCO, NRL, UO, 3COM, MERIT, BT-LABS. Note that DIGITAL (now COMPAQ) is different in that they are acting as a real IPv6 exchange thus have not been included in the previous list. It is doubtful that these site would ask, but if they did it would be unlikely they could get a positive 6PP Report. So maybe the problem should be ignored and let the 6bone community police itself on this. N5. clearly this process will be none too quick between the time to get it firmed up and agreed to and the inherent time built into the process as described above. Thus it may get poor support if the revised RIR draft offers a reasonable alternative (of course that's why I noted this was a voluntary path for sTRs to take). On this we will have to see what the RIRs do in their next draft. N6. there may be a liability exposure of the IETF with this process, given the 6bone relationship to the IETF. This need not be covered here, but everyone should be aware of the issue. Things forgotten !!?? :-) Speak up! -end From hansolofalcon@worldnet.att.net Mon Apr 5 04:16:12 1999 From: hansolofalcon@worldnet.att.net (Gregg Levine) Date: Sun, 4 Apr 1999 23:16:12 -0400 Subject: 6bone Prequalification for Sub-TLA assignment Message-ID: <01BE7EF1.58D7AC20.hansolofalcon@worldnet.att.net> ------ =_NextPart_000_01BE7EF1.58DF4D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello from Gregg Levine usually at Jedi Knight Computers I hate to be a nitpicker, or a piker, but what about backward compatibility? And what about Port Assignment? And what about Service Numbers? Obviously these are minor things, but probably they will turn out to be important later. On Sunday, April 04, 1999 8:41 PM, Bob Fink [SMTP:fink@es.net] wrote: | 6bone Folk, | | At the recent Minneapolis IETF meetings, the three RIR registries (APNIC, | ARIN and RIPE-NCC) had meetings with various groups about their recent | draft proposal for policies regarding the assignment of production IPv6 | Sub-TLA address prefixes. One of the most difficult aspects of their policy | (for them and for the IPv6 community) is to figure out how to go safely | between the two extremes of either giving Sub-TLAs away too easily, or | making it too difficult to get them. | | If Sub-TLAs are given away too easily, they will be encouraging non-ipv6 | providers to get theirs now, i.e., the land rush model which could easily | fill up the TLA/Sub-TLA space with networks, sites, and organizations that | simply want to make sure they have a TLA/Sub-TLA, even if they don't need | one now or really qualify (i.e., they have no intent on putting up IPv6 | service and/or are simply not higher level transits). | | Alternatively, if Sub-TLAs are too hard to get, especially in the early | days of IPv6 deployment, it will discourage providers from putting up IPv6 | service, may give the impression that IPv6 doesn't help the address space | problem at all, thus greatly impeding the progress of IPv6 deployment and | transition, and even pose a legal risk to the registries. | | During the meetings and discussions with the registries during the IETF | week, the idea of potentially using the 6bone as some sort of | prequalification for getting Sub-TLAs from the RIRs was proposed. This | could be especially useful during the "bootstrap" phase of IPv6 deployment | and address assignement (say 6 months to 24 months max). This idea was well | received by the RIRs, the IAB, the IPv6 co-chairs and various folk in the | IPv6 community. Thus the idea was pursued with a first draft reviewed by | the IAB, the RIRs and the IPv6 co-chairs. Now it is time for getting | comments from the 6bone community, which is the purpose of this email. | | An overview of the idea is that a network wanting a Sub-TLA would go | through the process of joining the 6bone to become a pTLA (for which rules | and procedures are in place, and soon to be reworked based on the 6bone | hardening effort now underway), and after spending 3 months as a pTLA would | ask for a "fitness report" from the 6bone community (actually a small | oversight group) to be made to the relevant RIR so that a Sub-TLA could be | assigned (thought it will still be the RIR making the actual decision and | assignment). | | Note that the RIRs will soon reissue a draft incorporating other ideas and | comments from various sources, and will continue to have Sub-TLA | prequalification criteria independent of the ideas presented here. Also | note that the RIRs will still be the folk in charge of deciding who gets | TLA/Sub-TLAs. Our processes, if adopted, will only be advisory to the RIRs. | | So, please review this carefully and send your comments to the full list | above (unless you have some reason to say something in private to someone!). | | | This will be open for discussion until 19 April '99, at which time the IAB, | RIRs and IPv6 co-chairs will decide whether to move forward on an agreement | about this or not, based on comments received. | | | Thanks, | | Bob | | ------------------ | 6bone Prequalification for Sub-TLA Assignment - draft 2, April 4, 1999 - | Bob Fink | | The following is a draft to describe how the 6bone might be used as a | prequalification step during the "bootstrap" phase of Sub-TLA assignment by | the Regional Internet Registries (RIRs): | | It is predicated on the following facts: | | F1. the 6bone community represents the world-wide IPv6 operational | networking community as of early 1999, including all existing IPv6 | providers and users in the world, operating under the only IPv6 address | allocation and authority in place at that time, i.e., the 3FFE::/16 | allocation to the 6bone under RFC 2471 ("IPv6 Testing Address Allocation") | . | | F2. the 6bone has a well defined address structure underneath the RFC 2471 | allocation for high-level (top tier) transit service providers, know as a | Pseudo-TLA (pTLA), that all the known top level IPv6 transit providers are | part of. See for | documentation of the pTLA structure. The pTLA structure is modeled on the | TLA structure and serves as a proving/testing ground for those structures. | | F3. the 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and | accepted by the 6bone community. See | Section 7 for Guidelines | for 6Bone pTLA sites. It has just been made Informational RFC 2546. | | F4. the 6bone community as a whole is willing to provide their knowledge, | experience and opinions as part of a process to help "bootstrap" the | Sub-TLA (sTLA) address allocation process for the RIRs. | | === | 6bone Prequalification for Sub-TLAs | | S1. the sTLA requestor (sTR) places their Sub-TLA request with the | appropriate RIR and declares that they intend to use the 6bone | prequalification process (6PP). | | S2. the sTR (and the RIR?) notifies the 6bone list of their intent to use | the 6PP. | | S3. the sTR follows the published process for becoming a pTLA (This will | change by the end of the OSLO IETF meetings as the 6bone hardening process | is approved by the NGtrans 6bone community). At the present time this | process is documented by [RFC 2546] Section 7. This process currently | requires 2-3 months minimum, based on this current practice, from the time | of first joining the 6bone as a end-site network. | | S4. after the sTR has been approved as a pTLA, and operating as a pTLA for | 3 months with at least y customers (either lower level transits or | end-sites) (recommend 3 customers), the pTR petitions the 6bone mailing | list for support of its request for a Sub-TLA based on its performance as a | pTLA, providing relevant proof or statement of how and/or why they believe | they have met current 6bone backbone practices (currently as in RFC 2546). | | S5. a 6bone steering group (consisting of 3-5 persons established by 6bone | participant consensus) prepares a short 6bone fitness report report (6FR) | based on input received from 6bone participants (note this means members of | pTLAs, pNLAs or end-sites organizations, not just mailing list subscribers) | and factual information of compliance with established pTLA rules extant at | the time (currently RFC 2546) and submits this report (the 6FR) to the | appropriate regsitry (will need a well established contact point for the | three IRRs). | | S6. if after the minimum time for the steps above, plus 1 (2?) month(s), | the sTR may protest to the appropriate RIR of non-responsiveness and revert | to another qualification process per RIR rules (unrelated to the 6PP). | | S7. after assignment of an sTLA to the sTR (by the RIR), the sTR may | optionally renumber from the 6bone pTLA prefeix to the sTLA prefix, or | continue use of their pTLA. If the pTLA space becomes over subscribed, the | most likely networks to be asked to surrender their pTLA would be those | holding production number space. | | === | Misc. Notes: | | N1. currently the RFC 2546 doc is being reworked under the 6bone hardening | process now underway, which will almost certainly yield a stronger set of | rules on what it takes to become a pTLA. | | N2. the current RFC 2546 doc does not specify a prequalification time as a | pNLA or end-site 6bone site prior to requesting a pTLA, so it is | recommended that a minimum of 2 months be specified (prior to the new rules | being published after Oslo). | | N3. in S6. above, the total time from start of the 6PP until a protest | could be made to the RIR, would be in the 6-8 months minimum (2-3 mos. | while becoming a pTLA, 3 mos. while a pTLA, plus 1-2 mos.). | | N4. we need a way to handle existing pTLA sites that should not really have | an sTLA as they are not production networks, rather they were created to | "bootstrap" the 6bone or help a specific testing user community. This might | include sites like INNER, TELEBIT, VIAGENIE, CISCO, NRL, UO, 3COM, MERIT, | BT-LABS. Note that DIGITAL (now COMPAQ) is different in that they are | acting as a real IPv6 exchange thus have not been included in the previous | list. It is doubtful that these site would ask, but if they did it would be | unlikely they could get a positive 6PP Report. So maybe the problem should | be ignored and let the 6bone community police itself on this. | | N5. clearly this process will be none too quick between the time to get it | firmed up and agreed to and the inherent time built into the process as | described above. Thus it may get poor support if the revised RIR draft | offers a reasonable alternative (of course that's why I noted this was a | voluntary path for sTRs to take). On this we will have to see what the RIRs | do in their next draft. | | N6. there may be a liability exposure of the IETF with this process, given | the 6bone relationship to the IETF. This need not be covered here, but | everyone should be aware of the issue. | | | Things forgotten !!?? :-) Speak up! | | -end | ------ =_NextPart_000_01BE7EF1.58DF4D40 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+Ii4DAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYA5AIAAAIAAAARAAAAAwAAMAMAAAAL AA8OAQAAAAIB/w8BAAAAMgAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABEEJvYiBGaW5rAFNNVFAA Zmlua0Blcy5uZXQAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAADAAAAGZpbmtAZXMubmV0 AAMAFQwBAAAAAwD+DwYAAAAeAAEwAQAAAAsAAAAnQm9iIEZpbmsnAAACAQswAQAAABEAAABTTVRQ OkZJTktARVMuTkVUAAAAAAMAADkAAAAACwBAOgAAAAADAHE6AAAAAB4A9l8BAAAACQAAAEJvYiBG aW5rAAAAAAIB918BAAAAMgAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABEEJvYiBGaW5rAFNNVFAA Zmlua0Blcy5uZXQAAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAAAxAAAAADAAAwBAAA AAsADw4AAAAAAgH/DwEAAABlAAAAAAAAALU7wsAsdxAaobwIACsqVsIVAAAA776nYflh0hGGQERF U1QAASSBAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAQA2Ym9uZUBpc2kuZWR1AFNNVFAANmJvbmVA aXNpLmVkdQAAAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAADgAAADZib25lQGlzaS5lZHUA AAADABUMAgAAAAMA/g8GAAAAHgABMAEAAAAQAAAAJzZib25lQGlzaS5lZHUnAAIBCzABAAAAEwAA AFNNVFA6NkJPTkVASVNJLkVEVQAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAADgAAADZib25lQGlz aS5lZHUAAAACAfdfAQAAACwAAAC/AAAAtTvCwCx3EBqhvAgAKypWwhUAAADvvqdh+WHSEYZAREVT VAABJIEAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAAAAQAAAAAAAAE7IQBBIABADIAAABSRTogNmJv bmUgUHJlcXVhbGlmaWNhdGlvbiBmb3IgU3ViLVRMQSBhc3NpZ25tZW50AJMRAQWAAwAOAAAAzwcE AAQAFwAQAAwAAAARAQEggAMADgAAAM8HBAAEABcACgAvAAAALgEBCYABACEAAAAzRDA0NUIxRkUz RUFEMjExODY0ODAwMjBBRjAzM0NCOAAVBwEDkAYAcBkAACIAAAALAAIAAQAAAAsAIwAAAAAAAwAm AAAAAAALACkAAAAAAAMALgAAAAAAAwA2AAAAAABAADkAgJRaqBJ/vgEeAHAAAQAAADIAAABSRTog NmJvbmUgUHJlcXVhbGlmaWNhdGlvbiBmb3IgU3ViLVRMQSBhc3NpZ25tZW50AAAAAgFxAAEAAAAW AAAAAb5/EqdvH1sEQOrjEdKGSAAgrwM8uAAAHgAeDAEAAAAFAAAAU01UUAAAAAAeAB8MAQAAAB8A AABoYW5zb2xvZmFsY29uQHdvcmxkbmV0LmF0dC5uZXQAAAMABhBlv/j2AwAHEKwdAAAeAAgQAQAA AGUAAABIRUxMT0ZST01HUkVHR0xFVklORVVTVUFMTFlBVEpFRElLTklHSFRDT01QVVRFUlNJSEFU RVRPQkVBTklUUElDS0VSLE9SQVBJS0VSLEJVVFdIQVRBQk9VVEJBQ0tXQVJEQ09NAAAAAAIBCRAB AAAA8xUAAO8VAACyMAAATFpGdcf7KMc/AAoBAwH3AqQDYwIAY2jBCsBzZXQwIAdtAoCmfQqACMgg OwlvMAKAJQqBdgiQd2sLgGQ0bQxgYwBQCwNjAEELYG4gZzEwMzMLpiBIlGVsCQAgA1IgRxIAIGdn IExlE2BuZRAgdXN1B0BseSCKYQVASgmAaSBLAwAMZ2gFQAhQbXB1dM0EkHMKogqASSAPcBkglCB0 FiBiF0BhIAMAIHRwaWNrBJAsIC8FsRqQGuAbE2IZECB3LxnhF9AG4BwxYgDQa3edCxEgBaAY8Bfg aWIDEGEawHk/IEETwBxaUO8JER6ABBAYgG4HgAIwHn/LBmETYGMXQE51BtAZMVkgcE9iE2AIYHMX sXTOaAeQGnESACBtC4AFsdMjMAuAZ3McBHADYB0Q/wJgIxMXwAPwFgAaIAhwA6D3HNIaNAdwcAkR AHAFQAtglRkhLhlkTwOgU3UTwDRheRtAQSTwAxEwNAkbQDE5KdAgODo0KjEfcE0bQEIlECBGAQuA ayBbU01UUFQ6ZirxQAeQLhcwdK5dHFADYBkgOhlkfAMwWxSQD9A2BuAXMUYG8Gv3G0AZZBSCIC0k Ll8egCaR3SNAIBIAIdAngU0LgBcwDmEnMB4wBCBJRVRG/yPACeAd8CRjMLIjMAnRB/DUSVIw4WcE AHQIgQQggChBUE5JQywvbzsegDOwThfQHqEzsFBF4C1OQ0MpGdEdgDJ2syXBIzAgdgrAIsIgCcDd CGBwBCActCMxaQXAMPThNR8gZHJhAYAk4icw3nMHQBYwBbExwmM0YhahtwsRJFEwo2Ef5xtQZiTi HmQUAB3wAiAyEFB2NoM6nyiRYi1UTEEX0D5kO7AHkAQgJPABEGl4/yvhIoAXMT8BMLIEYDQwO6Aj BpArkGN1bByRc3C9BZB0BCBDJDoBPON5QC//NJA8oiMxFnA2gkclP9Mdkn5tKLAeQTdAMfEaMSuQ Z2cIcEMBHDFobwfgGjFnexYgPGBmFfBF7w/QGmB0lncJ4TMEdxYgZXg0QP9HgAeRPwE58CMxBcA0 EBcR3xbQQUU5UR1QIxFvTYE+UN8DECjxBbBLjyPAYROhFtD/GsBQE0PoSsIPsEdTKAUuv/0vykk/ EE9II6FO0UzxT9/fJYgaYQnwBaAIcGE0ED3h+SPwbi0FIEAPLWEk8RNgvwSBSYNT1ToABCAj8Hcb QHBpLmUuMvQU0R2Acv8XYDhgBGIDIBxgGvA4YFnx/mwdgFBkWx9JwSXxOTAwo/1BgS9BRkSQANAX QDgzLBH5TXByaySBAJAZICSBNoL3BbA9kAMAeh3hAiBJgRnh/2DPZKEY8BexHVAngRoxUiH/F0AX cCOhJYMPcFewGoFiqV8bQBcATPEGkCV0ZAIgJ/8FQBcwCYBmjxtQFzFdsRtSuxIAF5NxF4EGkBfA KF4H/2llI/AnAAIwPsMDoBkBMqLfYiI/72dUIZU2gS8bYiOh32elI/BKYRiBTqFsasEmAfc7wACB RNApVF9VbzBhRFD/BJEd4XVRKPFrEVbLUCIPcf8dgFOkaqFEkgcxF7ELgDCj/TGgcmCvO4Io4ETj SHMBAP0LUG8GwCBBXeEcQSXiGDD/BPBaAxdAXDgWQ3Dfce8hlP8bQADAF8BXkjCjJxFB8j+iu2ZC fmVvB5BrsiNAbGJE/0HGY2OCnyTjdTBHkRyRFgD3MvI40zGgdHviGPAYIT3l/yTxCcEEEX5PHJET wIhPdYb/P6FlBGrDPEEacnUwPZADIP0FEHMrEBoxMLQ0FnYvdz/9D9BECHE95TenNoKAAhdg/4Vy OBWRvDuglOgyIpO/HFD/CeAuIYTTAQAakD8CLIECMP97tBdgPdYtlD5QSxADcGjB/x+SPwCZT0Iy bnQa8GXTPJP/U9GB009HFkMwsjOxOBGdQfc8FAmAQsBUJEAZVS/KYAS/WaJ7eBdgARBEQJhKIgbg 9yyANDExsCIboA9wI2GMn39mfw/QNoJBxj5UTeEngShfPGAXwEigBGACMGhJgzL2NKx2AMB4dhCj Y5r0opL/TNAWAKl/MONXoaURIxOiM7Ey9ElBQrGlSIQtD2H/XXI2gjiGAhAuEHwFr09Ibf+jUjjR mseikwhwF3CwwTgz/xqQK5APkEPBO8MSABNisMO/tP+xvKJDNoKyX0KxTkqR/1KRSXIHcaBaup9I syBBoZn/LZRIxxtAX6RJcovSCHCQY+9DIzHxR4ALcGySn5OvMGH/JlFXsCGhB9FDJZsDw6Mcgv9k BmgDPdIakEFGTXBgIkrwf8aPM0IIYBiQi7Yh0Ixkar5vC4CcbBozHaEacnBBgv9HE1+kXvB1MKOv qnTNw5hR/weRI5J8EQtRhAI2gp1whZL/GkMSAGRCsMKoEWVBTQQtk//Rr3qDCfA90gERH5Jtkiix +wSQT+EpZQQ70U6hRJETwP090jOsdp1B0DXLY9c/PkHXKxA8ohqQIiuQdBcwBBH/EgAnMqfQwa9I 5TSQANAmIP8XlEsQAMCvL20ix+Ef8Rih/zkDN0AaNADAAQCReHUxJ3L/M7KdcMlGQUak1uJ/q0Yd gP4oIzDNMr6hf5U0MFllogX/UhY+E+GDfrE9IIVzjc/pGP8gMnYfxm8tYb5QGgIccqII/+qz1OIS AAQBClAagTu0C4D/BaEnMR3hPeEsgE6SmwKV8//w38ENOIadcAhwzfFlBCXT/wWgymL0ERoxaYNB Rfafn0//HZAFEBkhBzBwIX7B2xE+xf+axkIjD6BwQR2ATpFeIHhR/51w+790cvIv6r+0Rg9igIH/ PwHtIj3DHGBTs9GfD9FiuP9CsqaQzbZk4msRN3A8MABh38MhJeIOMBexGmJkE2Cdwd9QAqH377/w z0EhbxtAjTD/UGEw0sgTxMP9cEJRREAXsvPUotsRIHlaAcEIkYUQkt8noDQhDc8commhKCiw0XH/ 3CARgWl0nXNuAZ1w1QOsIv+dciQz0+ORMDiAGgSdci2x/iHvrw2vGj8H0q4yWVY8MH9M8d5illjZ kesBKbEpFSf/KdBlAX+RX7O+87HGG2+8eP+ynX+0BeJjoWtQToNoYhSi/95hopB6se2DidCMMauz IT//OWcx8d5xdIFQwNYXwRewZv9CwCcPKx8sL6NhjzBkcS0/OS7PIEKJgC/fMS8gLfczXzI/nNVQ n2/ecUFGVyC1PnctO6UyUMAfJDRQwJ8e8B+QM0A0fzDiIEb0wP5rOh87v6NhBJONQLiwUmL/3CK5 hOShX2CWcJEwCzFKg/2ct23j4wsxphGqsdwhPM///M/q4X7Qpn+njuc27wi6b927dlKXsSYQkQFJ cEF4oJdT4Ulil+UookIpOkgP/0uvsfC+o0NRUwD9cdZIPig6Zuyxc0ufTK8zMEYx/wjA4C/hMd9R ABS3RMnxYDD+Lbiw5SG2Ex1R9TJJolFv/2QG20LgyNwRyGF8gzmjXeG59NBsddsze8HFAHiX0f/b QoJfiRaA5aqSphEjoXwV/1TzDwBV9YHy2bKXUwrjthP/qtVb74oCzeCgBKqTKFDqAP/98Xvz1COJ 0gK0vwF5MW8WAdtwRkZFOjovMR9b32J7kYWc5F/EUkZDpa0RN1DgKCK2E1TTgJ2B00GHhXhgYrYi KWbPVCA82qBwZoAvbbEuV+1RZaDTUC/0wC0CYnMQL3JmY2oCLnR43HQ+GT9RX1JhMlKqqAF/0CGv An6xuSDpood3jxB1/+GBeiHZo9cQ5uCXRGnGcU/vYoreYsNQzVAt5eGG8OnR/6LwvuF1wOSBjySD poCoDwDua9liQf8zA1CoIFpwsvD/0GPQUtohyVQc8ZdifCLVAv+HEHlkthN6dl0JJpB8v9QQ99hg /xIIwFOVkG2Q5ABtw6p3hOAunOMuycEvnONCLW8hdHYyLarSLY8eICZwANDkAG1sPiWC94J/uXBi wHUmwqAEyGXQU/9096NSii4+stug2IDRcNZW/4ffB/J06RD0yADTgtwje4L9v9AvhiLbQuQy+bHe Yunxv6ghdPcIsY2Pk19ScDNSqv/Nxt5iz8PKhH3fPrJzrPZ//apiY2SACjKw5uBthAOaL++EX4Vq zSG/si3TAOyxezFfhzKHgIQgoREmETe/M0e+dSRREyDfAZ2PvzM2MPC/ljKKU/4BCLFN0XNCah4g /0FSHXHlA0nw3mHlAFZEabS4NTQ2cC+UX1JhNFKv/1jGrqEGcNFwmOMKoewzBoD/XQXlcrNAfBOM 4QVwLr8zMP9bEFYByCBaQI9kCiDOkSYQ/9vzg5WQVM3z+sLl0HnwRWrnjV8Oo+dFKHOYo3R2Ypnv lmoML6kfUeg9u3C6XzWP/zafCKCTT7pPDsFSlbZi87Hv/QBq0d5xtlFS5IDUI1STf66B5zbCBRzB dhTAH2SgcP/TARfxGDLmUtpS7SHUMNNy/wK2ZAICgPmx5KFd4dafQq/D/TnNxig2UFAZL7//vw6y cnXCseFRySLrlD/kgP8pAf1Bw0SrNRMi/yWugcjj/z9TXeHOf6r0zSDNX85vDsHvlZXQEk9UVJRw 50ATIeWQ75HQlm+XdKUDKByH1t8FIh9fkF6Qm9URQv81T1NM4k8g4EVURiUwJqCRMv+QE3KqJeAR QGsCzIXcfz6z58aCKsGbxk5HenOrPs1A/wDwAuQABSBW8+DiP8x3ECHriPabpFuoBl2huIsiTgP7 suQeEHImkDhAEMDnr8HztyOQkAGGcDMlMThAaIyB+7GBnNBtKTkQBOyUzHGhBP8PAPhDwXIgYu0f /yL9UCOg+ThQam+xgUT1q0SQMxFB/i2lUle21b/Wzw7BqtE/Mf9f9dASc0Kmg+OHkDSYQR+x/7Ez X0b7d4efMwPu58TTfyF/DzI4UFmwHhE/cBYQI6Eo/yqgJMM+UQFyeXN6dSiy/d//9edLcNBAKnEp 85HQ7uAAh/9+04oix1AdYCBgofLRuqdwnxzgawEDH9JkluJzdcaA/5bwslMCssRWluKXsMPWKVf/ ArJfMadDsON8j1zD+9NdBP9rAiaQeWFjQIGDRoEKIolh7yazicJAMmNBL5bxIACb4/9ZsEAAvYB5 cQ5/yIRGMCVhzxdB8NerRClQY2uWFaEE/0sR7IeQImQhqAbNT/f/taL+NflRqzVEYbChkVV58BhA R7GxWzVGgTMtNQ1ic/+xsmrRKCDZpZvRyg+DOL2w/mkg0DhBHeL18ApQBLHLcb8g0ZACj7BjsRaW vaB0oxHvKlIKgyVFzQBGwtAgzwyZ/m7ZcCWSKpTx9JYFIfjM4d9vAvCEiTDkwokwbUAAXhHPRoAm f9tze/FwTr7ClvHLBDcRcWdjQGl6eHN78d9vAaYkCDXSZApQYj/EBiH/LE9jM0/yvWFkEadHicKX Qf/DAMbgsOLE0x+KpQOPABCw/x9hb/AQ4n8gMh/yRxg6GVf/j3TD4EEQVIPwsSW2qwMmQb9ohTfv xmsQkOAgrAByWbD+KNwy9nF0QnOUH4od4R+g//GQ23D0kQn0PT9I5BCQVYH+UkthGe8a/7WxqHBk ELKB3/mH73XnBLh2HOFwkEG80N8VwA/RWmCQQGoxMtER7wP/tlB+0EX/z8encFmwzIGGIv9ohsZ+ snFvAG7gdKEKgIFR/xXAJPNjQhCQFcCyQEufszL/Y0BvEAFiy6/Ms/xxxyM29P4oq+AQkRHRyTPV RUTPRd+ftaLrgfl0kDAeEGduEgb/Y0DBpGiV0BOb1dDhBkVM9f9X/7FRp5RggfER78Ar0fH41yll mELLcWaucHhbCGDF/2FAfuAC/91i7xFu0MSAyXP/0selAqWhiepi4HtBlyMu0vtRITFIZAZTYt+M kaZRvYD+a3mQIFD2hbMjlyCQIWogf8kzClDxAnWxZOlzkKBwbH+bscmiklFonxJxbXDhhWT/dSGi Al9FZnNW31fvu1/+lKpN0oBjhABOTZI6c6//dY/kcMFBGFjQozpViOLjQv+XIBBU9rKZwZGx+aXg zXaf98x3rsF6tHdNQAZQrJC9sH/FAD/jvXBpszVgskAIQG79GMF5sMBtcSPhtCC+AK8g/xGRFgEs L+4CNwO+AayQ/9H7rACzMGFqIGrlZvLbVXE//3aPd5HPpfDmeNuYEJABL/L/T/DHwL2QrCHLbzk0 Dj/LJP8t4S4qHHb2QsbBkgKzUAtF/9soBlAfMIPy54/uAwUVVfLvyFKXsEgmsnEy7vZrMYo0/7DA KPCYgI9mwXIgoBKgVRPPkZ95xdl4+XRPc7dgVs//hp93gtgBGSFHEknV8lNNkP+n0Uik8hIRsbJE 1UV6secQ/39hTWabXzTRbWWm00310OHPfrFtVhkhPHMtOO79SqH/7tO5L6qRftGswdrdBlCl9Pen ZfumSkQtlJKmMJovmz//d4L5QUCgQCdNQbNCx3Gnof+wcB4lZiQus8hDJAFtYi/y/xCQXtMVoqw/ WofgVBjREJD/L+NvymqFBlD8kQFiE3MBwc+IMbFRVeSyDyAivNBNkLuBEcZwInsZ2qE8gGwdsP8j 4ZVkeYBNotsiZIHasOVn8+uV2xBnaKDP4zEN8EpQj6KhLqRqAt9gTk5Fo2GAVEVMRUJJVAZQwFZJ QUdFTt9wBlAgQ0lTQ08GUE5SqkwGUFXBoTPBkE0GUA5Nv/DAgb1/IEJULRmzcEJTdQTINERJRznA gEFMKoISoMJxUEH+UUrg6UJTcGEg8ROkI//Rf7PWwy8cUPGR/NaxUt9gUP52eUA3UN2VSzBKYRWj L/L/+pO+lSjwpCWK0RAgHZCXX58JpGWRkVLpYZjwdGY3AP/Ht2SR9jNtRGth7+EoUUdR/xNzEEDN QRaQbUbOX3qxagX/E3Oh9IFgk6IKgD9xKMGfk/ZSJVPrkFORIE0xbaPmcv5vH8AR8LCV1C+j41nw jeD/+0IFYQAA5jTlDUIhU2A1Yf8CsQIwEWHwdKsfrC93kRwx+76wABByeGPr2T/jazFPkf+dspEg 7lEXMKfB9qD6ojkH/4+x1oK8gN/v9BLpsHqhuoH9BWFhHXBAQlKDk1KkAgFh/xIS5MPScDCgx3JN 9ewGjDD/5a+JkDcgZ+RJxLyySmGEAf9NMtaCCoAKKdK0UPIxEPtB/U8iZAJw+YDrP2SxxyHKNX8f MR+xTkHp0ADgXsDXIyhvNLMWQGSRk3In/2ETQUm/L+KTQ3mhfoCMT3SCdm9Q/5/hI5BNUbYBCgRb kGrjhDL/qwCZ0N5krYI/4xWja8JEUf+Ds1wF6y/sMZEhpDNswSCg/zdg8FTez9/fd5FHIVLiomL3 E6IcUTUhYjCh3UE3UNbhxxZAZKa/sEVURjWE4cr9BlBnUEL/z3sZVaMvkisA/x2wTfUDsry1QDPM RLwRUSG/IBHo4tJTBY+OAFEheY7D/7C0azJ+gAMYMRA7IHEv/6+/D390kbzRfDAjwEjxZ02QA1Xg KAAhIT8/IDq6LUrgUx8AhEDnISEQr7kT/yAtLmEVDxZkfXKQAgAYEAADABAQAAAAAAMAERABAAAA HgBCEAEAAAArAAAAPDQuMS4xOTk5MDMzMDA5MDQxNy4wMDliMjQwMEBpbWFwMi5lcy5uZXQ+AAAD AIAQ/////0AABzAAGovmEX++AUAACDAAGovmEX++AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOF AAAAAAAAAwACgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAA RgAAAABShQAA8xUAAB4AJYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAA AwAmgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAO hQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeAEGACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBC gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAAeAD0AAQAAAAUAAABSRTogAAAAAAMADTT9NwAA0kA= ------ =_NextPart_000_01BE7EF1.58DF4D40-- From rrockell@sprint.net Mon Apr 5 15:11:17 1999 From: rrockell@sprint.net (Robert Rockell) Date: Mon, 5 Apr 1999 10:11:17 -0400 (EDT) Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <4.1.19990330090417.009b2400@imap2.es.net> Message-ID: ->This will be open for discussion until 19 April '99, at which time the IAB, ->RIRs and IPv6 co-chairs will decide whether to move forward on an agreement ->about this or not, based on comments received. If the 6bone Hardening effort is not fully developed yet, maybe we can hold off on the date to see if the efforts of this group prove to be fuitful, or at least agreed upon, by all interested parties? However, this is not meant to say that we should hold up the delegation of TLA's till after Oslo, simply due to scheduling. I am afraid to move forward with the assumption that the hardening effort will be written in stone, and used as an advisory to the registries, if it has the chance of not being widely accepted withing the working groups, and particualarly the 6bone. Just a humble opinion. Rob Rockell Sprintlink Operations Engineering 703.689.6322 800.724.3508; 3858833 -> -> ->Thanks, -> ->Bob -> ->------------------ ->6bone Prequalification for Sub-TLA Assignment - draft 2, April 4, 1999 - ->Bob Fink -> ->The following is a draft to describe how the 6bone might be used as a ->prequalification step during the "bootstrap" phase of Sub-TLA assignment by ->the Regional Internet Registries (RIRs): -> ->It is predicated on the following facts: -> ->F1. the 6bone community represents the world-wide IPv6 operational ->networking community as of early 1999, including all existing IPv6 ->providers and users in the world, operating under the only IPv6 address ->allocation and authority in place at that time, i.e., the 3FFE::/16 ->allocation to the 6bone under RFC 2471 ("IPv6 Testing Address Allocation") ->. -> ->F2. the 6bone has a well defined address structure underneath the RFC 2471 ->allocation for high-level (top tier) transit service providers, know as a ->Pseudo-TLA (pTLA), that all the known top level IPv6 transit providers are ->part of. See for ->documentation of the pTLA structure. The pTLA structure is modeled on the ->TLA structure and serves as a proving/testing ground for those structures. -> ->F3. the 6bone process for becoming a Pseudo-TLA (pTLA) is well defined and ->accepted by the 6bone community. See -> Section 7 for Guidelines ->for 6Bone pTLA sites. It has just been made Informational RFC 2546. -> ->F4. the 6bone community as a whole is willing to provide their knowledge, ->experience and opinions as part of a process to help "bootstrap" the ->Sub-TLA (sTLA) address allocation process for the RIRs. -> ->=== ->6bone Prequalification for Sub-TLAs -> ->S1. the sTLA requestor (sTR) places their Sub-TLA request with the ->appropriate RIR and declares that they intend to use the 6bone ->prequalification process (6PP). -> ->S2. the sTR (and the RIR?) notifies the 6bone list of their intent to use ->the 6PP. -> ->S3. the sTR follows the published process for becoming a pTLA (This will ->change by the end of the OSLO IETF meetings as the 6bone hardening process ->is approved by the NGtrans 6bone community). At the present time this ->process is documented by [RFC 2546] Section 7. This process currently ->requires 2-3 months minimum, based on this current practice, from the time ->of first joining the 6bone as a end-site network. -> ->S4. after the sTR has been approved as a pTLA, and operating as a pTLA for ->3 months with at least y customers (either lower level transits or ->end-sites) (recommend 3 customers), the pTR petitions the 6bone mailing ->list for support of its request for a Sub-TLA based on its performance as a ->pTLA, providing relevant proof or statement of how and/or why they believe ->they have met current 6bone backbone practices (currently as in RFC 2546). -> ->S5. a 6bone steering group (consisting of 3-5 persons established by 6bone ->participant consensus) prepares a short 6bone fitness report report (6FR) ->based on input received from 6bone participants (note this means members of ->pTLAs, pNLAs or end-sites organizations, not just mailing list subscribers) ->and factual information of compliance with established pTLA rules extant at ->the time (currently RFC 2546) and submits this report (the 6FR) to the ->appropriate regsitry (will need a well established contact point for the ->three IRRs). -> ->S6. if after the minimum time for the steps above, plus 1 (2?) month(s), ->the sTR may protest to the appropriate RIR of non-responsiveness and revert ->to another qualification process per RIR rules (unrelated to the 6PP). -> ->S7. after assignment of an sTLA to the sTR (by the RIR), the sTR may ->optionally renumber from the 6bone pTLA prefeix to the sTLA prefix, or ->continue use of their pTLA. If the pTLA space becomes over subscribed, the ->most likely networks to be asked to surrender their pTLA would be those ->holding production number space. -> ->=== ->Misc. Notes: -> ->N1. currently the RFC 2546 doc is being reworked under the 6bone hardening ->process now underway, which will almost certainly yield a stronger set of ->rules on what it takes to become a pTLA. -> ->N2. the current RFC 2546 doc does not specify a prequalification time as a ->pNLA or end-site 6bone site prior to requesting a pTLA, so it is ->recommended that a minimum of 2 months be specified (prior to the new rules ->being published after Oslo). -> ->N3. in S6. above, the total time from start of the 6PP until a protest ->could be made to the RIR, would be in the 6-8 months minimum (2-3 mos. ->while becoming a pTLA, 3 mos. while a pTLA, plus 1-2 mos.). -> ->N4. we need a way to handle existing pTLA sites that should not really have ->an sTLA as they are not production networks, rather they were created to ->"bootstrap" the 6bone or help a specific testing user community. This might ->include sites like INNER, TELEBIT, VIAGENIE, CISCO, NRL, UO, 3COM, MERIT, ->BT-LABS. Note that DIGITAL (now COMPAQ) is different in that they are ->acting as a real IPv6 exchange thus have not been included in the previous ->list. It is doubtful that these site would ask, but if they did it would be ->unlikely they could get a positive 6PP Report. So maybe the problem should ->be ignored and let the 6bone community police itself on this. -> ->N5. clearly this process will be none too quick between the time to get it ->firmed up and agreed to and the inherent time built into the process as ->described above. Thus it may get poor support if the revised RIR draft ->offers a reasonable alternative (of course that's why I noted this was a ->voluntary path for sTRs to take). On this we will have to see what the RIRs ->do in their next draft. -> ->N6. there may be a liability exposure of the IETF with this process, given ->the 6bone relationship to the IETF. This need not be covered here, but ->everyone should be aware of the issue. -> -> ->Things forgotten !!?? :-) Speak up! -> ->-end -> -> From Smirk35@aol.com Mon Apr 5 15:44:29 1999 From: Smirk35@aol.com (Smirk35@aol.com) Date: Mon, 5 Apr 1999 10:44:29 EDT Subject: 6bone Prequalification for Sub-TLA assignment Message-ID: <95bf4e0.243a264d@aol.com> Just an observer, Maybe giving the community a section of IPv6 as we do with (IPv4 10.x.x.x) so that the community will be able to use it as a test bed and then allow the pTLA submit a small addressing of IPv6 for access to 6bone like most of the world does with IPv4 Internet access with class-C's. Pricing the block of addresses would deter the small business wanting a very large block of IPv6. Low cost on small blocks and tracking the number of blocks by that company so as not to accumulate 100s of small blocks by the same company. Mark H. Bowen From perry@piermont.com Mon Apr 5 16:16:16 1999 From: perry@piermont.com (Perry E. Metzger) Date: 05 Apr 1999 11:16:16 -0400 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Bob Fink's message of "Sun, 04 Apr 1999 16:40:56 -0800" References: <4.1.19990330090417.009b2400@imap2.es.net> Message-ID: <871zhzp073.fsf@jekyll.piermont.com> Bob Fink writes: > If Sub-TLAs are given away too easily, they will be encouraging non-ipv6 > providers to get theirs now, i.e., the land rush model which could easily > fill up the TLA/Sub-TLA space with networks, sites, and organizations that > simply want to make sure they have a TLA/Sub-TLA, even if they don't need > one now or really qualify (i.e., they have no intent on putting up IPv6 > service and/or are simply not higher level transits). > > Alternatively, if Sub-TLAs are too hard to get, especially in the early > days of IPv6 deployment, it will discourage providers from putting up IPv6 > service, may give the impression that IPv6 doesn't help the address space > problem at all, thus greatly impeding the progress of IPv6 deployment and > transition, and even pose a legal risk to the registries. I think we should err on the side of liberalism. The whole advantage of IPv6 is that we don't break the IP end to end model by forcing people into NATs. If its too hard to get v6 address space, no one is going to have any incentive to move to v6. If you can get v6 space when you couldn't get v4 space, people will start wanting it. Perry From seirios@Matrix.IRI.Co.Jp Mon Apr 5 17:50:04 1999 From: seirios@Matrix.IRI.Co.Jp (HEO SeonMeyong) Date: Tue, 06 Apr 1999 01:50:04 +0900 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <871zhzp073.fsf@jekyll.piermont.com> References: <4.1.19990330090417.009b2400@imap2.es.net> <871zhzp073.fsf@jekyll.piermont.com> Message-ID: <19990406015004Z.seirios@Matrix.IRI.Co.Jp> Hi. This is HEO writeing > Bob Fink writes: > > If Sub-TLAs are given away too easily, they will be encouraging non-ipv6 > > providers to get theirs now, i.e., the land rush model which could easily > > fill up the TLA/Sub-TLA space with networks, sites, and organizations that > > simply want to make sure they have a TLA/Sub-TLA, even if they don't need > > one now or really qualify (i.e., they have no intent on putting up IPv6 > > service and/or are simply not higher level transits). > > > > Alternatively, if Sub-TLAs are too hard to get, especially in the early > > days of IPv6 deployment, it will discourage providers from putting up IPv6 > > service, may give the impression that IPv6 doesn't help the address space > > problem at all, thus greatly impeding the progress of IPv6 deployment and > > transition, and even pose a legal risk to the registries. > > I think we should err on the side of liberalism. The whole advantage > of IPv6 is that we don't break the IP end to end model by forcing > people into NATs. If its too hard to get v6 address space, no one is > going to have any incentive to move to v6. If you can get v6 space > when you couldn't get v4 space, people will start wanting it. I agree perry@piermont.com's opinion, too. The IPv6 is very happy because many of IPv6 users are assigned IP address, so the users need not use IP (header) rewriting software, such like NAT, NAPT, or IP masquerade. sTLA assignment rule assigns IPv6 assigner to limited sites. We are now wanted IPv6 assigner near our site, or if we can not get such site, one of our solution is "we become assigner". That rules are reject that solution. IPv6 Network become generalize, maybe that rule will work. But start of construct and use IPv6 network, many of the interested person or volunteer team can get sTLA and assign IPv6 address many users. We need IPv6 users first. And now we can get IPv6 protocol stack easily. So next step is many of users get IPv6 address easily. Sorry for my poor English. Thanks ---------- HEO SeonMeyong. Internet Research Institute, Inc. seirios@matrix.iri.co.jp From perry@piermont.com Mon Apr 5 21:44:11 1999 From: perry@piermont.com (Perry E. Metzger) Date: 05 Apr 1999 16:44:11 -0400 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Smirk35@aol.com's message of "Mon, 5 Apr 1999 10:44:29 EDT" References: <95bf4e0.243a264d@aol.com> Message-ID: <87lng6lrvo.fsf@jekyll.piermont.com> Smirk35@aol.com writes: > Just an observer, > > Maybe giving the community a section of IPv6 as we do with (IPv4 > 10.x.x.x) We already have a private addressing plan. That's not the point at hand... .pm From fink@es.net Mon Apr 5 22:56:48 1999 From: fink@es.net (Bob Fink) Date: Mon, 05 Apr 1999 14:56:48 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: References: <4.1.19990330090417.009b2400@imap2.es.net> Message-ID: <4.1.19990405144759.01f43a00@imap2.es.net> Rob, At 10:11 AM 4/5/99 -0400, Robert Rockell wrote: >->This will be open for discussion until 19 April '99, at which time the IAB, >->RIRs and IPv6 co-chairs will decide whether to move forward on an agreement >->about this or not, based on comments received. > >If the 6bone Hardening effort is not fully developed yet, maybe we can hold >off on the date to see if the efforts of this group prove to be fuitful, or >at least agreed upon, by all interested parties? However, this is not meant >to say that we should hold up the delegation of TLA's till after Oslo, >simply due to scheduling. > >I am afraid to move forward with the assumption that the hardening effort >will be written in stone, and used as an advisory to the registries, if it >has the chance of not being widely accepted withing the working groups, and >particualarly the 6bone. Although I believe we will eventually agree to some (a lot) of 6bone hardening, I don't think this prequalification method hinges on it, and we do have a current set of rules for becoming a pTLA. If the 6bone consensus is that a network is a qualified pTLA, they would probably get a fitness report to the affirmative. When the 6bone's pTLA rules eventually get tougher (and I hope they will), it will just be a little tougher to get a fitness report. I don't really want us to delay on this prequalification any longer than it takes to get an agreement in place. We do need to have Sub-TLAs assigned. Thanks, Bob From schoen@uclink4.Berkeley.EDU Tue Apr 6 00:22:18 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Mon, 5 Apr 1999 16:22:18 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <95bf4e0.243a264d@aol.com>; from Smirk35@aol.com on Mon, Apr 05, 1999 at 10:44:29AM -0400 References: <95bf4e0.243a264d@aol.com> Message-ID: <19990405162218.M30703@requiem.geecs.org> Smirk35@aol.com writes: > Just an observer, > > Maybe giving the community a section of IPv6 as we do with (IPv4 10.x.x.x) so > that the community will be able to use it as a test bed and then allow the > pTLA submit a small addressing of IPv6 for access to 6bone like most of the > world does with IPv4 Internet access with class-C's. > > Pricing the block of addresses would deter the small business wanting a very > large block of IPv6. Low cost on small blocks and tracking the number of > blocks by that company so as not to accumulate 100s of small blocks by the > same company. There's certainly nothing wrong with testing allocations, but there's already a working IPv6 testing allocation (3FFE); I haven't heard of any plans to take it back or to shut down the 6bone just because production allocations are coming up. Network 10 in IPv4 isn't really for "testing": it's intended for production use on private networks. (RFC 1657, RFC 1918) Private networks -- at least "permanent" or structurally private networks that cannot possibly be directly connected to the Internet -- are deprecated. In the old days of IPv4, there was no charge for IPv4 allocations. (Some people I know managed to get portable class C allocations when they were fourteen to sixteen years old, without particularly extensive justification about what they were going to do with them. That's how liberal the allocations were before the Internet became a household word.) There's no reason that people should be paying for IPv6 addresses themselves, since IPv6 was deliberately designed so as to make addresses non-scarce. Of course, registrants may well need to pay a filing fee to meet the administrative costs of the registries, but there is no reason that they should pay for the actual address delegations. Remember that these addresses are _addresses_, which exist in mathematical spaces and not in the physical world, and that the addressing and allocation schemes are being designed in advance by people to meet their requirements. If everything is done right, there should be no scarcity of addresses, and consequently no need to pay for them, and no market for them. -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From kazu@iijlab.net Tue Apr 6 04:53:50 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 06 Apr 1999 12:53:50 +0900 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <4.1.19990330090417.009b2400@imap2.es.net> References: <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990330090417.009b2400@imap2.es.net>,<4.1.19990330090417.009b2400@imap2.es.net>,<4.1.19990330090417.009b2400@imap2.es.net> Message-ID: <19990406125350E.kazu@iijlab.net> From: Bob Fink Subject: 6bone Prequalification for Sub-TLA assignment Date: Sun, 04 Apr 1999 16:40:56 -0800 > Note that the RIRs will soon reissue a draft incorporating other ideas and > comments from various sources, and will continue to have Sub-TLA > prequalification criteria independent of the ideas presented here. How soon will be the next draft reissued? Note that the promise deadline, within two weeks, has passed. --Kazu From schoen@uclink4.Berkeley.EDU Tue Apr 6 09:59:41 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Tue, 6 Apr 1999 01:59:41 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <4.1.19990405144759.01f43a00@imap2.es.net>; from Bob Fink on Mon, Apr 05, 1999 at 02:56:48PM -0700 References: <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990405144759.01f43a00@imap2.es.net> Message-ID: <19990406015941.E19610@requiem.geecs.org> Bob Fink writes: > I don't really want us to delay on this prequalification any longer than it > takes to get an agreement in place. We do need to have Sub-TLAs assigned. On another note, is there an already accepted set of standards for qualification other than this prequalification procedure? I.e. if someone wants to be a TLA or sub-TLA somewhat later on, is there a prospect of a clear way to do this other than via 6bone performance reports? It seems to me that, if all goes well, a flood of late adopters -- which is to say other-than-earliest-conceivable-adopters -- will appear sometime in the next year. Do they continue to go through the 6bone prequalification process in order to receive IPv6 allocations, or is there to be another way in? -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From brian@hursley.ibm.com Tue Apr 6 10:54:15 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 06 Apr 1999 10:54:15 +0100 Subject: 6bone Prequalification for Sub-TLA assignment References: <95bf4e0.243a264d@aol.com> <19990405162218.M30703@requiem.geecs.org> Message-ID: <3709D9C7.5851D735@hursley.ibm.com> This isn't the IETF, so we don't have a blanket rule against talking about pricing, but I still wouldn't recommend it; such discussions never converge. Brian Seth David Schoen wrote: > > Smirk35@aol.com writes: > > > Just an observer, > > > > Maybe giving the community a section of IPv6 as we do with (IPv4 10.x.x.x) so > > that the community will be able to use it as a test bed and then allow the > > pTLA submit a small addressing of IPv6 for access to 6bone like most of the > > world does with IPv4 Internet access with class-C's. > > > > Pricing the block of addresses would deter the small business wanting a very > > large block of IPv6. Low cost on small blocks and tracking the number of > > blocks by that company so as not to accumulate 100s of small blocks by the > > same company. > > There's certainly nothing wrong with testing allocations, but there's already > a working IPv6 testing allocation (3FFE); I haven't heard of any plans to > take it back or to shut down the 6bone just because production allocations > are coming up. > > Network 10 in IPv4 isn't really for "testing": it's intended for production > use on private networks. (RFC 1657, RFC 1918) Private networks -- at least > "permanent" or structurally private networks that cannot possibly be directly > connected to the Internet -- are deprecated. > > In the old days of IPv4, there was no charge for IPv4 allocations. (Some > people I know managed to get portable class C allocations when they were > fourteen to sixteen years old, without particularly extensive justification > about what they were going to do with them. That's how liberal the > allocations were before the Internet became a household word.) > > There's no reason that people should be paying for IPv6 addresses themselves, > since IPv6 was deliberately designed so as to make addresses non-scarce. > Of course, registrants may well need to pay a filing fee to meet the > administrative costs of the registries, but there is no reason that they > should pay for the actual address delegations. > > Remember that these addresses are _addresses_, which exist in mathematical > spaces and not in the physical world, and that the addressing and allocation > schemes are being designed in advance by people to meet their requirements. > If everything is done right, there should be no scarcity of addresses, and > consequently no need to pay for them, and no market for them. > > -- > Seth David Schoen / schoen@uclink4.berkeley.edu > He said, "This is what the king who will reign over you will do." And they > said, "Nay, but we will have a king over us, that we also may be like all the > nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From brian@hursley.ibm.com Tue Apr 6 10:56:04 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 06 Apr 1999 10:56:04 +0100 Subject: 6bone Prequalification for Sub-TLA assignment References: <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990405144759.01f43a00@imap2.es.net> Message-ID: <3709DA34.2856E14F@hursley.ibm.com> The 6bone would not be the *only* way of getting a sTLA; but we certainly shouldn't make the 6bone's internal debate a roadblock for sTLA assignments; this is late already! Brian Bob Fink wrote: > > Rob, > > At 10:11 AM 4/5/99 -0400, Robert Rockell wrote: > >->This will be open for discussion until 19 April '99, at which time the IAB, > >->RIRs and IPv6 co-chairs will decide whether to move forward on an agreement > >->about this or not, based on comments received. > > > >If the 6bone Hardening effort is not fully developed yet, maybe we can hold > >off on the date to see if the efforts of this group prove to be fuitful, or > >at least agreed upon, by all interested parties? However, this is not meant > >to say that we should hold up the delegation of TLA's till after Oslo, > >simply due to scheduling. > > > >I am afraid to move forward with the assumption that the hardening effort > >will be written in stone, and used as an advisory to the registries, if it > >has the chance of not being widely accepted withing the working groups, and > >particualarly the 6bone. > > Although I believe we will eventually agree to some (a lot) of 6bone > hardening, I don't think this prequalification method hinges on it, and we > do have a current set of rules for becoming a pTLA. If the 6bone consensus > is that a network is a qualified pTLA, they would probably get a fitness > report to the affirmative. When the 6bone's pTLA rules eventually get > tougher (and I hope they will), it will just be a little tougher to get a > fitness report. > > I don't really want us to delay on this prequalification any longer than it > takes to get an agreement in place. We do need to have Sub-TLAs assigned. > > Thanks, > > Bob From brian@hursley.ibm.com Tue Apr 6 11:27:53 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Tue, 06 Apr 1999 11:27:53 +0100 Subject: 6bone Prequalification for Sub-TLA assignment References: <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990405144759.01f43a00@imap2.es.net> <19990406015941.E19610@requiem.geecs.org> Message-ID: <3709E1A9.BA1D99A7@hursley.ibm.com> Yes. The proposal to prequalify via 6bone is an addition to the criteria originally suggested by the registries. Brian Seth David Schoen wrote: > > Bob Fink writes: > > > I don't really want us to delay on this prequalification any longer than it > > takes to get an agreement in place. We do need to have Sub-TLAs assigned. > > On another note, is there an already accepted set of standards for > qualification other than this prequalification procedure? I.e. if someone > wants to be a TLA or sub-TLA somewhat later on, is there a prospect of a clear > way to do this other than via 6bone performance reports? > > It seems to me that, if all goes well, a flood of late adopters -- which is > to say other-than-earliest-conceivable-adopters -- will appear sometime in > the next year. Do they continue to go through the 6bone prequalification > process in order to receive IPv6 allocations, or is there to be another way > in? > > -- > Seth David Schoen / schoen@uclink4.berkeley.edu > He said, "This is what the king who will reign over you will do." And they > said, "Nay, but we will have a king over us, that we also may be like all the > nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From fink@es.net Tue Apr 6 13:49:48 1999 From: fink@es.net (Bob Fink) Date: Tue, 06 Apr 1999 05:49:48 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <19990406015941.E19610@requiem.geecs.org> References: <4.1.19990405144759.01f43a00@imap2.es.net> <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990405144759.01f43a00@imap2.es.net> Message-ID: <4.1.19990406054612.0098e1b0@imap2.es.net> Seth David, At 01:59 AM 4/6/99 -0700, Seth David Schoen wrote: >Bob Fink writes: > >> I don't really want us to delay on this prequalification any longer than it >> takes to get an agreement in place. We do need to have Sub-TLAs assigned. > >On another note, is there an already accepted set of standards for >qualification other than this prequalification procedure? I.e. if someone >wants to be a TLA or sub-TLA somewhat later on, is there a prospect of a clear >way to do this other than via 6bone performance reports? There is the registry draft we have already seen (that promped this 6bone prequal process) that will be revved in the next week. Watch this list :-) >It seems to me that, if all goes well, a flood of late adopters -- which is >to say other-than-earliest-conceivable-adopters -- will appear sometime in >the next year. Do they continue to go through the 6bone prequalification >process in order to receive IPv6 allocations, or is there to be another way >in? They could choose between the 6bone prequal or the RIR's own policy, at least as long as the RIRs want to leave the 6bone prequal in place. Currently is it estimated this would be in the 6-24 month range if it works well. Bob From bound@zk3.dec.com Tue Apr 6 17:32:30 1999 From: bound@zk3.dec.com (Jim Bound) Date: Tue, 06 Apr 1999 12:32:30 -0400 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Your message of "Sun, 04 Apr 1999 16:40:56 -0800." <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990330090417.009b2400@imap2.es.net> <4.1.19990330090417.009b2400@imap2.es.net> Message-ID: <199904061632.MAA0000003289@quarry.zk3.dec.com> Bob, I think this plan will work but some issues I see which I think you recorded. 1. Don't we need a 6PP doc? 2. 6Bone Hardening Defined? 3. Do we do this on the mail list? 4. What happens to existing pTLAs that don't qualify? But we need to do something quick and I have not heard a better plan. And if the IRs are open to this we should move forward is my input. I don't think the IETF (the entity) is associated with the 6bone in a manner that would cause one to have concern, and we should clear that up if folks do think this. The people working on the 6bone also participate in the IETF, and the work is presented at IETF meetings but the IETF does not bless or veto stuff we do on the 6bone? Or am I missing something more subtle? The 6bone is I think a good prequalifier for those who want to participate and in fact do real work with IPv6. Its not the only qualifier that should be used but a good one for the IRs to test applicants. Then applicants can use the 6bone to ramp up. What I really like about using the 6bone I don't think was mentioned. It means folks have to use the IPv6 address in some way and they can't say they can't because the 6bone is running. This way folks won't hoard them up like they did NSAP space and never use them. But ovverall I think this is a good idea in my input. What was the end result of /29 vs /35? thanks /jim From schoen@uclink4.Berkeley.EDU Wed Apr 7 02:33:34 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Tue, 6 Apr 1999 18:33:34 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <199904061632.MAA0000003289@quarry.zk3.dec.com>; from Jim Bound on Tue, Apr 06, 1999 at 12:32:30PM -0400 References: <4.1.19990330090417.009b2400@imap2.es.net> <199904061632.MAA0000003289@quarry.zk3.dec.com> Message-ID: <19990406183334.E9126@requiem.geecs.org> Jim Bound writes: > I don't think the IETF (the entity) is associated with the 6bone in a > manner that would cause one to have concern, and we should clear that up > if folks do think this. The people working on the 6bone also > participate in the IETF, and the work is presented at IETF meetings but > the IETF does not bless or veto stuff we do on the 6bone? Or am I missing > something more subtle? The 6bone is an IETF activity: http://www.6bone.net/ The 6bone is an IPv6 testbed to assist in the evolution and deployment of IPv6, often referred to as IPng ..., in the Internet. The 6bone activity is part of the ngtrans effort under the IETF. http://www.6bone.net/ngtrans/ The IPng Transition (ngtrans) working group of the IETF is under the Operations and Management Area, and has as its overall goal assisting in and promoting the transition to IPv6, the next generation Internet protocol chosen by the IETF community. Current ngtrans efforts are divided into two separate activities: tools and the 6bone. -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From bound@zk3.dec.com Wed Apr 7 17:26:33 1999 From: bound@zk3.dec.com (Jim Bound) Date: Wed, 07 Apr 1999 12:26:33 -0400 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Your message of "Tue, 06 Apr 1999 18:33:34 PDT." <19990406183334.E9126@requiem.geecs.org> Message-ID: <199904071626.MAA0000016111@quarry.zk3.dec.com> Seth, >> I don't think the IETF (the entity) is associated with the 6bone in a >> manner that would cause one to have concern, and we should clear that up >> if folks do think this. The people working on the 6bone also >> participate in the IETF, and the work is presented at IETF meetings but >> the IETF does not bless or veto stuff we do on the 6bone? Or am I missing >> something more subtle? > >The 6bone is an IETF activity: > >http://www.6bone.net/ > > The 6bone is an IPv6 testbed to assist in the evolution and deployment > of IPv6, often referred to as IPng ..., in the Internet. The 6bone > activity is part of the ngtrans effort under the IETF. Well this is written wrong IMO and should say in the last sentence. The 6bone activity is an effort by implementors to assist with verifying the work on IPv6 within the IETF. State and evolution of this activity is discussed and reported on at the IETF ngtrans WG. For example if we want to expand the 6bone to connect to StarWars Network on Planet Mars we don't have to go get approval from the IETF or the IESG. As their job is to work on protocols and operational characteristics of those protocols. It is the 6bone participants that make the decisions and direction of the 6bone not the IETF. So the above sentence is wrong IMO. http://www.6bone.net/ngtrans/ The IPng Transition (ngtrans) working group of the IETF is under the Operations and Management Area, and has as its overall goal assisting in and promoting the transition to IPv6, the next generation Internet protocol chosen by the IETF community. Current ngtrans efforts are divided into two separate activities: tools and the 6bone. This is clearly wrong because the IESG or IAB got nothing to say about how we operate and promote the 6bone. Thanks for catching this error. So how do we fix this? I suggest we update the wording at both places. thanks /jim From schoen@uclink4.Berkeley.EDU Wed Apr 7 21:03:07 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Wed, 7 Apr 1999 13:03:07 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <199904071626.MAA0000016111@quarry.zk3.dec.com>; from Jim Bound on Wed, Apr 07, 1999 at 12:26:33PM -0400 References: <19990406183334.E9126@requiem.geecs.org> <199904071626.MAA0000016111@quarry.zk3.dec.com> Message-ID: <19990407130307.B30420@requiem.geecs.org> Jim Bound writes: > >> I don't think the IETF (the entity) is associated with the 6bone in a > >> manner that would cause one to have concern, and we should clear that up > >> if folks do think this. The people working on the 6bone also > >> participate in the IETF, and the work is presented at IETF meetings but > >> the IETF does not bless or veto stuff we do on the 6bone? Or am I missing > >> something more subtle? > > > >The 6bone is an IETF activity: > > > >http://www.6bone.net/ > > > > The 6bone is an IPv6 testbed to assist in the evolution and deployment > > of IPv6, often referred to as IPng ..., in the Internet. The 6bone > > activity is part of the ngtrans effort under the IETF. > > Well this is written wrong IMO and should say in the last sentence. > > The 6bone activity is an effort by implementors to assist with verifying > the work on IPv6 within the IETF. State and evolution of this activity > is discussed and reported on at the IETF ngtrans WG. > > For example if we want to expand the 6bone to connect to StarWars > Network on Planet Mars we don't have to go get approval from the IETF or > the IESG. As their job is to work on protocols and operational > characteristics of those protocols. It is the 6bone participants that > make the decisions and direction of the 6bone not the IETF. > > So the above sentence is wrong IMO. > > http://www.6bone.net/ngtrans/ > > The IPng Transition (ngtrans) working group of the IETF is under the > Operations and Management Area, and has as its overall goal assisting > in and promoting the transition to IPv6, the next generation Internet > protocol chosen by the IETF community. > > Current ngtrans efforts are divided into two separate activities: > tools and the 6bone. > > This is clearly wrong because the IESG or IAB got nothing to say about > how we operate and promote the 6bone. > > Thanks for catching this error. > > So how do we fix this? > > I suggest we update the wording at both places. I think Bob Fink wrote most, if not all, of those pages, so I'll wait for what he has to say about how to interpret them. I don't think that "being an IETF activity" means that the IETF necessarily micromanages or even sets policy for something; as I understand it, it just means that the IETF endorses something and believes that it serves an IETF function. But I've never read an official definition of "IETF activity". I didn't mean to suggest that the IETF would "bless or veto" particular 6bone decisions, just that there does exist an association between them. -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From nathan@montana.com Thu Apr 8 04:47:19 1999 From: nathan@montana.com (Nathan Lane) Date: Wed, 07 Apr 1999 22:47:19 -0500 Subject: 6bone Prequalification for Sub-TLA assignment References: <4.1.19990330090417.009b2400@imap2.es.net> <871zhzp073.fsf@jekyll.piermont.com> Message-ID: <370C26C7.AC22CB60@terminus.com> A perspective from a Fortune 5 company with a large IP deployment: I'm currently in the throes of whether or not to obtain a huge allocation of ipv4 addresses at great cost (I already have 28 /16s [enough left for about a year given no surprises] and a usage of about a million or two 1918 private addresses) for a project that will take years to implement. If I can go in and say "we go ipv6, with a no/low cost address allocation big enough for our now and future needs" I'll get support for that when faced with a $2.5mil ARIN bill. NATing 3600 sites for bidirectional connectivity to outside sources is obviously a virtually impossible task - it's almost easier to throw in v6 with policy routing and tunnels at endpoints once you start thinking about the magnitude. So, I'm in a bind and not in the namespace sense. I would encourage liberalism as well to encourage deployment. It will strongly encourage v6 deployment in my network and my enterprise is large enough to force vendor compliance. We all need to keep in mind the business side. My IP renumbering project, into 1918 addresses, has been a two year "hold it, you know what you're getting us into? NATmare." But the protocol value alone of v6 will not convince me to go to it. Economics will. Availability of released code also will help and certain vendors are not exactly forthcoming nor helpful. -Nathan Lane Senior Network Engineer Wal-Mart Stores, Inc. "Perry E. Metzger" wrote: > Bob Fink writes: > > If Sub-TLAs are given away too easily, they will be encouraging non-ipv6 > > providers to get theirs now, i.e., the land rush model which could easily > > fill up the TLA/Sub-TLA space with networks, sites, and organizations that > > simply want to make sure they have a TLA/Sub-TLA, even if they don't need > > one now or really qualify (i.e., they have no intent on putting up IPv6 > > service and/or are simply not higher level transits). > > > > Alternatively, if Sub-TLAs are too hard to get, especially in the early > > days of IPv6 deployment, it will discourage providers from putting up IPv6 > > service, may give the impression that IPv6 doesn't help the address space > > problem at all, thus greatly impeding the progress of IPv6 deployment and > > transition, and even pose a legal risk to the registries. > > I think we should err on the side of liberalism. The whole advantage > of IPv6 is that we don't break the IP end to end model by forcing > people into NATs. If its too hard to get v6 address space, no one is > going to have any incentive to move to v6. If you can get v6 space > when you couldn't get v4 space, people will start wanting it. > > Perry From bound@zk3.dec.com Thu Apr 8 06:27:36 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 08 Apr 1999 01:27:36 -0400 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Your message of "Wed, 07 Apr 1999 22:47:19 CDT." <370C26C7.AC22CB60@terminus.com> Message-ID: <199904080527.BAA0000000864@quarry.zk3.dec.com> Nathan, Well said and we need to get vendors to commit to what and when they are shipping "publicly". Most of us have early adopter kits. I first would suggest discussing making those kits production enabled until they hit base products. To get that done requires a request from a customer using IPv6. It would be hard but not impossible. One important issue is what applications from the Host platform must have been ported for the first release? The list we have now is: Net Utilities (ping, finger, ifconfig....etc) FTP, TELNET WWW Server and Browser Sendmail and SMTP GATED and ROUTED Routing DAEMONS 6over4 NFS ???? Will this do it initially? If not what else do you need? Compaq Tru64 UNIX will provide in the upcoming 5.0 release the IPv6 Sockets API to begin porting to IPv6 this should be on the streets summer 1999. Our kit will continue at some level. The next release which will be early 2000 will have the above is the strategy. But what else do you need in that release? But again if the vendors are willing to harden their early adopter kits for production they first need to hear that someone wants them NOW. It is possible given enough requests to begin discussions. Also note the above assumes all are compliant to the core specs and a few others I think will be needed like DHCPv6, until stateless can really be managed which it will not initially. Also transition is affected by the fact if the new IPv6 nodes deployed need to talk out on the Internet (not Intranet) to IPv4 nodes? Also do you want to give subscribers IPv6 addresses? I also suggest you forward this and an actual request to users@ipv6.org with an initial RFI to see what comes back to you. thanks /jim From bound@zk3.dec.com Thu Apr 8 06:43:57 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 08 Apr 1999 01:43:57 -0400 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Your message of "Wed, 07 Apr 1999 13:03:07 PDT." <19990407130307.B30420@requiem.geecs.org> Message-ID: <199904080543.BAA0000003537@quarry.zk3.dec.com> >I think Bob Fink wrote most, if not all, of those pages, so I'll wait for what >he has to say about how to interpret them. I agree. >I don't think that "being an IETF activity" means that the IETF necessarily >micromanages or even sets policy for something; as I understand it, it just >means that the IETF endorses something and believes that it serves an IETF >function. But I've never read an official definition of "IETF activity". This is my concern. What does it mean? >I didn't mean to suggest that the IETF would "bless or veto" particular >6bone decisions, just that there does exist an association between them. I agree there is an association. What I am doing of late is to clearly differentiate IETF space from vendor and others space to get Ipv6 deployed. The decision on when to ship real IPv6 products, market them, move them, and proactively push them in the market is not an IETF effort but an industry and market effort. Because "transition" kind of overlaps btw the IETF and the act stated above is why this has come up at all. If the market is ready before we can complete what we are working very hard on for transition in the IETF (and I include myself in that hard work in the IETF) as an industry and as vendors we have a delimma. I think this has already happened. We stand at a crossroad as vendors (at least some of us) with ready customers who want IPv6 for several reasons but will need some transition mechanisms potentially in 1999. That is why I think the "differentiation" is needed for IPv6 deployment and why the IPv6 Deployment/Users List and IPv6 Forum is moving forward now in part. To assist users with this delimma and provide a forum to influence the market and vendors to hasten what is happening here with IPv6. /jim From jabley@clear.co.nz Thu Apr 8 07:15:42 1999 From: jabley@clear.co.nz (Joe Abley) Date: Thu, 8 Apr 1999 18:15:42 +1200 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <370C26C7.AC22CB60@terminus.com>; from Nathan Lane on Wed, Apr 07, 1999 at 10:47:19PM -0500 References: <4.1.19990330090417.009b2400@imap2.es.net> <871zhzp073.fsf@jekyll.piermont.com> <370C26C7.AC22CB60@terminus.com> Message-ID: <19990408181542.A38393@clear.co.nz> On Wed, Apr 07, 1999 at 10:47:19PM -0500, Nathan Lane wrote: > A perspective from a Fortune 5 company with a large IP deployment: > > I'm currently in the throes of whether or not to obtain a huge allocation of > ipv4 addresses at great cost (I already have 28 /16s [enough left for about a > year given no surprises] and a usage of about a million or two 1918 private > addresses) for a project that will take years to implement. If I can go in and > say "we go ipv6, with a no/low cost address allocation big enough for our now > and future needs" I'll get support for that when faced with a $2.5mil ARIN > bill. Eh? APNIC will give me as many addresses as I can justify at no cost, as long as I am a member. Membership costs US$2000 per year. Is ARIN so different? Joe From schoen@uclink4.Berkeley.EDU Thu Apr 8 10:24:01 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Thu, 8 Apr 1999 02:24:01 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <19990408181542.A38393@clear.co.nz>; from Joe Abley on Thu, Apr 08, 1999 at 06:15:42PM +1200 References: <4.1.19990330090417.009b2400@imap2.es.net> <871zhzp073.fsf@jekyll.piermont.com> <370C26C7.AC22CB60@terminus.com> <19990408181542.A38393@clear.co.nz> Message-ID: <19990408022401.I2983@requiem.geecs.org> Joe Abley writes: > On Wed, Apr 07, 1999 at 10:47:19PM -0500, Nathan Lane wrote: > > A perspective from a Fortune 5 company with a large IP deployment: > > > > I'm currently in the throes of whether or not to obtain a huge allocation of > > ipv4 addresses at great cost (I already have 28 /16s [enough left for about a > > year given no surprises] and a usage of about a million or two 1918 private > > addresses) for a project that will take years to implement. If I can go in and > > say "we go ipv6, with a no/low cost address allocation big enough for our now > > and future needs" I'll get support for that when faced with a $2.5mil ARIN > > bill. > > Eh? > > APNIC will give me as many addresses as I can justify at no cost, as long > as I am a member. Membership costs US$2000 per year. > > Is ARIN so different? Yes: http://www.arin.net/feeschedule.html -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From jabley@clear.co.nz Thu Apr 8 21:09:15 1999 From: jabley@clear.co.nz (Joe Abley) Date: Fri, 9 Apr 1999 08:09:15 +1200 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <19990408022401.I2983@requiem.geecs.org>; from Seth David Schoen on Thu, Apr 08, 1999 at 02:24:01AM -0700 References: <4.1.19990330090417.009b2400@imap2.es.net> <871zhzp073.fsf@jekyll.piermont.com> <370C26C7.AC22CB60@terminus.com> <19990408181542.A38393@clear.co.nz> <19990408022401.I2983@requiem.geecs.org> Message-ID: <19990409080915.A48071@clear.co.nz> On Thu, Apr 08, 1999 at 02:24:01AM -0700, Seth David Schoen wrote: > Joe Abley writes: > > > On Wed, Apr 07, 1999 at 10:47:19PM -0500, Nathan Lane wrote: > > > A perspective from a Fortune 5 company with a large IP deployment: > > > > > > I'm currently in the throes of whether or not to obtain a huge allocation of > > > ipv4 addresses at great cost (I already have 28 /16s [enough left for about a > > > year given no surprises] and a usage of about a million or two 1918 private > > > addresses) for a project that will take years to implement. If I can go in and > > > say "we go ipv6, with a no/low cost address allocation big enough for our now > > > and future needs" I'll get support for that when faced with a $2.5mil ARIN > > > bill. > > > > Eh? > > > > APNIC will give me as many addresses as I can justify at no cost, as long > > as I am a member. Membership costs US$2000 per year. > > > > Is ARIN so different? > > Yes: > > http://www.arin.net/feeschedule.html Does anybody pay this? For this money, it is far more cost effective to buy an IPLC to an Asian country so you can legitimately obtain addresses from APNIC as an Asian operator :/ Incidentally, the APNIC member schedules (small, medium, large) are related to the number of votes you get as an APNIC member, and are nothing really to do with the size (or rate of address consumption) of your organisation. If you're happy having only a single vote for the annual APNIC meetings, then there is nothing wrong with joining as a "small" organisation (which costs US$2000 per year, from memory). Joe -- Joe Abley Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Communications Ltd http://www.clear.net.nz/ From schoen@uclink4.Berkeley.EDU Fri Apr 9 01:03:42 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Thu, 8 Apr 1999 17:03:42 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <19990409080915.A48071@clear.co.nz>; from Joe Abley on Fri, Apr 09, 1999 at 08:09:15AM +1200 References: <4.1.19990330090417.009b2400@imap2.es.net> <871zhzp073.fsf@jekyll.piermont.com> <370C26C7.AC22CB60@terminus.com> <19990408181542.A38393@clear.co.nz> <19990408022401.I2983@requiem.geecs.org> <19990409080915.A48071@clear.co.nz> Message-ID: <19990408170342.I24034@requiem.geecs.org> Joe Abley writes: > > > Is ARIN so different? > > > > Yes: > > > > http://www.arin.net/feeschedule.html > > Does anybody pay this? Well, you can take a look at the number of entries at whois.arin.net to give some idea. On the other hand, it's not clear to me whether ARIN is actually assessing fees under this schedule on people who registered for address space pre-ARIN (i.e. with InterNIC). I know people who have old delegations still listed at whois.arin.net but have never received a bill from ARIN. -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From fink@es.net Fri Apr 9 02:48:43 1999 From: fink@es.net (Bob Fink) Date: Thu, 08 Apr 1999 18:48:43 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <199904071626.MAA0000016111@quarry.zk3.dec.com> References: Message-ID: <4.1.19990408184444.009f0910@imap2.es.net> Jim, Regarding your comments on the 6bone and its relationship to the IETF, I believe you are closer to right than wrong! I'll put together some slightly better words to say what I think the situation is and let the list know. Thanks for commenting on it. Bob PS: Thanks to Seth as well as it helps to have someone throw words back at you to make one think about what they mean :-) === At 12:26 PM 4/7/99 -0400, Jim Bound wrote: >Seth, > >>> I don't think the IETF (the entity) is associated with the 6bone in a >>> manner that would cause one to have concern, and we should clear that up >>> if folks do think this. The people working on the 6bone also >>> participate in the IETF, and the work is presented at IETF meetings but >>> the IETF does not bless or veto stuff we do on the 6bone? Or am I missing >>> something more subtle? >> >>The 6bone is an IETF activity: >> >>http://www.6bone.net/ >> >> The 6bone is an IPv6 testbed to assist in the evolution and deployment >> of IPv6, often referred to as IPng ..., in the Internet. The 6bone >> activity is part of the ngtrans effort under the IETF. > >Well this is written wrong IMO and should say in the last sentence. > >The 6bone activity is an effort by implementors to assist with verifying >the work on IPv6 within the IETF. State and evolution of this activity >is discussed and reported on at the IETF ngtrans WG. > >For example if we want to expand the 6bone to connect to StarWars >Network on Planet Mars we don't have to go get approval from the IETF or >the IESG. As their job is to work on protocols and operational >characteristics of those protocols. It is the 6bone participants that >make the decisions and direction of the 6bone not the IETF. > >So the above sentence is wrong IMO. > >http://www.6bone.net/ngtrans/ > > The IPng Transition (ngtrans) working group of the IETF is under the > Operations and Management Area, and has as its overall goal assisting > in and promoting the transition to IPv6, the next generation Internet > protocol chosen by the IETF community. > > Current ngtrans efforts are divided into two separate activities: > tools and the 6bone. > >This is clearly wrong because the IESG or IAB got nothing to say about >how we operate and promote the 6bone. > >Thanks for catching this error. > >So how do we fix this? > >I suggest we update the wording at both places. > >thanks >/jim From fink@es.net Fri Apr 9 02:48:43 1999 From: fink@es.net (Bob Fink) Date: Thu, 08 Apr 1999 18:48:43 -0700 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <199904071626.MAA0000016111@quarry.zk3.dec.com> References: Message-ID: <4.1.19990408184444.009f0910@imap2.es.net> Jim, Regarding your comments on the 6bone and its relationship to the IETF, I believe you are closer to right than wrong! I'll put together some slightly better words to say what I think the situation is and let the list know. Thanks for commenting on it. Bob PS: Thanks to Seth as well as it helps to have someone throw words back at you to make one think about what they mean :-) === At 12:26 PM 4/7/99 -0400, Jim Bound wrote: >Seth, > >>> I don't think the IETF (the entity) is associated with the 6bone in a >>> manner that would cause one to have concern, and we should clear that up >>> if folks do think this. The people working on the 6bone also >>> participate in the IETF, and the work is presented at IETF meetings but >>> the IETF does not bless or veto stuff we do on the 6bone? Or am I missing >>> something more subtle? >> >>The 6bone is an IETF activity: >> >>http://www.6bone.net/ >> >> The 6bone is an IPv6 testbed to assist in the evolution and deployment >> of IPv6, often referred to as IPng ..., in the Internet. The 6bone >> activity is part of the ngtrans effort under the IETF. > >Well this is written wrong IMO and should say in the last sentence. > >The 6bone activity is an effort by implementors to assist with verifying >the work on IPv6 within the IETF. State and evolution of this activity >is discussed and reported on at the IETF ngtrans WG. > >For example if we want to expand the 6bone to connect to StarWars >Network on Planet Mars we don't have to go get approval from the IETF or >the IESG. As their job is to work on protocols and operational >characteristics of those protocols. It is the 6bone participants that >make the decisions and direction of the 6bone not the IETF. > >So the above sentence is wrong IMO. > >http://www.6bone.net/ngtrans/ > > The IPng Transition (ngtrans) working group of the IETF is under the > Operations and Management Area, and has as its overall goal assisting > in and promoting the transition to IPv6, the next generation Internet > protocol chosen by the IETF community. > > Current ngtrans efforts are divided into two separate activities: > tools and the 6bone. > >This is clearly wrong because the IESG or IAB got nothing to say about >how we operate and promote the 6bone. > >Thanks for catching this error. > >So how do we fix this? > >I suggest we update the wording at both places. > >thanks >/jim From Francis.Dupont@inria.fr Sat Apr 10 16:47:54 1999 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Sat, 10 Apr 1999 17:47:54 +0200 Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: Your message of Thu, 08 Apr 1999 02:24:01 PDT. <19990408022401.I2983@requiem.geecs.org> Message-ID: <199904101547.RAA21071@givry.inria.fr> In your previous mail you wrote: > Is ARIN so different? http://www.arin.net/feeschedule.html => my concern with this topic is the xxx-TLA assignment can be interpreted as an attack against the regional NIC business... Obviously IPv4 addresses are not for free and the fee schedule of IPv4 cannot be translated easily to IPv6. I'd like to say the problem is with assignment/allocation procedures, ie a technical issue, but this doesn't explain why it is still impossible today to get an *official* IPv6 address... I can see a clear danger here! Francis.Dupont@inria.fr PS: I expect we'll get the new proposal before the next RIPE meeting in Vienna in order to have a technical discussion about it... From sgunderson@bigfoot.com Wed Apr 7 21:30:19 1999 From: sgunderson@bigfoot.com (Steinar H. Gunderson) Date: Wed, 7 Apr 1999 22:30:19 +0200 Subject: 6bone Prequalification for Sub-TLA assignment (really about addresses) In-Reply-To: <19990405162218.M30703@requiem.geecs.org>; from Seth David Schoen on Mon, Apr 05, 1999 at 04:22:18PM -0700 References: <95bf4e0.243a264d@aol.com> <19990405162218.M30703@requiem.geecs.org> Message-ID: <19990407223019.A7393@uio.no> On Mon, Apr 05, 1999 at 04:22:18PM -0700, Seth David Schoen wrote: >In the old days of IPv4, there was no charge for IPv4 allocations. (Some >people I know managed to get portable class C allocations when they were >fourteen to sixteen years old, without particularly extensive justification >about what they were going to do with them. That's how liberal the >allocations were before the Internet became a household word.) Unfortunately, this is how things have become now. If IPv4 address delegations had been planned a little better, I (stupid as I may be) think there would have been no problems at all. Seriously, IPv4 allows for up to 4294967296 (256 ** 4) addresses, and if they hadn't been giving them out in chunks of 256, I (being 15 years old, soon 16) wouldn't have needed all the trouble that IP masquerading gives. (There are still some, but at least things work out OK, thanks to Linux.) Therefore I welcome IPv6. The problem (for me) so far with 6bone seems to get connected for the everyday user. I've got an internal IPv6 network up and running, but nobody seems to want to give me a tunnel to the 6bone, especially as I'm connected with my 28.800 modem and have to use dynamic IP. The answer I get is generally `educational institutions only'. Could anybody help? (I live in Norway.) Sorry for being a bit off-topic here, but I still feel this is part of the discussion ;-) >If everything is done right, there should be no scarcity of addresses, and >consequently no need to pay for them, and no market for them. As in the case of IPv4. (Though I've heard something about fragmented router tables being a problem... Is this why they only give out in 256 and 256?) /* Steinar */ From schoen@uclink4.Berkeley.EDU Sat Apr 10 20:15:02 1999 From: schoen@uclink4.Berkeley.EDU (Seth David Schoen) Date: Sat, 10 Apr 1999 12:15:02 -0700 Subject: History and economics of fees? (was: Re: 6bone Prequalification...) In-Reply-To: <199904101547.RAA21071@givry.inria.fr>; from Francis Dupont on Sat, Apr 10, 1999 at 05:47:54PM +0200 References: <19990408022401.I2983@requiem.geecs.org> <199904101547.RAA21071@givry.inria.fr> Message-ID: <19990410121502.A6329@requiem.geecs.org> Francis Dupont writes: > In your previous mail you wrote: > > > Is ARIN so different? > > http://www.arin.net/feeschedule.html > > => my concern with this topic is the xxx-TLA assignment can be > interpreted as an attack against the regional NIC business... > Obviously IPv4 addresses are not for free and the fee schedule > of IPv4 cannot be translated easily to IPv6. How did the regional NICs appear the first time around? I remember when they showed up, but I wasn't really following Internet architecture matters yet. Brian Carpenter is right that these delegation and pricing issues aren't going to be solved suddenly on this list, but I'm curious about that part of the historical context. At some time before the regional NICs, IPv4 addresses _were_ "free"; the explanation I'm familiar with is that the InterNIC's registration services were being subsized by the US government. While I certainly don't want to see a return to such a subsidy, I'm also very curious about the economics of the process; the fees have been said to exist in order to cover registries' costs (which makes sense) and also in order to conserve scarce IPv4 address space (which also makes sense). But now IPv6 addresses are not scarce, at least not in the same sense that IPv4 addresses are. Shouldn't this, as I've heard suggested, cause the scarcity portion of the fees (if registration fees can actually be broken down this way) to evaporate? Is this off-topic for this list? If so, is it on-topic somewhere else? -- Seth David Schoen / schoen@uclink4.berkeley.edu He said, "This is what the king who will reign over you will do." And they said, "Nay, but we will have a king over us, that we also may be like all the nations." (1 Sam 8) http://ishmael.geecs.org/~sigma/ http://www.loyalty.org/ From fink@es.net Sun Apr 11 00:26:31 1999 From: fink@es.net (Bob Fink) Date: Sat, 10 Apr 1999 16:26:31 -0700 Subject: History and economics of fees? (was: Re: 6bone Prequalification...) In-Reply-To: <19990410121502.A6329@requiem.geecs.org> References: <199904101547.RAA21071@givry.inria.fr> <19990408022401.I2983@requiem.geecs.org> <199904101547.RAA21071@givry.inria.fr> Message-ID: <4.1.19990410161910.009bcf10@imap2.es.net> Seth, At 12:15 PM 4/10/99 -0700, Seth David Schoen wrote: ... >How did the regional NICs appear the first time around? I remember when they >showed up, but I wasn't really following Internet architecture matters yet. > > >Brian Carpenter is right that these delegation and pricing issues aren't going >to be solved suddenly on this list, but I'm curious about that part of the >historical context. > > >At some time before the regional NICs, IPv4 addresses _were_ "free"; the >explanation I'm familiar with is that the InterNIC's registration services >were being subsized by the US government. While I certainly don't want to >see a return to such a subsidy, I'm also very curious about the economics >of the process; the fees have been said to exist in order to cover registries' >costs (which makes sense) and also in order to conserve scarce IPv4 address >space (which also makes sense). But now IPv6 addresses are not scarce, at >least not in the same sense that IPv4 addresses are. Shouldn't this, as I've >heard suggested, cause the scarcity portion of the fees (if registration fees >can actually be broken down this way) to evaporate? > >Is this off-topic for this list? If so, is it on-topic somewhere else? I'd prefer we stick to the topic of 6bone prequalification for Sub-TLAs. However, I'm not really sure where a good place to have these kind of conversations is. Possibly some ICANN mail list? Anyone know? Meanwhile, I'm concerned that we've had lots of social commentary about registries, addresses, etc., but no comment on the process that was proposed for 6bone prequalification for Sub-TLAs. Until I hear direct comments to the contrary, I'm assuming that no one has a porblem with the proposed process. Thanks, Bob From Francis.Dupont@inria.fr Sun Apr 11 14:26:21 1999 From: Francis.Dupont@inria.fr (Francis Dupont) Date: Sun, 11 Apr 1999 15:26:21 +0200 Subject: History and economics of fees? (was: Re: 6bone Prequalification...) In-Reply-To: Your message of Sat, 10 Apr 1999 12:15:02 PDT. <19990410121502.A6329@requiem.geecs.org> Message-ID: <199904111326.PAA21879@givry.inria.fr> In your previous mail you wrote: How did the regional NICs appear the first time around? => I know well the RIPE history: the idea of RIPE is the coordination of IP networking in Europe (read RFC 1181). This has grown as the Internet has grown then one time a permanent structure became necessary: the RIPE NCC. When IANA delegated some parts of IPv4 address space to "Europe", the RIPE NCC began to manage them and to distribute address blocks to so-called "local IRs" which are now access ISPs but NCC fees are not bound to address blocks, their purpose is make up for NCC costs... I believe the ARIN history is very different (and short), the only clear purpose of ARIN is to replace the IANA/InterNIC for IPv4 address assignment/allocation in the "American" region. Brian Carpenter is right that these delegation and pricing issues aren't going to be solved suddenly on this list, but I'm curious about that part of the historical context. => the historical context is very important because some years ago the idea of address fees was not imaginable. But now IPv4 addresses are a rare resource (perhaps they are not but the important point is one believes they are) and you can only buy them... Obviously this should be transposed to IPv6 as it! At some time before the regional NICs, IPv4 addresses _were_ "free"; the explanation I'm familiar with is that the InterNIC's registration services were being subsized by the US government. While I certainly don't want to see a return to such a subsidy, I'm also very curious about the economics of the process; the fees have been said to exist in order to cover registries' costs (which makes sense) and also in order to conserve scarce IPv4 address space (which also makes sense). But now IPv6 addresses are not scarce, at least not in the same sense that IPv4 addresses are. Shouldn't this, as I've heard suggested, cause the scarcity portion of the fees (if registration fees can actually be broken down this way) to evaporate? => we agree. Is this off-topic for this list? If so, is it on-topic somewhere else? => perhaps the 6bone list is not the good place but I don't know what list to use about this topic and wordwide (ie not the RIPE IPv6 WG list). The discussion is supposed to be about the 6bone prequalification idea. I believe this is a good idea and most of the persons on the list agree. Thanks Francis.Dupont@inria.fr From peterdd@gto.net.om Sun Apr 11 16:16:03 1999 From: peterdd@gto.net.om (Peter Dawson) Date: Sun, 11 Apr 1999 19:16:03 +0400 Subject: /29 vs /35 References: <199904101547.RAA21071@givry.inria.fr> <19990408022401.I2983@requiem.geecs.org> <199904101547.RAA21071@givry.inria.fr> <4.1.19990410161910.009bcf10@imap2.es.net> Message-ID: <3710BCB3.6BD3C0E7@gto.net.om> Bob Bob Fink wrote: > Until I hear direct comments to the contrary, I'm assuming that > no one has > a porblem with the proposed process. > > Thanks, > > Bob I recall someone asking the /29 vs /35 question. whats the final fix on this ? /pete From fink@es.net Sun Apr 11 17:28:29 1999 From: fink@es.net (Bob Fink) Date: Sun, 11 Apr 1999 09:28:29 -0700 Subject: /29 vs /35 In-Reply-To: <3710BCB3.6BD3C0E7@gto.net.om> References: <199904101547.RAA21071@givry.inria.fr> <19990408022401.I2983@requiem.geecs.org> <199904101547.RAA21071@givry.inria.fr> <4.1.19990410161910.009bcf10@imap2.es.net> Message-ID: <4.1.19990411092709.01bc5890@imap2.es.net> Pete, At 07:16 PM 4/11/99 +0400, Peter Dawson wrote: ... >I recall someone asking the /29 vs /35 question. >whats the final fix on this ? There was no resolution yet (many of us expressed our frustration to the RIRs on it) and none of us have seen the revised RIR policy draft that specified it to see if they are changing this. Bob From peterdd@gto.net.om Sun Apr 11 17:33:47 1999 From: peterdd@gto.net.om (Peter Dawson) Date: Sun, 11 Apr 1999 20:33:47 +0400 Subject: /29 vs /35 References: <199904101547.RAA21071@givry.inria.fr> <19990408022401.I2983@requiem.geecs.org> <199904101547.RAA21071@givry.inria.fr> <4.1.19990410161910.009bcf10@imap2.es.net> <4.1.19990411092709.01bc5890@imap2.es.net> Message-ID: <3710CEEA.9EBF14F1@gto.net.om> Bob, Bob Fink wrote: > Pete, > > At 07:16 PM 4/11/99 +0400, Peter Dawson wrote: > ... > >I recall someone asking the /29 vs /35 question. > >whats the final fix on this ? > > There was no resolution yet (many of us expressed our > frustration to the > RIRs on it) and none of us have seen the revised RIR policy > draft that > specified it to see if they are changing this. > > Bob OK. but when do we expect to see the revised draft ?? b4 19 april ???? /pete From fink@es.net Sun Apr 11 17:56:31 1999 From: fink@es.net (Bob Fink) Date: Sun, 11 Apr 1999 09:56:31 -0700 Subject: /29 vs /35 In-Reply-To: <3710CEEA.9EBF14F1@gto.net.om> References: <199904101547.RAA21071@givry.inria.fr> <19990408022401.I2983@requiem.geecs.org> <199904101547.RAA21071@givry.inria.fr> <4.1.19990410161910.009bcf10@imap2.es.net> <4.1.19990411092709.01bc5890@imap2.es.net> Message-ID: <4.1.19990411095003.00995e60@imap2.es.net> Pete, At 08:33 PM 4/11/99 +0400, Peter Dawson wrote: ... >OK. but when do we expect to see the revised >draft ?? b4 19 april ???? The last I heard was Daniel Karrenberg's comment to the 6bone list earlier this week. Bob === >To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) >cc: 6bone@ISI.EDU, fink@es.net, kimh@arin.net, pwilson@apnic.net, mir@ripe.net, > brian@hursley.ibm.com, hinden@iprg.nokia.com, deering@cisco.com, > tonyhain@microsoft.com, Alain.Durand@imag.fr, randy@psg.com, > WIJNEN@VNET.IBM.COM >Subject: Re: 6bone Prequalification for Sub-TLA assignment >From: Daniel Karrenberg >Date: Tue, 06 Apr 1999 11:23:05 +0200 > > > > Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wr > > > > How soon will be the next draft reissued? Note that the promise > > deadline, within two weeks, has passed. > >Quality goes before speed. We had a lot of justified comments from >-among others- you folks regarding the quality of the previous version. >We want to spend enough time to not repeat those mistakes. Please >consider also that this needs local consultations as well as global >coordination between the registries. However we hope to have it out >later this week. I know that Kim Hubbard wants to discuss it at next >week's ARIN membership meeting. > >Regards > >Daniel From fink@es.net Mon Apr 12 01:49:33 1999 From: fink@es.net (Bob Fink) Date: Sun, 11 Apr 1999 17:49:33 -0700 Subject: edits on various web pages about ngtrans and 6bone relationship Message-ID: <4.1.19990411174725.00961f10@imap2.es.net> I've cleaned up various places on our web pages about the 6bone and its relationship to ngtrans. Please take a look (especially Jim :-) and let me know what I've missed. Note that the ngtrans charter is being changed to the one shown on the 6bone pages about ngtrans: Thanks, Bob From truman@superlink.net Mon Apr 12 17:32:38 1999 From: truman@superlink.net (Truman Boyes) Date: Mon, 12 Apr 1999 12:32:38 -0400 (EDT) Subject: 6bone Prequalification for Sub-TLA assignment In-Reply-To: <95bf4e0.243a264d@aol.com> Message-ID: On Mon, 5 Apr 1999 Smirk35@aol.com wrote: > Pricing the block of addresses would deter the small business wanting a very > large block of IPv6. Low cost on small blocks and tracking the number of > blocks by that company so as not to accumulate 100s of small blocks by the > same company. > > Mark H. Bowen > I think justification of allocation and assignment is always the way to go. Cost should not be a factor in requesting of addresses. The current procedures implemented by ARIN and other registries are working. Why change ? .truman.boyes. From fink@es.net Mon Apr 12 23:41:23 1999 From: fink@es.net (Bob Fink) Date: Mon, 12 Apr 1999 15:41:23 -0700 Subject: Proposed change in 6bone pTLA 3FFE usage Message-ID: <4.1.19990412082542.0095f880@imap2.es.net> 6bone Folk, At the Minneapolis IETF I proposed changing the pTLA 3FFE:/16 usage to allow future growth as the 6bone becomes used more for production. The current usage specifices an 8-bit pTLA (prefix 3FFE:xx00::/24). This only provides for 256 pTLAs, of which 55 are currently in use. In addition, if 6bone prequalification for Sub-TLAs becomes a common operational mode, we will need more pTLAs. The proposal I made in Minneapolis was for split usage of the pTLA space, with the lower half of the space left for the current 8-bit pTLAs (3FFE:0000::/24 thru 3FFE:7F00::/24, for a total of 128 8-bit pTLAs), and the upper half for 13-bit pTLAs (3FFE:8000::/29 thru 3FFE:FFF8:/29 for a total of 4096 13-bit pTLAs). As I remember, there was positive support for this with the exception comment being the difficulty in specifying the reverse path for the DNS given the 29 bit boundary. One suggestion for this was to use a 12-bit pTLA (thus a /28 prefix) to keep to a 4-bit boundary. My suggestion would be to use a full 16-bit pTLA (thus a /32) as the remaining 16-bit NLA space, up to the site's 80-bit space, is big enough for 6bone use. Also, we don't have to assign any more pTLAs than we collectively deem reasonable. Another (offline) suggestion was to use the /29 as a forcing factor to have folks adopt the newer DNS bit specification method (I'm unfamiliar with this and when it might appear). Another question about this proposal is, do we leave the first half /24 usage as is, or make those folk renumber eventually to the bigger space? Maybe this doesn't matter at the start, but I'd like opinions on this. Your comments to the list please. Thanks, Bob Thanks, Bob From map@stacken.kth.se Tue Apr 13 16:13:03 1999 From: map@stacken.kth.se (Magnus Ahltorp) Date: 13 Apr 1999 17:13:03 +0200 Subject: Proposed change in 6bone pTLA 3FFE usage In-Reply-To: Bob Fink's message of "Mon, 12 Apr 1999 15:41:23 -0700" References: <4.1.19990412082542.0095f880@imap2.es.net> Message-ID: > Another (offline) suggestion was to use the /29 as a forcing factor to have > folks adopt the newer DNS bit specification method (I'm unfamiliar with > this and when it might appear). This problem has been present for IPv4 since the advent of CIDR. Solutions have been presented, but I haven't seen any deployment in this area. I cannot see why using /29 prefixes in IPv6 would speed up development/deployment of bit-level reverse delegations. It would be good to have bit-level reverse delegations, but the idea to, with purpose, increase the work load just to make it happen, is, in my opinion, a bad one. /Magnus From bound@zk3.dec.com Tue Apr 13 23:26:57 1999 From: bound@zk3.dec.com (Jim Bound) Date: Tue, 13 Apr 1999 18:26:57 -0400 Subject: /29 vs /35 In-Reply-To: Your message of "Sun, 11 Apr 1999 19:16:03 +0400." <3710BCB3.6BD3C0E7@gto.net.om> Message-ID: <199904132226.SAA0000026741@quarry.zk3.dec.com> yep I asked the question on /29 vs /35... I think the answer was is still being debated..?? /jim From mir@ripe.net Tue Apr 13 23:56:55 1999 From: mir@ripe.net (Mirjam Kuehne) Date: Wed, 14 Apr 1999 00:56:55 +0200 Subject: new IPv6 policy draft - real soon now Message-ID: <199904132256.AAA03282@birch.ripe.net> Dear colleagues, We are aware that the promised deadline for the next IPv6 policy draft has passed. We are sorry for that delay and thank you for your patience. The ARIN members met yesterday and today and were given the opportunity to discuss the proposed policies. During this discussion we received very good input. These comments are now being incorporated in the new draft and we expect to send this new version out in a couple of days. Mirjam Kuehne RIPE NCC From bound@zk3.dec.com Wed Apr 14 04:10:29 1999 From: bound@zk3.dec.com (Jim Bound) Date: Tue, 13 Apr 1999 23:10:29 -0400 Subject: Quick questions (on a deadline) In-Reply-To: Your message of "Tue, 13 Apr 1999 15:30:09 EDT." <37139B41.6737D859@loshin.com> Message-ID: <199904140310.XAA0000012402@quarry.zk3.dec.com> Pete, >- Any comments about relative importance of dual-IP vs tunneling vs >NAT-PT for IPv4/IPv6 interoperability? Yep. We are working on it diligently. We are not done yet. We hope to be done soon. Right now to build any products on these technologies is premature. Prototypes yes. Thats why I think ngtrans is now far more important for cycles in the IETF than IPng at this time. IMHO of course. Users need to determine as I pointed out to you for the article what, how, and when they want to transition and what is best for their business model. Multiple tools will be defined and some out of the IETF most likely that will be added value. But a user will have a range of tools to use just like a carpenter, mason, or landscaper does in their tasks. Each of the tools are important you mentioned above IMO. How they will be used and by whom will be TBD when IPv6 deployment ramps up a bit more than now. I could see a case where all three are used in one organization eventually. /jim From pfs@cisco.com Wed Apr 14 10:54:15 1999 From: pfs@cisco.com (Philip Smith) Date: Wed, 14 Apr 1999 19:54:15 +1000 Subject: new IPv6 policy draft - real soon now In-Reply-To: <199904132256.AAA03282@birch.ripe.net> Message-ID: <4.1.19990414195007.00a89350@lint.cisco.com> Hello Mirjam, Can you or someone else who was at the meeting summarise the input received from the ARIN community to the 6bone and ipv6-wg lists? For those not present, the specific feedback would be most interesting/useful... thanks! philip -- At 00:56 14/04/99 +0200, Mirjam Kuehne wrote: > >Dear colleagues, > >We are aware that the promised deadline for the next IPv6 policy draft >has passed. We are sorry for that delay and thank you for your >patience. > >The ARIN members met yesterday and today and were given the >opportunity to discuss the proposed policies. During this discussion >we received very good input. These comments are now being incorporated >in the new draft and we expect to send this new version out in a >couple of days. > >Mirjam Kuehne >RIPE NCC > > > From mir@ripe.net Wed Apr 14 15:59:18 1999 From: mir@ripe.net (Mirjam Kuehne) Date: Wed, 14 Apr 1999 16:59:18 +0200 Subject: new IPv6 policy draft - real soon now In-Reply-To: Your message of Wed, 14 Apr 1999 19:54:15 +1000. <4.1.19990414195007.00a89350@lint.cisco.com> Message-ID: <199904141459.QAA01942@birch.ripe.net> Hi Philip, A working group was created to discuss allocation policies. This working group also discussede the initial allocation criteria as proposed in the current draft (with participation on the 6bone added as one criteria). The feedback was very positive, also regarding the slow start mechanism. We also received useful input regarding some of the parameters in the allocation criteria, for example 12 for the number of months within which IPv6 services will have to be provided and 42 :-) for the number of customers the ISP has to have in one of the other criteria (we'll probably round this up or down in the final document :-) I suggest to further discuss this when the new draft will be sent to the list in one of the next days. Mirjam Philip Smith writes: * Hello Mirjam, * * Can you or someone else who was at the meeting summarise the input received * from the ARIN community to the 6bone and ipv6-wg lists? For those not * present, the specific feedback would be most interesting/useful... * * thanks! * * philip * -- * * At 00:56 14/04/99 +0200, Mirjam Kuehne wrote: * > * >Dear colleagues, * > * >We are aware that the promised deadline for the next IPv6 policy draft * >has passed. We are sorry for that delay and thank you for your * >patience. * > * >The ARIN members met yesterday and today and were given the * >opportunity to discuss the proposed policies. During this discussion * >we received very good input. These comments are now being incorporated * >in the new draft and we expect to send this new version out in a * >couple of days. * > * >Mirjam Kuehne * >RIPE NCC * > * > * > * * From mrosa@fc.ul.pt Thu Apr 15 09:33:01 1999 From: mrosa@fc.ul.pt (Miguel Rosa) Date: Thu, 15 Apr 1999 09:33:01 +0100 Subject: Proposed change in 6bone pTLA 3FFE usage References: <4.1.19990412082542.0095f880@imap2.es.net> Message-ID: <007b01be871a$94822850$140175c2@ip6.fc.ul.pt> > One suggestion for this was to use a 12-bit pTLA (thus a /28 prefix) to > keep to a 4-bit boundary. > Another (offline) suggestion was to use the /29 as a forcing factor to have > folks adopt the newer DNS bit specification method (I'm unfamiliar with > this and when it might appear). > > Another question about this proposal is, do we leave the first half /24 > usage as is, or make those folk renumber eventually to the bigger space? > Maybe this doesn't matter at the start, but I'd like opinions on this. > > Your comments to the list please. The idea of using 12-bit pTLA seems good enough. We would have, for now, 128 pTLAS in the first half (prefix 3FFE:xx00::/24 for xx bettween 00 and 7F) and 2048 in the second (prefix 3FFE:xxx0::/24 for xxx bettween 800 and FFF). Then, there would be a recommendation for the current xx be converted to the best xxx that they would like (i.e., gives them less trouble to convert). We would increasingly have the 4096 pTLA capacity after all conversions and not have to worry about the DNS problem because I'm also with Magnus about all that he says, although it would be great to have bit-level reverse delegations. Miguel Rosa mrosa@fc.ul.pt http://www.ip6.fc.ul.pt From mir@ripe.net Thu Apr 15 11:36:01 1999 From: mir@ripe.net (Mirjam Kuehne) Date: Thu, 15 Apr 1999 12:36:01 +0200 Subject: new IPv6 policy draft - real soon now In-Reply-To: Your message of Wed, 14 Apr 1999 13:13:11 MDT. <19990414131311.B1310@qwest.net> Message-ID: <199904151036.MAA26722@birch.ripe.net> Hi David, thanks for adding some details. David Kessens writes: * * Mirjam, * * On Wed, Apr 14, 1999 at 04:59:18PM +0200, Mirjam Kuehne wrote: * > * > A working group was created to discuss allocation policies. * > This working group also discussede the initial allocation criteria * > as proposed in the current draft (with participation on the 6bone added * > as one criteria). * * The wg was (interim-)chaired by: Sandra Reimer from McLeadUSA. I hope * we will be able to get the minutes from her as soon as possible. * * > The feedback was very positive, also regarding the slow start * > mechanism. We also received useful input regarding some of the * > parameters in the allocation criteria, for example 12 for the number * > of months within which IPv6 services will have to be provided and * > 42 :-) for the number of customers the ISP has to have in one of the * > other criteria (we'll probably round this up or down in the final * > document :-) * * It was my impression that the number of 42 was the optimal number and * that nobody wanted to have anything less/more ;-). There is no reason * to start playing again with those numbers. Another point that was * discussed was the removal of the condition entirely since the other * condition (intent to provide IPv6 service) was easier to qualify for * anyways. * * The biggest concern left was the slow start procedure within the sTLA. * It was discussed at length but no agreement could be reached. The * registries want to have some kind of control against allocations that * are given out that are not used as they are supposed to be used, while One other reason is that if all organisations/networks have the same prefix length ISPs will have difficulties to make rationale routing decisions if that may be necessary in the future. Mirjam * at the same time most customers of the registries would obviously like * to have maximum freedom & minimal paperwork. The registries asked for * alternatives that would have the same effect - one of the variations * that was discussed, was to make the slow start even slower (eg.: you * can only assign a very small number of NLAs before returning to the * registry), and to allocate the full space soon thereafter. It was * agreed that more discussion this topic would be needed. * * David K. * --- * From brian@hursley.ibm.com Thu Apr 15 13:48:12 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 15 Apr 1999 13:48:12 +0100 Subject: new IPv6 policy draft - real soon now References: <199904151036.MAA26722@birch.ripe.net> Message-ID: <3715E00C.587E094C@hursley.ibm.com> > * The biggest concern left was the slow start procedure within the sTLA. > * It was discussed at length but no agreement could be reached. The > * registries want to have some kind of control against allocations that > * are given out that are not used as they are supposed to be used, while > > One other reason is that if all organisations/networks have the same > prefix length ISPs will have difficulties to make rationale routing > decisions if that may be necessary in the future. Well hang on a moment. sTLAs are intended for ISPs and exchange points, and we're expecting them all to show up in the default-free table. I don't see your point. Brian From fink@es.net Thu Apr 15 15:08:03 1999 From: fink@es.net (Bob Fink) Date: Thu, 15 Apr 1999 07:08:03 -0700 Subject: new IPv6 policy draft - real soon now In-Reply-To: <3715E00C.587E094C@hursley.ibm.com> References: <199904151036.MAA26722@birch.ripe.net> Message-ID: <4.1.19990415065727.01be94e0@imap2.es.net> Brian, At 01:48 PM 4/15/99 +0100, Brian E Carpenter wrote: >> * The biggest concern left was the slow start procedure within the sTLA. >> * It was discussed at length but no agreement could be reached. The >> * registries want to have some kind of control against allocations that >> * are given out that are not used as they are supposed to be used, while >> >> One other reason is that if all organisations/networks have the same >> prefix length ISPs will have difficulties to make rationale routing >> decisions if that may be necessary in the future. > >Well hang on a moment. sTLAs are intended for ISPs and exchange >points, and we're expecting them all to show up in the default-free >table. I don't see your point. It is a built in discriminator for the future. That is, if in the future the larger ISPs with sTLAs decide to not carry routes for lesser sTLAs, they make their cut on length of prefix. I've been getting lots of flack from ESnet engineering staff for having any such built in discriminator (as if I had a choice :-). I had been skeptical at first that this was the intent, but increasingly I see that their fears are justified by comments such as Mirjam's. TO say the least, I don't like it. It is basically the large (which often means more financially influential) being able to automatically discriminate against small. If it was simply a way to avoid ultra large routing tables, maybe it could be justified, but the hidden agenda that appears more and more in the v4 world is for large ISPs to muscle the smaller into paying for peering/connectivity. It would be nice if v6 could stay as neutral as possible on this, and at least not give overtly obvious ways to encourage such behaviour. Bob From bound@zk3.dec.com Thu Apr 15 15:23:07 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 15 Apr 1999 10:23:07 -0400 Subject: edits on various web pages about ngtrans and 6bone relationship In-Reply-To: Your message of "Sun, 11 Apr 1999 17:49:33 PDT." <4.1.19990411174725.00961f10@imap2.es.net> Message-ID: <199904151423.KAA0000024910@quarry.zk3.dec.com> Hi Bob, >I've cleaned up various places on our web pages about the 6bone and its >relationship to ngtrans. > >Please take a look (especially Jim :-) and let me know what I've missed. >Note that the ngtrans charter is being changed to the one shown on the >6bone pages about ngtrans: > > >3. Coordinating with the IPv6 6bone testbed, operating under the IPv6 > Testing Address Allocation allocated in Experimental RFC 2471, to > foster the development, testing, and deployment of IPv6. I would change to: 3. Coordinating with the IPv6 6bone testbed, operating under the IPv6 Testing Address Allocation allocated in Experimental RFC 2471, to foster the development, testing, and deployment of IPv6. ^^^^^^ assist I think "foster" sounds like one owns the thing. assist is really what is happening. On the IETF WEB Page Charter. I am find with paragraph '1' on the web page. >2. Define and specify the mandatory and optional mechanisms that vendors >are to implement in >hosts, routers, and other components of the Internet in order for the >transition to be carried out. >Dual protocol stack, encapsulation and header translation mechanisms >must all be defined, as well >as the interaction between hosts using different combinations of these >mechanisms. The >specifications produced will be used by people implementing these IPv6 >systems In the above we need to not send the message that any vendor MUST implement all of these tools. If you implement the tool then some MUST will apply. But the tool is optional. SIT should be mandatory I agree and I think it is. I think you did that in the first sentence. More clarity may be provided by adding the adverbial clause below: "Define and specify the mandatory and optional mechanisms, and the mandatory parts of optional mechanisms, that vendors are to implement in hosts, routers.....etc... >3.. Articulate a concrete operational plan for transitioning from IPv4 to >IPv6. The result of this >work will be a transition plan for the Internet that network operators >and Internet subscribers can >execute. I think this is a tall order as stated and unrealistic. How about: 3. Articulate a concrete operational plan for the initial interoperation and eventual transition from IPv4 to IPv6. The result of this work will be a transitional guideline for the Internet and network operators, and one which Internet subscribers can execute. I really like Section 4 (note the word "assist" is used here too) and Section 5 is obvious. thanks /jim From brian@hursley.ibm.com Thu Apr 15 15:52:21 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 15 Apr 1999 15:52:21 +0100 Subject: new IPv6 policy draft - real soon now References: <199904151036.MAA26722@birch.ripe.net> <4.1.19990415065727.01be94e0@imap2.es.net> Message-ID: <3715FD25.7AFF493E@hursley.ibm.com> Right. Well, I still want to see the revised text before I rush to judgement. Brian Bob Fink wrote: > > Brian, > > At 01:48 PM 4/15/99 +0100, Brian E Carpenter wrote: > >> * The biggest concern left was the slow start procedure within the sTLA. > >> * It was discussed at length but no agreement could be reached. The > >> * registries want to have some kind of control against allocations that > >> * are given out that are not used as they are supposed to be used, while > >> > >> One other reason is that if all organisations/networks have the same > >> prefix length ISPs will have difficulties to make rationale routing > >> decisions if that may be necessary in the future. > > > >Well hang on a moment. sTLAs are intended for ISPs and exchange > >points, and we're expecting them all to show up in the default-free > >table. I don't see your point. > > It is a built in discriminator for the future. That is, if in the future > the larger ISPs with sTLAs decide to not carry routes for lesser sTLAs, > they make their cut on length of prefix. I've been getting lots of flack > from ESnet engineering staff for having any such built in discriminator (as > if I had a choice :-). I had been skeptical at first that this was the > intent, but increasingly I see that their fears are justified by comments > such as Mirjam's. > > TO say the least, I don't like it. It is basically the large (which often > means more financially influential) being able to automatically > discriminate against small. If it was simply a way to avoid ultra large > routing tables, maybe it could be justified, but the hidden agenda that > appears more and more in the v4 world is for large ISPs to muscle the > smaller into paying for peering/connectivity. > > It would be nice if v6 could stay as neutral as possible on this, and at > least not give overtly obvious ways to encourage such behaviour. > > Bob From fink@es.net Thu Apr 15 16:16:19 1999 From: fink@es.net (Bob Fink) Date: Thu, 15 Apr 1999 08:16:19 -0700 Subject: edits on various web pages about ngtrans and 6bone relationship In-Reply-To: <199904151423.KAA0000024910@quarry.zk3.dec.com> References: Message-ID: <4.1.19990415075532.01beb7a0@imap2.es.net> Jim, Thanks for the comments. The stuff on the IETF web page is the old stuff and will change to look like the stuff on the 6bone/ngtrans page. I will be mailing this to the list today or tomorrow. As for the 'foster' versus 'assist', I think it doesn't matter, but also don't really care. Let's wait for the mailing of the charter and see who else comments. Bob At 10:23 AM 4/15/99 -0400, Jim Bound wrote: >Hi Bob, > >>I've cleaned up various places on our web pages about the 6bone and its >>relationship to ngtrans. >> >>Please take a look (especially Jim :-) and let me know what I've missed. > >>Note that the ngtrans charter is being changed to the one shown on the >>6bone pages about ngtrans: >> >> > >>3. Coordinating with the IPv6 6bone testbed, operating under the IPv6 >> Testing Address Allocation allocated in Experimental RFC 2471, to >> foster the development, testing, and deployment of IPv6. > >I would change to: > >3. Coordinating with the IPv6 6bone testbed, operating under the IPv6 > Testing Address Allocation allocated in Experimental RFC 2471, to > foster the development, testing, and deployment of IPv6. > ^^^^^^ > assist > >I think "foster" sounds like one owns the thing. assist is really what >is happening. > >On the IETF WEB Page Charter. > >I am find with paragraph '1' on the web page. > >>2. Define and specify the mandatory and optional mechanisms that vendors >>are to implement in >>hosts, routers, and other components of the Internet in order for the >>transition to be carried out. >>Dual protocol stack, encapsulation and header translation mechanisms >>must all be defined, as well >>as the interaction between hosts using different combinations of these >>mechanisms. The >>specifications produced will be used by people implementing these IPv6 >>systems > >In the above we need to not send the message that any vendor MUST >implement all of these tools. If you implement the tool then some MUST >will apply. But the tool is optional. SIT should be mandatory I agree >and I think it is. I think you did that in the first sentence. More >clarity may be provided by adding the adverbial clause below: > >"Define and specify the mandatory and optional mechanisms, and the >mandatory parts of optional mechanisms, that vendors are to implement in >hosts, routers.....etc... > >>3.. Articulate a concrete operational plan for transitioning from IPv4 to >>IPv6. The result of this >>work will be a transition plan for the Internet that network operators >>and Internet subscribers can >>execute. > >I think this is a tall order as stated and unrealistic. How about: > >3. Articulate a concrete operational plan for the initial interoperation >and eventual transition from IPv4 to IPv6. The result of this work will >be a transitional guideline for the Internet and network operators, and >one which Internet subscribers can execute. > >I really like Section 4 (note the word "assist" is used here too) and >Section 5 is obvious. > >thanks >/jim From brian@hursley.ibm.com Thu Apr 15 17:45:38 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Thu, 15 Apr 1999 17:45:38 +0100 Subject: new IPv6 policy draft - real soon now References: <199904151314.PAA17232@titan.urec.fr> <199904151624.SAA14930@birch.ripe.net> Message-ID: <371617B2.E5585787@hursley.ibm.com> Daniel, The point is that unless we are collectively foolish, IPv6 will not have a disaggregation problem - it starts out classless and provider-based, and dual homing will in the end be solved by dual prefixes. I really can't see why we would *need* prefix length based discrimination as we do for IPv4. Brian Daniel Karrenberg wrote: > > > Bernard.Tuy@urec.cnrs.fr (Bernard TUY) writes: > > ====BT: moreover, one can imagine carriers will be able to aggregate ISPs p > > refixes. > > If they've got different legnth ones, I don't know how to achieve this. > > Aggregation is governed by topology and allocation policy. > Hierarchy helps aggregation. I do not see how equal prefix length > helps aggregation. Please explain. > > Daniel From fink@es.net Thu Apr 15 18:31:28 1999 From: fink@es.net (Bob Fink) Date: Thu, 15 Apr 1999 10:31:28 -0700 Subject: new IPv6 policy draft - real soon now In-Reply-To: <199904151621.SAA14785@birch.ripe.net> References: <4.1.19990415065727.01be94e0@imap2.es.net> Message-ID: <4.1.19990415094940.01be92d0@imap2.es.net> Daniel, At 06:21 PM 4/15/99 +0200, Daniel Karrenberg wrote: ... >PS: I do not understand you presenting this as a hidden agenda. It has >been out in the open and I have explained this to you personally during >the last IETF. Sorry to have given the impression that this is something I just found out about. You have definitely explained it to me and others at the recent IAB meeting, and I appreciate your taking the time to do that. Of course that doesn't mean that there is agreement with the approach. It was also the case that, at the IAB discussion, you and/or other RIR folk present felt that it might not be necssary to take this approach if we could control the land rush for TLAs/sTLAs (by methods such as 6bone prequalification and tough entry policies). Unfortunately this tack in the conversation wasn't folowed up due to time constraints. I have been waiting to see the next draft to see what the updated thinking of the RIRs is while also pursuing the 6bone prequalification process. However, I am concerned about this approach for more than the social policy stuff. When one does aggregation the way v6 does, it needs reasonably sized NLA space to provide a decent level of aggregatable hierarchy below the sTLA level for multiple levels of lower tier providers and their end-sites below them. With the /29 sTLA slow start, as specified in RFC 2450, there are only 19 bits of NLA to play with... a tight but reasonable tradeoff if one imagined a two- or three-level hierarchy (sTLA and one or two levels of NLA transits below). With a /35 sTLA it gets real tight as only 13 bits are left to play with. To summarize, I don't think the RIRs have any hidden agenda here, and do hope the RIRs don't use the /35 system and stay with the /29 the IETF process proposed to them. Thanks, Bob From bound@zk3.dec.com Thu Apr 15 18:35:00 1999 From: bound@zk3.dec.com (Jim Bound) Date: Thu, 15 Apr 1999 13:35:00 -0400 Subject: edits on various web pages about ngtrans and 6bone relationship In-Reply-To: Your message of "Thu, 15 Apr 1999 08:16:19 PDT." <4.1.19990415075532.01beb7a0@imap2.es.net> Message-ID: <199904151735.NAA0000007752@quarry.zk3.dec.com> sounds good.......... /jim From brian@hursley.ibm.com Fri Apr 16 09:41:50 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Fri, 16 Apr 1999 09:41:50 +0100 Subject: new IPv6 policy draft - real soon now References: <199904151621.SAA14785@birch.ripe.net> <4.1.19990415065727.01be94e0@imap2.es.net> <4.1.19990415134804.00d9ab20@192.149.252.141> Message-ID: <3716F7CE.497BF5D0@hursley.ibm.com> Kim Hubbard wrote: ... > Bob, > > I understand your concerns but I honestly think you can accomplish your goals > using the slow start method. If an organization requesting address space can > justify a larger block than a /35 for heirarchical reasons or other than they > will receive it. I believe many organizations will start out *very* slow > at first so I don't see a reason to issue the entire sub-tla. Instead, issuing > a smaller block (8K+) will give the RIRs ample time to verify that the > organizations are utilizing the space and sending reassignment info, etc. Kim, This is the argument you gave us in Minn. and I bought it, as long as it is *not* transformed later into an excuse for sub-allocating the /29s and thereby inviting the creation of an IPv6 toxic waste dump. That's why I'm eagerly awaiting the exact wording of the new draft. Brian From brian@hursley.ibm.com Fri Apr 16 09:46:57 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Fri, 16 Apr 1999 09:46:57 +0100 Subject: new IPv6 policy draft - real soon now References: <86256754.005BC95F.00@smtp2.mcld.net> <199904151659.SAA18451@birch.ripe.net> Message-ID: <3716F901.8BD06595@hursley.ibm.com> Daniel Karrenberg wrote: ... > Of course it is not surprising that I raise the same concerns because > I am responsible for one of the registries and we listen very closely > to ther 1300+ ISPs from 70+ countries who are our members and fund > our activities. They are who determine our policies. Daniel, this is correct and as it should be. However the interests of the ISPs include the state of the grass on the common land, and specifically the avoidance of a toxic waste dump. There the RIRs should IMHO take a view that is wider than the sum of the views of the ISPs. Brian From kato@wide.ad.jp Fri Apr 16 12:27:56 1999 From: kato@wide.ad.jp (Akira Kato) Date: Fri, 16 Apr 1999 20:27:56 +0900 Subject: New draft from APNIC Message-ID: <19990416202756O.kato@nezu.wide.ad.jp> Folks, A new draft from APNIC is available: http://www.apnic.net/drafts/ipv6 -- Akira Kato From fink@es.net Mon Apr 19 15:49:17 1999 From: fink@es.net (Bob Fink) Date: Mon, 19 Apr 1999 07:49:17 -0700 Subject: new RIR IPv6 Assignment and Allocation draft out Message-ID: <4.1.19990419074650.00ac5cd0@imap2.es.net> The new RIR IPv6 Assignment and Allocation draft is out and will be circulated to all the lists shorly. Bob From bound@zk3.dec.com Tue Apr 20 03:21:47 1999 From: bound@zk3.dec.com (Jim Bound) Date: Mon, 19 Apr 1999 22:21:47 -0400 Subject: Announcement: Trumpet Fanfare released. In-Reply-To: Your message of "Fri, 16 Apr 1999 22:30:47 +1000." Message-ID: <199904200221.WAA0000013287@quarry.zk3.dec.com> Peter, Congrats to you and Trumpet. I firmly believe now we all need to ship. Your leading the pack here and it is greatly appreciated by us who want IPv6 to succeed and soon............. IPv6 can't happen without shipping products even with the best business case on paper. /jim From fink@es.net Wed Apr 21 01:59:37 1999 From: fink@es.net (Bob Fink) Date: Tue, 20 Apr 1999 17:59:37 -0700 Subject: new RIR IPv6 Assignment and Allocation Policy draft (16Apr99) Message-ID: <4.1.19990420175742.00a2bbf0@imap2.es.net> Here is the new RIR IPv6 Assignment and Allocation Policy draft for your comments by May 3: Please send your comments just to the list you receive this message on (i.e., a simple reply). Hopefully this will minimize multiple copies being sent. I'll make sure to gather comments from the various lists for any composite reponse to the RIRs. Thanks, Bob From peter@jazz-1.trumpet.com.au Fri Apr 23 07:28:28 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Fri, 23 Apr 1999 16:28:28 +1000 (EST) Subject: ideas for automatic tunnel configs Message-ID: In the interests of increasing the ease of getting customers to hook up to the 6bone, I am planning to build both ends of a tunnel client/server mechanism. Are there any places where I could start apart from the obvious RFC on IPv6 tunnels? I guess what I'd need would be a way to manage the tunnel end points automatically without need for configuration. Perhaps a higher layer TCP or UDP protocol that would establish the tunnel and manage it. Or perhaps a special keep alive packet that could be sent to a tunnel concentrator that would keep the tunnel open. While there could be security implications with tunnel hijacking under such a scheme at this early stage, the benefits of being able to automatically hook up to the 6bone could outweigh the risks. -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From Alain.Durand@imag.fr Fri Apr 23 08:52:13 1999 From: Alain.Durand@imag.fr (Alain Durand) Date: Fri, 23 Apr 1999 09:52:13 +0200 Subject: ideas for automatic tunnel configs In-Reply-To: Message-ID: <4.2.0.32.19990423095130.00a29670@brahma.imag.fr> At 16:28 23/04/99 +1000, Peter Tattam wrote: >In the interests of increasing the ease of getting customers to hook up to >the 6bone, I am planning to build both ends of a tunnel client/server >mechanism. > >Are there any places where I could start apart from the obvious RFC on >IPv6 tunnels? > >I guess what I'd need would be a way to manage the tunnel end points >automatically without need for configuration. Perhaps a higher layer TCP >or UDP protocol that would establish the tunnel and manage it. Or perhaps >a special keep alive packet that could be sent to a tunnel concentrator >that would keep the tunnel open. > >While there could be security implications with tunnel hijacking under >such a scheme at this early stage, the benefits of being able to >automatically hook up to the 6bone could outweigh the risks. Have you look at the tunnel broker model? draft-ietf-ngtrans-broker-00.txt - Alain. From brian@hursley.ibm.com Fri Apr 23 02:24:47 1999 From: brian@hursley.ibm.com (Brian E Carpenter) Date: Fri, 23 Apr 1999 02:24:47 +0100 Subject: Multi homing & NLAs. References: Message-ID: <371FCBDF.E6DAF7F4@hursley.ibm.com> I don't think we should worry about the singly addressed version of multihoming. There's no reason to, since we can use multiple addresses. I think that a PASTE-like mechanism resolves the failover problem that Perry was worrying about. And surely nobody writes serious apps that depend on long-term TCP sessions surviving? If you need that kind of assurance you build it into the app. I take Jim's point that in some situations address selection can be pretty subtle and it should be/must be addressed in its own document. But please let's not try and solve all this by tweaking the address allocation policy. We have running code proof that this is a broken solution. Brian Peter Tattam wrote: > > I'm sorry if I've confused people about the multihoming issue. The > discussion has helped me to resolve some issues but not others. > > First some terminology issues for the discussion. > > When I refer to "multi-homing", I am using a broad definition of "being > connected to the internet at more than one place in the internet > topology". This means that I could be connected at two or more points > anywhere in the internet, and not restricted to a region. > > When I refer to "multi-addressing" I am referring to the ability for a > site to have more than one prefix which is accessible from the internet. > i.e. the addresses are public. A site would be called "multiply > addressed" under this situation. It may or may not be multiply homed. > > If a site has only one prefix, I refer to it as being "singly addressed". > > I think we can be agreed on those points - in this discussion anyway. > > The way I see it, there are two ways to be multihomed, singly addressed > and multiply addressed. The way the multi homing operates with each model > is distinctly different. > > Now take the case of a multiply addressed site. If we consider the IPv6 > network as a tree structure which the current 6bone routing policies > encourage, then a site could be connected at two points on that tree. > Packets would follow different paths on the tree based on which address > were selected in the host by the source address selection policies of the > hosts in that site. I concede that router updates may be the best way of > finding the "best" route if only *one* default route is advertised by the > immediate routers in the site local network. It does not solve the > problem of long running connections though. We cannot dictate to higher > level protocols regarding this issue. TCP for example is supposed to > allow connections to remain active for an indefinite amount of time, even > over network outages. Without the ability for IPv6 to renumber active > connections, then this will be a problem for multiply addressed sites, > even if a defined way of obtaining the best source address can be found. > > Now take the case of a singly addressed site. While we have solved the > long running TCP connection problem, I see there are other difficulties. > > Can I explain by way of an example. > > Say I have I am a site connected to two NLA's, each in themselves > connected to two independent TLA's respectively. I hope this diagram can > do it justice. > > /--A----NLA1-----C----TLA1---E----\ > Site / \The 6bone. > \ / > \--B----NLA2-----D----TLA2---F----/ > > The links are named "A" through "F". > > I will use my own addresses for the example.. > > NLA1 is connected to VBNS prefix 3FFE:2800::/24, > NLA1 address is 3FFE:2804::/32 > > NLA2 is connected to Sprint prefix 3FFE:2900::/24 > NLA2 address is 3FFE:2901::/32 > > Now my site address from the VBNS side 3FFE:2804:1::/48 > and from the Sprint side 3FFE:2901:1::/48 > > If I only select only one address say 3FFE:2901:1::/48, then as long as I > have a route both ways through the Sprint network (TLA2) then I'll have > connectivity. if link B, D or F goes down, I have a problem. My > understanding of the 6bone routing policy is that no addresses with > prefixes longer than /24 are allowed to be advertised in the default free > zone. This means that even if I could get to the internet via VBNS > (TLA1), routing policies preclude it. If there was a peering arrangement > between TLA1 & TLA2 or between NLA1 & NLA2 , then if either E or F went > down I might still have connectivity as the two sites may exchange BGP > information. If however link A, B, C or D went down (which is more likely > anyway), I have a problem unless NLA1 and NLA2 have a peering arrangement. > Considering a worst case scenario where there are no peering arrangements > whatsoever, a site multiply homed in this way would not work, mainly > because of the default free zone rules that are currently in place. > > In my understanding this differs significantly from current practice in > the IPv4 world as a multiply homed site would have to have a routing entry > in the default free zone to work. > > I stress that this is not an IPv6 problem per se, but rather our > application of current routing policy to IPv6. > > My suggestion for this problem is to relax the default free zone rules in > a controlled manner. Under the quiescent state (all links up), the normal > rules apply which would leave ethe default free zone small. If however a > site is down, there may be a need for a site which is inaccessible from > one TLA to punch through to the DFZ via another TLA. Is this planned > routing practice, or is it forbidden? (or does BGP just work that way) > > So in summary, both methods of multihoming have their problems. For a > multiply addressed site, there is the issue of selecting the best source > address, and also the issue of preserving long running connections. For a > singly addressed site, there may be problems getting connectivity if > default free zone rules are adhered to. > > There is a side issue about source addressing which seems to have been a > source of contention which I don't think has been particularly well > defined at this point in time. For it to work properly, all hosts in the > site must participate in a controlled manner. My opinion is that this is > not something we can fix later, as it is a fundamental IPv6 stack issue. > If we start deploying IPv6 stacks soon, we will have a problem as there > will need to be a whole heap of upgrades when we've figured out how best > it is to be done. It's not an issue that can be sidelined by letting the > router working groups solve it later - it affects everybody. > > [ For me personally, multi homing is bad enough under current Ipv4 > practices. We're a small ISP and we don't do it fully. We have multiple > connections, but traffic flows out via static routes and quite > arbitrarily. We certainly don't use multi addressing because communicating > that to the hosts would be a nightmare. I am told internal BGP could > solve our problem, but the routing table sizes make it prohibitive with > the limited sized routers which we run. ] > > With larger ISP's I believe multi homing is essential to the quality of > their service so if they were to switch to IPv6, they would have a need to > do it and do it soon. > > Once we've worked all this out, perhaps we need to put together a multi > homing how-to fact sheet so that this issue doesn't have to get thrashed > out yet again. > > Does this explain things better? > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > --------------------------------------------------------------------- > The IPv6 Deployment Mailing List > Unsubscribe by sending "unsubscribe deployment" to majordomo@ipv6.org From Marc.Blanchet@viagenie.qc.ca Fri Apr 23 22:46:19 1999 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Fri, 23 Apr 1999 17:46:19 -0400 Subject: 100th IPv6 tunnel! Message-ID: <4.1.19990423173428.03855ee0@mail.viagenie.qc.ca> Hi, On our IPv6 tunnel server (http://www.freenet6.net), we just hit today the 100th client getting a (free) IPv6 tunnel! Well, this is one kind of progress for IPv6 deployment: We didn't advertise our IPv6 tunnel server up to now, and have that much of tunnels. Regards, Marc. ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ From peter@jazz-1.trumpet.com.au Sat Apr 24 05:20:47 1999 From: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Sat, 24 Apr 1999 14:20:47 +1000 (EST) Subject: Multi homing & NLAs. In-Reply-To: <371FCBDF.E6DAF7F4@hursley.ibm.com> Message-ID: On Fri, 23 Apr 1999, Brian E Carpenter wrote: > I don't think we should worry about the singly addressed > version of multihoming. There's no reason to, since we can use > multiple addresses. > > I think that a PASTE-like mechanism resolves the failover > problem that Perry was worrying about. And surely nobody writes > serious apps that depend on long-term TCP sessions surviving? > If you need that kind of assurance you build it into the app. > > I take Jim's point that in some situations address selection > can be pretty subtle and it should be/must be addressed in its > own document. > > But please let's not try and solve all this by tweaking the > address allocation policy. We have running code proof that > this is a broken solution. I fully understand and would not realy want to alter it. However to sustain the policy, we need to solve the source address problems. Firstly selection of source address which appears to be manageable, and secondly modifying the source address of long running tcp connections. I stand by my firm opinion that it is not acceptable to insist on higher layers having to reestablish a tcp connection in the case of a network outage. It will cause significant disruption to a wide array of existing applications that rely on state information being bound to the tcp/ip connection. By solving one problem, we create a problem elsewhere in the IP framework. I don't believe this is progress, and if enough people perceive the issue in the wrong way.... well, I'm not going to say any more as I will get blasted again. Peter > > Brian > > > Peter Tattam wrote: > > > > I'm sorry if I've confused people about the multihoming issue. The > > discussion has helped me to resolve some issues but not others. > > > > First some terminology issues for the discussion. > > > > When I refer to "multi-homing", I am using a broad definition of "being > > connected to the internet at more than one place in the internet > > topology". This means that I could be connected at two or more points > > anywhere in the internet, and not restricted to a region. > > > > When I refer to "multi-addressing" I am referring to the ability for a > > site to have more than one prefix which is accessible from the internet. > > i.e. the addresses are public. A site would be called "multiply > > addressed" under this situation. It may or may not be multiply homed. > > > > If a site has only one prefix, I refer to it as being "singly addressed". > > > > I think we can be agreed on those points - in this discussion anyway. > > > > The way I see it, there are two ways to be multihomed, singly addressed > > and multiply addressed. The way the multi homing operates with each model > > is distinctly different. > > > > Now take the case of a multiply addressed site. If we consider the IPv6 > > network as a tree structure which the current 6bone routing policies > > encourage, then a site could be connected at two points on that tree. > > Packets would follow different paths on the tree based on which address > > were selected in the host by the source address selection policies of the > > hosts in that site. I concede that router updates may be the best way of > > finding the "best" route if only *one* default route is advertised by the > > immediate routers in the site local network. It does not solve the > > problem of long running connections though. We cannot dictate to higher > > level protocols regarding this issue. TCP for example is supposed to > > allow connections to remain active for an indefinite amount of time, even > > over network outages. Without the ability for IPv6 to renumber active > > connections, then this will be a problem for multiply addressed sites, > > even if a defined way of obtaining the best source address can be found. > > > > Now take the case of a singly addressed site. While we have solved the > > long running TCP connection problem, I see there are other difficulties. > > > > Can I explain by way of an example. > > > > Say I have I am a site connected to two NLA's, each in themselves > > connected to two independent TLA's respectively. I hope this diagram can > > do it justice. > > > > /--A----NLA1-----C----TLA1---E----\ > > Site / \The 6bone. > > \ / > > \--B----NLA2-----D----TLA2---F----/ > > > > The links are named "A" through "F". > > > > I will use my own addresses for the example.. > > > > NLA1 is connected to VBNS prefix 3FFE:2800::/24, > > NLA1 address is 3FFE:2804::/32 > > > > NLA2 is connected to Sprint prefix 3FFE:2900::/24 > > NLA2 address is 3FFE:2901::/32 > > > > Now my site address from the VBNS side 3FFE:2804:1::/48 > > and from the Sprint side 3FFE:2901:1::/48 > > > > If I only select only one address say 3FFE:2901:1::/48, then as long as I > > have a route both ways through the Sprint network (TLA2) then I'll have > > connectivity. if link B, D or F goes down, I have a problem. My > > understanding of the 6bone routing policy is that no addresses with > > prefixes longer than /24 are allowed to be advertised in the default free > > zone. This means that even if I could get to the internet via VBNS > > (TLA1), routing policies preclude it. If there was a peering arrangement > > between TLA1 & TLA2 or between NLA1 & NLA2 , then if either E or F went > > down I might still have connectivity as the two sites may exchange BGP > > information. If however link A, B, C or D went down (which is more likely > > anyway), I have a problem unless NLA1 and NLA2 have a peering arrangement. > > Considering a worst case scenario where there are no peering arrangements > > whatsoever, a site multiply homed in this way would not work, mainly > > because of the default free zone rules that are currently in place. > > > > In my understanding this differs significantly from current practice in > > the IPv4 world as a multiply homed site would have to have a routing entry > > in the default free zone to work. > > > > I stress that this is not an IPv6 problem per se, but rather our > > application of current routing policy to IPv6. > > > > My suggestion for this problem is to relax the default free zone rules in > > a controlled manner. Under the quiescent state (all links up), the normal > > rules apply which would leave ethe default free zone small. If however a > > site is down, there may be a need for a site which is inaccessible from > > one TLA to punch through to the DFZ via another TLA. Is this planned > > routing practice, or is it forbidden? (or does BGP just work that way) > > > > So in summary, both methods of multihoming have their problems. For a > > multiply addressed site, there is the issue of selecting the best source > > address, and also the issue of preserving long running connections. For a > > singly addressed site, there may be problems getting connectivity if > > default free zone rules are adhered to. > > > > There is a side issue about source addressing which seems to have been a > > source of contention which I don't think has been particularly well > > defined at this point in time. For it to work properly, all hosts in the > > site must participate in a controlled manner. My opinion is that this is > > not something we can fix later, as it is a fundamental IPv6 stack issue. > > If we start deploying IPv6 stacks soon, we will have a problem as there > > will need to be a whole heap of upgrades when we've figured out how best > > it is to be done. It's not an issue that can be sidelined by letting the > > router working groups solve it later - it affects everybody. > > > > [ For me personally, multi homing is bad enough under current Ipv4 > > practices. We're a small ISP and we don't do it fully. We have multiple > > connections, but traffic flows out via static routes and quite > > arbitrarily. We certainly don't use multi addressing because communicating > > that to the hosts would be a nightmare. I am told internal BGP could > > solve our problem, but the routing table sizes make it prohibitive with > > the limited sized routers which we run. ] > > > > With larger ISP's I believe multi homing is essential to the quality of > > their service so if they were to switch to IPv6, they would have a need to > > do it and do it soon. > > > > Once we've worked all this out, perhaps we need to put together a multi > > homing how-to fact sheet so that this issue doesn't have to get thrashed > > out yet again. > > > > Does this explain things better? > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > --------------------------------------------------------------------- > > The IPv6 Deployment Mailing List > > Unsubscribe by sending "unsubscribe deployment" to majordomo@ipv6.org > > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 From hansolofalcon@worldnet.att.net Sat Apr 24 14:49:18 1999 From: hansolofalcon@worldnet.att.net (Gregg Levine) Date: Sat, 24 Apr 1999 09:49:18 -0400 Subject: Browsers that support IPv6 either as native or with a translator service active Message-ID: <01BE8E37.FF836820.hansolofalcon@worldnet.att.net> ------ =_NextPart_000_01BE8E37.FFBEEA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello from Gregg Levine usually at Jedi Knight Computers (This message is being cross posted to the 6Bone list at ISI, and the Microsoft Research Lists and the Deployment list for IPv6, so if you receive mail from all three as I do, then I apologize in advance.) And the question is: Does anyone know of a browser that supports IPv6, preferably as native, or even as with a translator service? I am aware of such a translator, it is for MS IE4.0x for Windows, but I which to study the behavior of others first. Also the stack, that I have chosen may not be compatible with the MS IE4.0x product. It isn't the one for WinNT, and Win2000, as I do not have access to a platform to do the actual installation, and developement there. Please feel free to contact me, either directly, or indirectly, I will accept complaints, and other statements of intent. Gregg C Levine mailto:hansolofalcon@worldnet.att.net This signature supports the Rebel Alliance to Restore the Republic "They were in the wrong place at the wrong time, naturally they became heroes." Princess Leia Organa of Alderaan, Senator "Remember, the Force will be with you, always." General Obi-Wan Kenobi, Jedi Knight (retired) ------ =_NextPart_000_01BE8E37.FFBEEA80 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhINAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAAAUAAAMAAAAQAAAAAwAAMAQAAAAL AA8OAAAAAAIB/w8BAAAAZQAAAAAAAAC1O8LALHcQGqG8CAArKlbCFQAAAO++p2H5YdIRhkBERVNU AAEkgQAAAAAAAIErH6S+oxAZnW4A3QEPVAIAAAEANmJvbmVAaXNpLmVkdQBTTVRQADZib25lQGlz aS5lZHUAAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMwAQAAAA4AAAA2Ym9uZUBpc2kuZWR1AAAA AwAVDAEAAAADAP4PBgAAAB4AATABAAAAEAAAACc2Ym9uZUBpc2kuZWR1JwACAQswAQAAABMAAABT TVRQOjZCT05FQElTSS5FRFUAAAMAADkAAAAACwBAOgEAAAAeAPZfAQAAAA4AAAA2Ym9uZUBpc2ku ZWR1AAAAAgH3XwEAAAAsAAAAvwAAALU7wsAsdxAaobwIACsqVsIVAAAA776nYflh0hGGQERFU1QA ASSBAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABBAAAAADAAAwBQAAAAsADw4AAAAA AgH/DwEAAAB+AAAAAAAAALU7wsAsdxAaobwIACsqVsIVAAAA776nYflh0hGGQERFU1QAAYSAAAAA AAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABNU1Jlc2VhcmNoAFNNVFAATVNSSVBWNi1VU0VSU0BMSVNU LlJFU0VBUkNILk1JQ1JPU09GVC5DT00AAAAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAKgAA AE1TUklQVjYtVVNFUlNATElTVC5SRVNFQVJDSC5NSUNST1NPRlQuQ09NAAAAAwAVDAEAAAADAP4P BgAAAB4AATABAAAADQAAACdNU1Jlc2VhcmNoJwAAAAACAQswAQAAAC8AAABTTVRQOk1TUklQVjYt VVNFUlNATElTVC5SRVNFQVJDSC5NSUNST1NPRlQuQ09NAAADAAA5AAAAAAsAQDoBAAAAHgD2XwEA AAALAAAATVNSZXNlYXJjaAAAAgH3XwEAAAAsAAAAvwAAALU7wsAsdxAaobwIACsqVsIVAAAA776n Yflh0hGGQERFU1QAAYSAAAADAP1fAQAAAAMA/18AAAAAAgH2DwEAAAAEAAAAAAAABRAAAAADAAAw BgAAAAsADw4BAAAAAgH/DwEAAABtAAAAAAAAALU7wsAsdxAaobwIACsqVsIVAAAA776nYflh0hGG QERFU1QAAQSWAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABEZXBsb3ltZW50IElQdjYAU01UUABk ZXBsb3ltZW50QGlwdjYub3JnAAAAAB4AAjABAAAABQAAAFNNVFAAAAAAHgADMAEAAAAUAAAAZGVw bG95bWVudEBpcHY2Lm9yZwADABUMAQAAAAMA/g8GAAAAHgABMAEAAAASAAAAJ0RlcGxveW1lbnQg SVB2NicAAAACAQswAQAAABkAAABTTVRQOkRFUExPWU1FTlRASVBWNi5PUkcAAAAAAwAAOQAAAAAL AEA6AAAAAB4A9l8BAAAAEAAAAERlcGxveW1lbnQgSVB2NgACAfdfAQAAACwAAAC/AAAAtTvCwCx3 EBqhvAgAKypWwhUAAADvvqdh+WHSEYZAREVTVAABBJYAAAMA/V8BAAAAAwD/XwAAAAACAfYPAQAA AAQAAAAAAAAG8wUBBIABAFAAAABCcm93c2VycyB0aGF0IHN1cHBvcnQgSVB2NiBlaXRoZXIgYXMg bmF0aXZlIG9yIHdpdGggYSB0cmFuc2xhdG9yIHNlcnZpY2UgYWN0aXZlAHsdAQWAAwAOAAAAzwcE ABgACQAxABIABgBEAQEggAMADgAAAM8HBAAYAAkAHQAFAAYAIwEBCYABACEAAABFOTRDOENEMTRC QjRBQTREQUVFRkU5NDBCMDJDN0EyQgCRBwEDkAYAhAcAACAAAAALAAIAAQAAAAsAIwAAAAAAAwAm AAAAAAALACkAAAAAAAMANgAAAAAAQAA5AOC+zj9Zjr4BHgBwAAEAAABQAAAAQnJvd3NlcnMgdGhh dCBzdXBwb3J0IElQdjYgZWl0aGVyIGFzIG5hdGl2ZSBvciB3aXRoIGEgdHJhbnNsYXRvciBzZXJ2 aWNlIGFjdGl2ZQACAXEAAQAAABYAAAABvo5ZPrH/LbZWxllI3qmHk0dJXbZoAAAeAB4MAQAAAAUA AABTTVRQAAAAAB4AHwwBAAAAHwAAAGhhbnNvbG9mYWxjb25Ad29ybGRuZXQuYXR0Lm5ldAAAAwAG EC136x8DAAcQzQMAAB4ACBABAAAAZQAAAEhFTExPRlJPTUdSRUdHTEVWSU5FVVNVQUxMWUFUSkVE SUtOSUdIVENPTVBVVEVSUyhUSElTTUVTU0FHRUlTQkVJTkdDUk9TU1BPU1RFRFRPVEhFNkJPTkVM SVNUQVRJU0ksQU4AAAAAAgEJEAEAAAAuBAAAKgQAAGgFAABMWkZ1fJ5cFwMACgByY3BnMTI1FjIA +Atgbg4QMDMzTwH3AqQDYwIAY2gKwHOwZXQwIAdtAoB9CoGSdgiQd2sLgGQ0DGAOYwBQCwMLtSBI ZWwlCQAgA1IgRwlwZ2cIIExlEsBuZSB1hHN1B0BseSBhBUAiSgmAaSBLAwBnaIUFQCAIUG1wdXQE kEZzCqIKgChUaAQAIDEHgXNhZxXQGJFiZdcLgBVgBQBvBBFwGfAXwEhkIHQUsHRoFdA2dkICIBXQ bAQABUAWcUm4U0ksFmATIBrDTQ3g3RnhbwGAB/AHkGUKwBDgTxVwG4EEIBxGRGULUG8/BsAJ8AVA G3MCEAXASVAcdjYcIB0QGTBmIHnVCGAgCXBjGYB2FdAAwH8DERTTFiEawQnRFmAEIEl4IGRvHCAa 0QOgIwBhYxowCQBnaXoZIQOgYUxkdgBwITAuKRgEQW0cVXEKUBpQaQIgGTE6PR7AbweRAHAg0BXB a26+bwfgHSAWYBlgA2B3ESDvBcAa0BZxFgBwGjAAICLh9SAjcAlwZgSQAaAWQgQg/m4WcCFRHCAF sRWQI4Ei0fcD8BrQKBF0KlAAgAtgGqBvBcAogRLAITA/I6IiEXf/CsAV0CfxFgAdwSxqHCAsIAcZ Mh/SBeFJRTQuMLp4H8NXExEoYRwgYhewPSLxdxiAHcEaoRpQdWR/FlAa0hlwEPASwAWxJ/FvFxrR ERAUwGkREHQuILxBbCBxGtIaUADQayNC/RvCIDORFdAQ4BnwI4EAwP8WUCewBUAZcBnAF4Eq8QJg /xXQLBMcgzCHKgAEcBNgNOHySS/ibicFQBrSGzIxFfxOVBwkMVEB0DygHCEi5P83czaDANAhMAQR GqEoIAtR/wAwBbAVABqhPUEa0gDQMuD/B0AkYTWhFJAq8QIgHCQBAHMhYAkAcGUfMzRCJQAg/lA4 cCLQO1EJ4CHCIqEaof8FoAIwP/EYsRwgGYA0QiMQ+zSwBZB0FkArQxMRRUcyIf8DEAMgPgIFMTfy C2IeIBwk/zQzNZIXwB8yBCAn8UgBH0HvNPAYBArzFRVDFXYhkhqgbjoQ8ACACPFmB0BEAUDydwWw bGQVwDTgFnA04O9NsRgEGHMAkGcq4QhwNYH/KSYa0h1gGXADIDUQG3Ak0v8akh1hLPFDsVBTF6AC YA3g1RgEIhhwZRZQd0JxJGL9GtJ3A2AZoQtRUUEWcVQofyZQRIJPQxYjGtEWUBlwY08t4BXQNFEm 8S4iSlVQHwUQJOEEERWABzAgT3K+ZwBwKCAn8TUQBIFhAHD/HCAGYCrhBbFS5R1gB4AG0PMEkCND IEYFsFFBRuM3wdcsEyDRHCFsLiB5WAEYBA5HCfAqQQMgT2JpLepXA5FLCfBvX4AcIBaq/igJcCZQ CXElJUppGAQSgQIAY3AAAAMAEBAAAAAAAwAREAAAAAADAIAQ/////0AABzCADslsVo6+AUAACDCA DslsVo6+AQsAAIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAAAwACgAggBgAAAAAAwAAAAAAA AEYAAAAAEIUAAAAAAAADAAWACCAGAAAAAADAAAAAAAAARgAAAABShQAA8xUAAB4AJYAIIAYAAAAA AMAAAAAAAABGAAAAAFSFAAABAAAABQAAADguMDQAAAAAAwAmgAggBgAAAAAAwAAAAAAAAEYAAAAA AYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAAAAMAMIAIIAYAAAAAAMAAAAAA AABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAAeAEGACCAGAAAA AADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgBCgAggBgAAAAAAwAAAAAAAAEYAAAAAN4UA AAEAAAABAAAAAAAAAB4AQ4AIIAYAAAAAAMAAAAAAAABGAAAAADiFAAABAAAAAQAAAAAAAAAeAD0A AQAAAAEAAAAAAAAAAwANNP03AABS1w== ------ =_NextPart_000_01BE8E37.FFBEEA80-- From rsofia@rccn.net Mon Apr 26 18:25:29 1999 From: rsofia@rccn.net (Rute Sofia) Date: Mon, 26 Apr 1999 18:25:29 +0100 (WET DST) Subject: IPv6 assignment and Allocation Policy Document Message-ID: I've read the IPv6 Assignment and Allocation Policy Document and think it is quite resonable now :-), at least for what concerns the initial deployment. However, I have some considerations: in point 4.2.2, "Criteria for sub-TLA Allocations in Transitional Bootstrap phase", point a. states that "the requesting organization's network...with at least three other public AS in the default-free zone". What is meant by "default-free zone"? I also think that it is of major importance in IPv6 to have section 6., DNS and Reverse Address Mapping in the initial deployment document. There is also the question of the now pseudo-TLA: even though I suppose that most of us are under the conditions of point 4.2.1, nothing is said about pseudo-TLA. Do we have to request for a sub-TLA again? Or what will be needed is only to renumber? Thanks, Rute Sofia From mitra@ukr.net Mon Apr 26 20:52:47 1999 From: mitra@ukr.net (Alexei Akimov) Date: Mon, 26 Apr 1999 22:52:47 +0300 (EEST) Subject: cisco IPv6 Message-ID: <199904261952.WAA11392@wind.ukr.net> Hi dear 6bone community! I would like to install IPv6 on my Cisco 3620 router. What IOS shall I need? Would anyone be so kind to share his expirience in setup? -- Wishing all the best, Alexei Akimov AA914-RIPE Best Known As M1tRA E-Mail: mitra@ukr.net ICQ: 2655858 +380 (44) 235-85-55 UkrNet Ltd., Kiev From fink@es.net Mon Apr 26 20:57:32 1999 From: fink@es.net (Bob Fink) Date: Mon, 26 Apr 1999 12:57:32 -0700 Subject: cisco IPv6 In-Reply-To: <199904261952.WAA11392@wind.ukr.net> Message-ID: <4.1.19990426125602.00abc780@imap2.es.net> At 10:52 PM 4/26/99 +0300, Alexei Akimov wrote: >Hi dear 6bone community! > >I would like to install IPv6 on my Cisco 3620 router. >What IOS shall I need? Would anyone be so kind to share his >expirience in setup? To start with you need the cisco betga ios for v6 that's at: but you will need the Cisco CCO loging and passwd for your Cisco support account. Bob From ksbn@kt.co.kr Tue Apr 27 03:30:41 1999 From: ksbn@kt.co.kr (ksb) Date: Tue, 27 Apr 1999 11:30:41 +0900 Subject: cisco IPv6 References: <4.1.19990426125602.00abc780@imap2.es.net> Message-ID: <37252151.96ECF948@kt.co.kr> Dear Bob Rink, I tried with CCO login account, password to get beta-IOS for IPv6. But the screen of my workstation required a Access Code. I asked the Access Code to cisco korea company. But they didn't know. Will you give me any information to get the Access Code to get any IPv6 IOS. Thank you. Bob Fink wrote: > At 10:52 PM 4/26/99 +0300, Alexei Akimov wrote: > >Hi dear 6bone community! > > > >I would like to install IPv6 on my Cisco 3620 router. > >What IOS shall I need? Would anyone be so kind to share his > >expirience in setup? > > To start with you need the cisco betga ios for v6 that's at: > > > > but you will need the Cisco CCO loging and passwd for your Cisco support account. > > Bob -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- From kato@wide.ad.jp Tue Apr 27 03:56:55 1999 From: kato@wide.ad.jp (Akira Kato) Date: Tue, 27 Apr 1999 11:56:55 +0900 Subject: cisco IPv6 In-Reply-To: Your message of "Tue, 27 Apr 1999 11:30:41 +0900" <37252151.96ECF948@kt.co.kr> References: <37252151.96ECF948@kt.co.kr> Message-ID: <19990427115655Y.kato@nezu.wide.ad.jp> Dear Kim: The CCO account may not be issued to cisco customers not in U.S. I am afraid you may have the same situation in Korea. I suggest you to contact with Cisco Korea if any or with your cisco resaller to obtain information about IPv6-capable IOS. In Japan, Nihon-Cisco offers it to Japanese cisco customers who satisfy some technical criteria. -- Akira Kato, WIDE Project From Ronald.vanderPol@surfnet.nl Tue Apr 27 10:08:03 1999 From: Ronald.vanderPol@surfnet.nl (Ronald van der Pol RVDP) Date: Tue, 27 Apr 1999 11:08:03 +0200 (CEST) Subject: 100th IPv6 tunnel! In-Reply-To: <4.1.19990423173428.03855ee0@mail.viagenie.qc.ca> Message-ID: On Fri, 23 Apr 1999, Marc Blanchet wrote: > Hi, > On our IPv6 tunnel server (http://www.freenet6.net), we just hit today the > 100th client getting a (free) IPv6 tunnel! > > Well, this is one kind of progress for IPv6 deployment: We didn't > advertise our IPv6 tunnel server up to now, and have that much of tunnels. Congratulations! I thought your idea was to setup more tunnel servers in various countries. Is that still your intended setup? If so, is your server software available for downloading? We would like to setup a IPv6 tunnel service. rvdp From Ivano.Guardini@CSELT.IT Tue Apr 27 12:31:46 1999 From: Ivano.Guardini@CSELT.IT (Guardini Ivano) Date: Tue, 27 Apr 1999 13:31:46 +0200 Subject: 100th IPv6 tunnel! Message-ID: <9187FF572943D211B28100805FC130FC0E03D2@xrr1.cselt.stet.it> Hi Ronald, another IPv6 Tunnel Broker server is available here at CSELT (https://carmen.cselt.it/ipv6tb) and our software is available for downloading at the following URL: http://carmen.cselt.it/ipv6/download.html More information about our implementation of the Tunnel Broker idea can be found in draft-ietf-ngtrans-broker-00.txt. Bye Ivano > ---------- > From: Ronald van der Pol RVDP[SMTP:Ronald.vanderPol@surfnet.nl] > Sent: Tuesday, April 27, 1999 11:08 AM > To: Marc Blanchet > Cc: deployment@ipv6.org; ngtrans@sunroof.eng.sun.com; users@ipv6.org; > 6bone@isi.edu; support@freenet6.net > Subject: Re: 100th IPv6 tunnel! > > On Fri, 23 Apr 1999, Marc Blanchet wrote: > > > Hi, > > On our IPv6 tunnel server (http://www.freenet6.net), we just hit > today the > > 100th client getting a (free) IPv6 tunnel! > > > > Well, this is one kind of progress for IPv6 deployment: We didn't > > advertise our IPv6 tunnel server up to now, and have that much of > tunnels. > > Congratulations! I thought your idea was to setup more tunnel servers > in various countries. Is that still your intended setup? If so, is your > server software available for downloading? We would like to setup a > IPv6 tunnel service. > > rvdp > > > --------------------------------------------------------------------- > The IPv6 Deployment Mailing List > Unsubscribe by sending "unsubscribe deployment" to majordomo@ipv6.org > From cnguyen@triton-network.com Tue Apr 27 13:07:58 1999 From: cnguyen@triton-network.com (Cung Nguyen) Date: Tue, 27 Apr 1999 08:07:58 -0400 Subject: cisco IPv6 Message-ID: <60731098BE78D211B37700A0C9899A802B6FB8@triton.triton-network.com> Alexei, Try http://www.freenet6.net and it has a link to cisco site where you can get the ios... Does one need the CCO account number to get the IPV6 IOS though ? Does any know ? Thanks ================= Cung Nguyen Triton Network Systems Inc. 407.903.2052 or cnguyen@triton-network.com > -----Original Message----- > From: Alexei Akimov [SMTP:mitra@ukr.net] > Sent: Monday, April 26, 1999 3:53 PM > To: 6bone@ISI.EDU > Subject: cisco IPv6 > > Hi dear 6bone community! > > I would like to install IPv6 on my Cisco 3620 router. > What IOS shall I need? Would anyone be so kind to share his > expirience in setup? > > -- > Wishing all the best, > Alexei Akimov AA914-RIPE Best Known > As M1tRA > E-Mail: mitra@ukr.net ICQ: 2655858 +380 (44) 235-85-55 UkrNet > Ltd., Kiev From fink@es.net Tue Apr 27 14:34:12 1999 From: fink@es.net (Bob Fink) Date: Tue, 27 Apr 1999 06:34:12 -0700 Subject: cisco IPv6 In-Reply-To: <199904271003.HAA21573@Snoopy.UCIS.Dal.Ca> References: <4.1.19990426125602.00abc780@imap2.es.net> <199904261952.WAA11392@wind.ukr.net> Message-ID: <4.1.19990427063255.0096acc0@imap2.es.net> John, At 07:03 AM 4/27/99 -0300, John Sherwood wrote: >> >I would like to install IPv6 on my Cisco 3620 router. >> >What IOS shall I need? Would anyone be so kind to share his >> >expirience in setup? >> >> To start with you need the cisco betga ios for v6 that's at: >> >> >> >> but you will need the Cisco CCO loging and passwd for your Cisco support >account. > >Bob: > >Looks like you now need more than just your CCO login. There used to be a >page at >http://www.cisco.com/warp/customer/732/ipv6/download.html that would let >you get at the IOS, but it no longer works. The page you gave us needs >an Access Code with no indication of how you are supposed to get one. You are right. They just told me that it's ok to use the code 'galing' to get to it. I'll see if they mind if I also put it on the web page. Thanks, Bob From mitra@ukr.net Tue Apr 27 15:27:51 1999 From: mitra@ukr.net (Alexei Akimov) Date: Tue, 27 Apr 1999 17:27:51 +0300 (EEST) Subject: IPv6 on Cisco Routers Message-ID: <199904271427.RAA28644@wind.ukr.net> Hi! I walked through www.cisco.com using my CCO account and found a link to download the IOS with IPv6 support, but I was asked for the 'Access Code'. Where can I obtain one? -- Wishing all the best, Alexei Akimov AA914-RIPE Best Known As M1tRA E-Mail: mitra@ukr.net ICQ: 2655858 +380 (44) 235-85-55 UkrNet Ltd., Kiev From k-logic@sins.net Tue Apr 27 13:28:15 1999 From: k-logic@sins.net (kalvin k. lined) Date: Tue, 27 Apr 1999 12:28:15 +0000 (GMT) Subject: cisco IPv6 In-Reply-To: <60731098BE78D211B37700A0C9899A802B6FB8@triton.triton-network.com> Message-ID: I would contact Cisco. I have found that they appricate beta testers. On Tue, 27 Apr 1999, Cung Nguyen wrote: > Alexei, > > Try http://www.freenet6.net and it has a link to cisco site where you > can get the ios... > > Does one need the CCO account number to get the IPV6 IOS though ? Does > any know ? > > Thanks > > ================= > Cung Nguyen > Triton Network Systems Inc. > 407.903.2052 or cnguyen@triton-network.com > > > > -----Original Message----- > > From: Alexei Akimov [SMTP:mitra@ukr.net] > > Sent: Monday, April 26, 1999 3:53 PM > > To: 6bone@ISI.EDU > > Subject: cisco IPv6 > > > > Hi dear 6bone community! > > > > I would like to install IPv6 on my Cisco 3620 router. > > What IOS shall I need? Would anyone be so kind to share his > > expirience in setup? > > > > -- > > Wishing all the best, > > Alexei Akimov AA914-RIPE Best Known > > As M1tRA > > E-Mail: mitra@ukr.net ICQ: 2655858 +380 (44) 235-85-55 UkrNet > > Ltd., Kiev > k-logic / http://todiefor.com / k-logic@todiefor.com "For a good time ping 206.152.181.28." From Marc.Blanchet@viagenie.qc.ca Tue Apr 27 20:03:33 1999 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Tue, 27 Apr 1999 15:03:33 -0400 Subject: (ngtrans) Re: 100th IPv6 tunnel! In-Reply-To: References: <4.1.19990423173428.03855ee0@mail.viagenie.qc.ca> Message-ID: <4.1.19990427134728.0352d780@mail.viagenie.qc.ca> At 11:08 99-04-27 +0200, Ronald van der Pol RVDP wrote: >On Fri, 23 Apr 1999, Marc Blanchet wrote: > >> Hi, >> On our IPv6 tunnel server (http://www.freenet6.net), we just hit today the >> 100th client getting a (free) IPv6 tunnel! >> >> Well, this is one kind of progress for IPv6 deployment: We didn't >> advertise our IPv6 tunnel server up to now, and have that much of tunnels. > >Congratulations! I thought your idea was to setup more tunnel servers >in various countries. Is that still your intended setup? well. the first person who developed that concept is Alain Durand. In his concept, a tunnel broker receive requests from users and tunnels servers actually do the tunnels. This model has been coded by Ivano and his friends. You probably see his offer for his source code. go get it! What we implemented is more simpler: the same server is receiving the requests from the users and make the tunnels to the clients. We got request from many people to have our source code to setup servers in the world. We have been very busy since Minneapolis but it is on our priority to release the software. in the mean time, we just add new client platforms and linux client is going to be released soon. So if you are interested in our "simpler" implementation, drop me an email and I'll make sure you receive it when it is released. Regards, Marc. >If so, is your >server software available for downloading? We would like to setup a >IPv6 tunnel service. > > rvdp > ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ From kazu@iijlab.net Wed Apr 28 06:11:42 1999 From: kazu@iijlab.net (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 28 Apr 1999 14:11:42 +0900 Subject: Meeting with JPNIC Message-ID: <19990428141142Z.kazu@iijlab.net> Folks, Some members of WIDE Project and JPNIC guys had a meeting on 23 April. The following topics were discussed. (1) 6bone Prequalification for Sub-TLA assignment (Bob Fink) (2) Proposed change in 6bone pTLA 3FFE usage (Bob Fink) (3) IPv6 Assignment and Allocation Policy Document 16/04/99 (RIR) No particular objections arose against (1) and (2), so we agree to Bob's proposals. And we have some comments to RTR's draft. (a) Section 3.2 says, "It is recommended that site-local addresses be used for all point-to-point links,". RTRs should not encourage the usage of site-local addresses. For point-to-point links, link-local addresses are sufficient. For particular proposes, global addresses should be used. (Please don't encourage Number 10 stuff.) (b) The word "BGP" is occasionally used in this draft. We feel that the definition of this word is not clear. BGP consists of transport (ie. peering) and contents (routing info). We can't understand whether or not IPv6 is required for both transport and contents. (Note IPv6 routing information can be exchanged over BGP/TCP/IPv4 peerings.) Moreover, we think particular protocols should not be specified. More abstract word such as "exterior routing protocol" should be used. (c) /35 doesn't align to the nibble boundary. So, we would like to have considerations to DNS reverse lookups in Section 6. :-) --Kazu From pfs@cisco.com Thu Apr 29 01:55:39 1999 From: pfs@cisco.com (Philip Smith) Date: Thu, 29 Apr 1999 10:55:39 +1000 Subject: IPv6 assignment and Allocation Policy Document In-Reply-To: Message-ID: <4.1.19990429104114.00a55590@lint.cisco.com> At 18:25 26/04/99 +0100, Rute Sofia wrote: > >I've read the IPv6 Assignment and Allocation Policy Document and think >it is quite resonable now :-), at least for what concerns the initial >deployment. However, I have some considerations: > >in point 4.2.2, "Criteria for sub-TLA Allocations in Transitional >Bootstrap phase", point a. states that "the requesting organization's >network...with at least three other public AS in the default-free zone". > >What is meant by "default-free zone"? "The default free zone is made up of Internet routers which have explicit routing information about the rest of the Internet, and therefore do not need to use a default route." So my understanding of 4.2.2(a) is that the requesting organisation would be one which is receiving the full Internet routing table separately from 3 neighbouring ASes, and is therefore able to use that routing table to make intelligent decisions about where to send IP packets. philip -- >I also think that it is of major importance in IPv6 to have section 6., >DNS and Reverse Address Mapping in the initial deployment document. > >There is also the question of the now pseudo-TLA: even though I suppose >that most of us are under the conditions of point 4.2.1, nothing is said >about pseudo-TLA. Do we have to request for a sub-TLA again? Or what >will be needed is only to renumber? > > Thanks, > Rute Sofia > From lambert@psc.edu Fri Apr 30 20:52:32 1999 From: lambert@psc.edu (Michael H. Lambert) Date: Fri, 30 Apr 1999 15:52:32 -0400 (EDT) Subject: new RIR IPv6 Assignment and Allocation Policy draft (16Apr99) In-Reply-To: <4.1.19990420175742.00a2bbf0@imap2.es.net> Message-ID: I do not wish to discuss the merits of a /35 slow-start allocation. I would like to suggest that an initial /35 allocation could cause undue hardship to sites already on the 6bone. As an example, Abilene (a backbone network for the Internet2 project) has an addressing scheme which was developed with RFC2450 in mind. It assumes a /29 sTLA (or a /29 pTLA from the 6bone) and uses a 19-bit NLA field. The NLA field is subdivided; the high-order subfield is allocated using the left-to-right procedure described in Marc Blanchet's Internet Draft. Thus, migrating from a /29 pTLA to a /35 sTLA would require us to reengineer our addressing. I propose the following: Provided that it meets the requirements for sTLA allocation, an entity which has a 6bone pTLA allocation at the time of the adoption of the RIR allocation rules will be allocated a /29 sTLA rather than a /35 sTLA. Fewer than 60 pTLAs have been allocated. Doubtless not all of these would qualify for sTLAs. Thus the impact of allocating them /29s should be minimal. Michael +----------------------------------------------------------------------------+ | Michael H. Lambert, Network Engineer Phone: +1 412 268-4960 | | Pittsburgh Supercomputing Center FAX: +1 412 268-8200 | | 4400 Fifth Avenue, Pittsburgh, PA 15213 lambert@psc.edu | +----------------------------------------------------------------------------+