From kanda@nn.iij4u.or.jp Tue Jan 1 13:43:42 2002 From: kanda@nn.iij4u.or.jp (KANDA Mitsuru / =?ISO-2022-JP?B?GyRCP0BFRBsoQiAbJEI9PBsoQg==?=) Date: Tue, 01 Jan 2002 22:43:42 +0900 Subject: USAGI stable release Message-ID: A Happy New Year! We are glad that we can announce the 3rd STABLE RELEASE of USAGI (UniverSAl playGround for Ipv6)[1] product on January 1st, 2002. On this release, we provide ipv6 enhanced kernel (based on linux-2.2.20 and/or linux-2.4.13) and basic IPv6 libraries and applications. The improved features are listed below. - ICMPv6 Node Information Queries - Privacy Extensions (RFC 3041)(kernel-2.4 only) - IPv6 khttpd - Better source address selection - Per-device statistics for SNMP - IPv4/IPv6 socket binding on the same port - Dropping IPv6 packets with malicious address(es) - Enabling default route when IPv6 forwarding is enabled - Improving SO_REUSEADDR behavior - Fixing bugs in NDP(Neighbor Discovery Protocol) - Fixing bugs in Stateless Address Auto-configuration - Catching up and implementing RFC2553 / RFC2553bis APIs including IPV6_V6ONLY socket option - Catching up and implementing RFC2292 / RFC2292bis APIs - Making many basic applications IPv6 ready. You can get our source codes from the following URL. We also provide our code in the form divided into the patch against the main-line kernel and the tool. We plan to provide the binary packages for some distributions. They will appear under within several weeks. We announce latest information via web. Please check our web site . We also manage the mailing list for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit for further information. Thanks. About USAGI Project: The USAGI Project is managed by volunteers and aims to provide better IPv6 environment on Linux freely. We are tightly collaborating with WIDE Project[2], KAME Project[3] and TAHI Project[4], and trying improving Linux kernel, IPv6 related libraries and IPv6 applications. Our products are released every two weeks and stable release several times a year. Please check our web site for the latest detailed information. References: [1] USAGI Project [2] WIDE Project [3] KAME Project [4] TAHI Project -- USAGI Project From fink@es.net Wed Jan 2 16:42:11 2002 From: fink@es.net (Bob Fink) Date: Wed, 02 Jan 2002 08:42:11 -0800 Subject: 6bone pTLA 3FFE:8310::/28 allocated to MICROSOFT Message-ID: <5.1.0.14.0.20020102083509.00acf720@imap2.es.net> MICROSOFT has been allocated pTLA 3FFE:8310::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to either bmanning@isi.edu or hostmaster@ep.net.] Thanks, Bob From fink@es.net Wed Jan 2 17:02:28 2002 From: fink@es.net (Bob Fink) Date: Wed, 02 Jan 2002 09:02:28 -0800 Subject: 2nd draft minutes of NGtrans WG meeting, Salt Lake City, IETF-52 Message-ID: <5.1.0.14.0.20020102084640.00acf720@imap2.es.net> NGtrans Folk, Here is the 2nd version of the draft minutes of the ngtrans meeting in Salt Lake City. Please send comments and corrections to me or the list by Friday so I can submit the final minutes to the secretariat. Thanks, Bob ============================= Minutes of NGtrans WG Meeting 13-14 December 2001 London IETF-51 ======= Chairs: Alain Durand Bob Fink Tony Hain Alain Durand and Tony Hain chaired the meeting. Bob Fink took the minutes. Attendance was just over 150. =========================== Administrative information: Discussion ngtrans: Subscribe ngtrans: "subscribe ngtrans" Archive ngtrans: Web site: Discussion 6bone: Subscribe 6bone: "subscribe 6bone" Archive 6bone: Web site: ====== Agenda --- Thursday, 13 December, 1530-1730 - Agenda Bashing, Chairs - 2 minutes WG Status, Bob Fink - 3 minutes Survey of IPv4 Addresses in Currently Deployed IETF Standards, Phil Nesser 15-30 mins NGtrans IPv6 DNS operational requirements and roadmap, Alain Durand - 15 mins Plans for transition from ip6.int to ip6.arpa - Alain Durand 5 mins IPv6 SMTP operational requirements, Itojun - 15 mins Connecting IPv6 Islands across IPv4 Clouds with BGP, Dirk Oooms - 5-10 mins Dual Stack Transition Mechanism (DSTM), Laurent Toutain - 5 mins Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), Fred Templin - 5 mins An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp), Kazuaki Tsuchiya 5 mins Dual Stack Hosts using "Bump-in-the-API" (BIA). Myung-Ki Shin 2 mins Application Aspects of IPv6 Transition, Myung-Ki Shin 5 mins Dual Stack deployment using DSTM and neighbour discovery, Gerard Gastaud 5 mins Multicast extensions to dual stack hosts using the "Bump-In-the-Stack" Technique (mBIS), Kazuaki Tsuchiya 5 mins IPv6 Traffic Engineering Tunnel, Hiroki Ishibashi - 5 mins (if time permits) --- Friday, December 14 at 0900-1000 - Discussion of new ngtrans charter and future ngtrans work - chairs, 1 hour ================================ Thursday, 13 December, 1530-1730 Agenda bashing There were no changes to the agenda listed above === NGtrans Project Status - Bob Fink SLIDES: Bob presented the current status of NGtrans projects (see slides above). For current status of projects, look at: Bob noted that there were numerous drafts either expired in the ID directory and/or in an unknown state (i.e., not progressing), and that in the context of reevaluating the directions of ngtrans authors can expect to be contacted by the chairs to determine the future of these projects. === Survey of IPv4 Addresses in Currently Deployed IETF Standards, Phil Nesser SLIDES: Phil presented a history and overview of his IPv4survey work • Work Started in late 1999 ­ First draft (-00) in May 2000 ­ Second (current) draft (-01) in August 2001 • Goal of the project is to review all of the current IETF Standards for IPv4 assumptions to make sure a transition to IPv6 as smooth as possible There are: • Full Standards (68 RFCS) • Draft Standards (65 RFCS) • Proposed Standards (611 RFCS) • Experimental (150 RFCS) • Most of the work has been done as an individual effort ­ Reading Each of the 894 RFCS ­ About 25,000 pages of text • PLEASE LOOK AT THE DRAFT FOR ANY RFCS THAT YOU HAVE KNOWLEDGE OF AND COMMENT Current Results: • The ­01 draft was concerned with finding RFCS with problems ­ Full Standards: 26 RFCS (38.25%) ­ Draft Standards: 19 RFCS (29.23%) ­ Proposed Standards: 112 RFCS (18.33%) ­ Experimental: 23 RFCS (15.33%) ­ Total: 180 RFCS (20.13%) • Each RFC was examined independently of all others • Technique purposely chosen to give more false positives rather than accidentally missing something • Helped reduce the scope of the individual investigation • In the middle of reviewing the RFCS that came up positive in the first pass to see what problems are already fixed in later RFCS • It is clear that many issues are already resolved, are in work, or can be fixed by registering a parameter with the IANA Next Steps: • Finish review of RFCS identified in the first pass to finalize a list of problem child RFCS that need some updates • At the request of the IETF chair the project should also include a discussion of protocols that assume the long term stability of addresses • Produce an ­02 draft that summarizes the final results of the review later this month or early next month • Produce a series of recommendations for any RFCS that still have problems and include a discussion on the long term stability of address in an ­03 draft in early 2002 • Go to Last Call after the ­03 draft is published How You Can Help: • READ THE DRAFT AND COMMENT • Think about the long term stability of addresses issue and provide input • READ THE DRAFT AND COMMENT • … and in case it isn't clear, READ THE DRAFT AND COMMENT ­ It's 120 pages of gripping narrative, enjoy! Francis Dupont asked if IPv6 over FDDI was fixed; did Phil get the comment. Phil did. Phil has a big problem trying to understand what protocols assume long term address stability. Keith Moore felt that there is an unreasonable expectation that there is not a long term address stability requirement, thus this should be discussed at another place as a major architectural issue as he believes there is often a requirement for long term address stability. Phil noted this and pointed out that his context is just to note the occurrence of these. Phil said that by early 2002 he will have a -03 with recommendation for RFCs that have a problem. Then the draft can go to last call. Brian Carpenter congratulated Phil on his efforts, and noted that this is a real list of changes we need to make to real software. He also asked that everyone read and comment on the draft. Keith Moore noted that the normal editing cycle may not be best place to handle this process, and that maybe putting up a web page would help. It was also noted that the ID editor might be able to help on this. === NGtrans IPv6 DNS operational requirements and roadmap, Alain Durand SLIDES: Alain presented the current status of plans to provide for successful operation of the DNS in a mixed environment of IPv4-only, IPv6-only and dual-stacks networks. • 2 approaches ­ Let DNS break if it has to break ­ Make sure DNS works. • Requirement document made by NGtrans, was presented in DNSext and DNSop. • If the requirements are accepted, some work needs to be done in DNSext. Architectural principles: • The public DNS has a unique root valid for IPv4 & IPv6 (derived from RFC2826). • DNS is an IP version agnostic application. ­ Any node (v4, v6, dual stack) should be able to query any record in any zone ­ Queries should get the same answers regardless of the IP version used during the process. (Note: this does not apply to additional sections) • The burden has to be placed on new IPv6 systems Consequences: • A bridging system is needed • Bridging does not need to be symmetric • Any change to the existing IPv4 resolvers is out of scope. • Bridging v4 to v6 is technically very difficult. However, It can be achieved by administrative procedures: ­ Mandate at least one v4 server per zone ­ Can be achieved by contracted 3rd party dual stack servers • Bridging v6 to v4 requires something new. Bridging requirements: (v4 to v6 or v6 to v4) • Any change to existing IPv4 resolvers is out of scope. • The bridging system is required to have good scaling properties. • The bridging system discovery is required to have good scaling properties. • All zones should be reachable through the bridging system. • Security is not an option in the IETF, that is it is mandatory. DNSext comments/questions: • Designing such a bridging system is not easy, may be a huge kludge. • Draft-durand-dns-proxy-00.txt is an attempt at a possible solution. • There might be other solutions. • DNSext should be the place to design it. Steve Deering asked if truncation of packets was an issue for getting the same answer in either transport. It was noted that this is not a problem, that just the main answer needs to be the same, not the packet size. There were concerns expressed of bridging system scalability and complexity. Steve Deering asked that if DNS was to be IP agnostic, what is an IPv6 zone. Alain noted that this meant a DNS zone available only over IPv6 transport. Keith Moore asked why not an approach with no scaling problems, like every site having a resolver. Perry Metzger noted that one could modify BIND to solve this. Alain will continue with these efforts, with a strong focus on DNS folks who know what the issues are being involved in the solution. === Plans for transition from ip6.int to ip6.arpa - Alain Durand 5 mins SLIDES: none Alain spoke briefly on planning now underway for a transition from ip6.int to ip6.arpa. He noted that how to make delegations were a registry problem, not ours. The harder problem is that there are lots of existing stub resolvers hardwired to ip6.int. There are a few folk now working on problem with two solutions under study. Experiments with the approaches, and drafts describing the approaches are soon to come, so stay tuned. === IPv6 SMTP operational requirements, Itojun & Alain Durand - 15 mins SLIDES: full content is included below Itojun presented the history of development of his ipvt smtp requirements draft: 03 draft completed WG last call for informational Area director suggested a review by SMTP-related mailing lists 04 draft submitted to reflect comments another comment received (not sure if it was for 03 or 04) WG chair (alain) suggested changes in direction so this time slot Outline of draft: Operational requirements for IPv6 SMTP, and IPv6 DNS MX records Goal: stable email transport in IPv6/v4 dual stack world Similar content presented by Kazu, at IETFxx Outgoing: be careful looking up all MX/A/AAAAs Incoming: configure MX right, be sure to keep reachability among servers Widely practiced by existing IPv6-ready MTAs because it is a natural extension to IPv4 SMTP behavior IPv6 MX lookup (outgoing) Same, but a bit more complicated email to foo@example.org Lookup example.org MX - use it, based on preference (then A/AAAA) A/AAAA - use it CNAME - resolve till get to MX/A/AAAA Be sure to try all available As and AAAAs SMTP failure handling (4xx or 5xx) complicates the story example.org. IN MX 1 mx1.example.org. IN MX 10 mx10.example.org. mx1.example.org. IN A 1.0.0.1 ; IPv4/v6 dual stack IN AAAA 3ffe:501:ffff::1 mx10.example.org. IN AAAA 3ffe:501:ffff::2 ; IPv6 only MX for dual stack sites (incoming) Be sure to allow emails to get delivered to the final email server If possible, make the most preferred MX a dual stack node ; easy and good config easy.com. IN MX 1 v4only.easy.com. easy.com. IN MX 10 dualstack.easy.com. ; good config good.com. IN MX 1 dualstack.good.com. good.com. IN MX 10 v4only.good.com. ; bad config bad.com. IN MX 1 v4only.bad.com. bad.com. IN MX 10 v6only.bad.com. Outgoing from IPv6-only site to IPv4-only site? THIS PART IS NOT IN THE DRAFT. Just like last-resort relay rule for bitnet in sendmail.cf, this is outside of the protocol document Make the server dual-stack Use dualstack SMTP relay server in ISP Purchase translation service from ISP # sendmail.cf # Smart relay host DSdualstackrelay.isp.com MX for IPv4/v6-only sites? (incoming) THIS PART IS NOT IN THE DRAFT. Not a protocol issue Make the server dual-stack Purchase SMTP relaying service from ISP Purchase translation service from ISP ; rely upon ISP relay v6only.com. IN MX 1 mail.v6only.com. v6only.com. IN MX 10 dualstackrelay.isp.com. %center, newimage -yscrzoom 40 "relayconfig.eps" Itojun then outlined his discussions issues How can I go forward with the document? How far do we want to document? How to document? updates to RFC2821 only, wrt IPv4/v6 address manipulation some more details on MX setups <--- current much more detail in operation SMTP servers setup, interactions with translators, etc Alain said that he was concerned about the title which is at odds with a goal of stable transport in dual stack world, thus he suggested to change title to only be specific to Itojun's draft goals, then start work on greater issue of entire transition of SMTP. Keith Moore recommended that work be done elsewhere, i.e., in mail community, as there is lots of subtlety in correct handling of SMTP *failure* conditions, thus needs to be done by experts (probably in the apps area). Christian Huitema felt that Keith was right, that the draft is fine but only looks at one problem. He noted that smtp is not the only app that has these problems. Keith Moore emphasized that he wants to get IETF people outside of ngtrans involved, and this is good motivation for that. Alain will work with Itojun on the renaming and how to proceed with other work in the SMTP community. === Connecting IPv6 Islands across IPv4 Clouds with BGP, Dirk Oooms SLIDES: Dirk noted that there were two interpretations of the previous draft: • MP-BGP/TCP/IPv4 ­ includes implicit automatic tunnelling method ­ MP-BGP advertises an IPv4 BGP next hop (encoded as IPv4-mapped IPv6 address) ­ IPv6 data encapsulated in IPv4, MPLS, ... • MP-BGP/TCP/IPv6 ­ uses existing ngtrans method ­ MP-BGP advertises an IPv6 BGP next hop (address matches the used ngtrans mechanism) ­ IPv6 data encapsulated in IPv4 (and if desired subsequently in e.g. MPLS) The new draft has been changed to explain the two approaches explicitly. The applicability is: • ISP familiar with BGP (and possibly already offering VPN services) that wants to offer native IPv6 services without wanting to upgrade its backbone • ISP only needs to upgrade (some of) its PE routers What's next?: • Applicability statement will be added • Earlier it was agreed to go for informational: - Most of it is informational - But address encoding in "IPv4 BGP next hop" approach needs to be standardized to assure interoperability => move to standards track • Ready for last call after update? Tony said we cannot decide here about the possibility of changing to standards track, so this will be taken offline. === Dual Stack Transition Mechanism (DSTM), Laurent Toutain SLIDES: Major Change • Annex lists some ways to configure interfaces: - Manual, RPCv6, DHCPv6 - Allow 3G to specify its own protocol ? • Don't mandate an address allocation mechanism - One document describing DSTM - Several documents to define address allocation and mapping. - Common to other ngtrans protocols (SIIT, Tunnel Broker) • Issue ASAP new drafts and be ready for last call Alain note that he needs to see how the new separated drafts look to decide how to progress draft, and that he was pleased with this new direction. === Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), Fred Templin SLIDES: Fred reported on ISATAP Status • draft-ietf-ngtrans-isatap-02.txt published • "ISATAP Issues" message posted to mailing list • Linux ISATAP implementation announced. HOWTO at: v6web.litech.org/isatap/ Experimentation encouraged! (Thanks Nathan Lutchansky and Yoshifuji Hideaki!) IPv4 anycast vs. DNS w/multiple RR's ­ Author prefers anycast: • IPv4 anycast is a *configuration option*; NOT a feature of IPv4 addressing i.e. ANY topologically-correct IPv4 prefix can be used for IPv4 anycast use within the site: - allocate IANA prefix/use existing IANA prefix for easy configuration (vote?) - Site administrators can override with DNS entry (single RR); static config if desired IPv4 Anycast vs. DNS • v4anycast allows hosts to operate exactly as RFC 2461, section 6.3: - Default router *lists* constructed - Redirects; other ND features work as per 2461 • v4anycast provides easy security check (i.e. only accept RAs from v4anycast) Router solicitation w/Anycast • ISATAP host sends RS with: v6_src=FE80::0:5EFE:V4ADDR_HOST v6_dst=FF02::2 v4_src=V4ADDR_HOST v4_dst=V4ANYCAST • ISATAP Router sends RA with: v6_src=FE80::0:5EFE:V4ADDR_RTR <= works w/2461 v6_dst=FE80::0:5EFE:V4ADDR_HOST v4_src=V4ADDR_ISATAP (note: corrected per F. Dupont) v4_dst=V4ADDR_HOST Router solicitation interval • RFC 2461, section 6.3.7 gives list of acceptable reasons for hosts to re-issue RSs. One says: "- the host re-attaches to a link after being detached for SOME TIME" Author's recommendation for ISATAP: • Host deems itself to be detached from the ISATAP interface immediately after receiving solicited RA (i.e. expects to NOT receive unsolicited RA's) • Host sets "SOME TIME" == Router Lifetime/2, for some Router Lifetime in default router list. • Is RFC 2461 language needed? Suggestion, "A link should NOT deem itself to be detached arbitrarily; only if it KNOWS it cannot receive unsolicited RAs" Security • Source address spoofing for ISATAP peers: If v4_src != embedded V4ADDR in v6_src … • Source address spoofing for forwarded messages: If v4_src != embedded V4ADDR in reverse routing lookup for v6_src … • Reverse routing lookup trust based on v4_src=v4anycast in RAs Open Issues Since London • When to deprecate ISATAP address? - Old answer: when native IPv6 Rtadv's heard - New answer: when native Rtadv's heard AND ISATAP interface usage drops below some threshold - NEWER ANSWER: make it work the same as RFC 2462, section 5.5.4 ­ Address Lifetime Expiry • Will ISATAP addresses be preferred over native IPv6 addresses by longest prefix-match? - No ­ destination ordering will fix this (already addressed in source/destination selection draft) NAT Clarifications: • Will ISATAP work on the private network side of a NAT? - Yes! • Will ISATAP work *across* NAT? - NO - NON-GOAL! • Other NGTRANS works address NAT traversal • ISATAP is complementary to these Fred wanted a straw vote on use of anycast prefix. Alain wanted to take this issue to the mail list. Jim Bound wantd to support authors recommendation. === An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp), Kazuaki Tsuchiya SLIDES: Kazuaki took a review of MAGMA (multicast specialists) yesterday. • The effectiveness of MTP was acknowledged by MAGMA. • MAGMA indicated that a few points remained to make clear. It was decided to go on with discussion on these on the mail list. === Dual Stack Hosts using "Bump-in-the-API" (BIA). Myung-Ki Shin SLIDES: Myung-Ki covered changes since IETF-51: • Published 01 version • Editorial changes - Applicability statements section - Disclaimers section • Added API function list intercepted by BIA module [Appendix] Open Issue: • Problem - A client node running BIA trying to contact a dual stack node on a port number that is only associated to an IPv4 application. • There are 2 approaches - 1- the client node should cycle through all the addresses and end up trying the IPv4 one - 2- BIA should do the work. * It is not clear at this time which behavior is desirable so we need to get feedback from experimentation. Next Steps: • Go to wg last call - We propose to publish the draft with experimental status to give it wide circulation and ask for implementation feedback. • Once feedback will have determined which behavior is desirable (it may very well be application dependant), we should republish the draft with Informational status. === Application Aspects of IPv6 Transition, Myung-Ki Shin SLIDES: Why this draft? • As IPv6 is deployed, there are some problems that the application developers and the administrators face. • This draft clarifies the problems occurred in transition periods between IPv4 applications and IPv6 applications. What is problem ? • Dual stack host does not mean having both IPv4 and IPv6 applications. • We cannot know the version of peer application only by DNS name resolving. • We have three types of IPv6-enabled applications. - IPv4+BIA - IPv6 native - Both IPv4 and IPv6 support • Application selection problem - System administrator can be confused by various combinations of application versions and Ngtrans mechanisms. Next Steps • We need consensus on these problem statements. • Are there any other problems or issues for application transition now, and in the future ? • Do we need guidelines for application transition ? - This draft will propose guidelines to implement and choose the suitable application under the various current transition environments. • Become a ngtrans project. Brian Zill commented that this needs to be a living document as it could be years before a polished and finished document can be delivered. He felt this is important work, but cannot be done quickly. Tony and Alain noted that this is a project that at least needs coordination with the Applications area, so the chairs will interact with those area directors to see what works. === Dual Stack deployment using DSTM and neighbour discovery, Gerard Gastaud SLIDES: Gerard presented ND-DSTM for consideration as an ngtrans project. He noted that DSTM is a powerful and useful element in the NGTRANS tool box for both mobile and enterprise environments. Though DSTM has been associated with DHCP, which has been delayed, something is needed. ND-DSTM uses IPv6 neighbour discovery [ND] to manage IPv4 address allocation. The draft show how a border gateway using extensions to ND can manage this allocation process. A Dual Stacked Host (DS-H) starts a communication with a v4 host in a remote domain according to DSTM. When DS-H needs it, it requests an IPv4 address of the DSTM router by means of an "RS"" message. The DSTM router assigns an IPv4 address to the DSH by means of an"RA" message. RA/RS messages are tunnelled into IPv6 to override the local link scope of the ND messages. To accomplish this, 2 new options are required: an RS DSH mapping request and an RA DSTM reply. Gerard noted that the authors want ND-DSTM to be one of the implementations of the DSTM architecture. Alain Durand was concerned that host may require manual configuration. He asked developers if they would accept the tunnel if it is not configured. Jim Bound said it would be dropped if not configured, but this shouldn't stop use of the idea. Christian Huitema said that it will be dropped. Author said they will resubmit a new draft in the context of other DSTM changes. When the new draft is available, it will not evaluated as a project again. === Multicast extensions to dual stack hosts using the "Bump-In-the-Stack" Technique (mBIS), Kazuaki Tsuchiya SLIDES: Kazuaki presented his mBIS draft for consideration as an ngtrans project. This draft describes a mechanism which allows existing hosts to speak in IPv6 multicast using existing IPv4 multicast applications. This is an extension of the original BIS work, now Informational RFC2767. There was no show of support for mBIS as an ngtrans project among attendees, thus mBIS will be taken to the ngtrans list to confirm this. === IPv6 Traffic Engineering Tunnel, Hideo Ishii SLIDES: This document specifies a method to transmit IPv6 traffic over IPv4 MPLS Label Switched Paths (LSPs) constructed by RSVP-TE. The way to transmit IPv4 and IPv6 traffic over IPv4 MPLS LSPs and the way to exchange routing information are described. This method allows Traffic Engineering for IPv4 and IPv6 separately or both inclusively. The advantages of this approach are: • From the IPv6 point of view, these are ordinal logical interfaces (Similar to tunneling interfaces) capable of IPv6. • Can use any routing protocols among IPv6 PE routers. OSPFv3, RIPng and of course BGP4+. • Traffic Engineering for IPv4 and IPv6 separately or both inclusively. Alain Durand noted that a review of rfc/id directory shows several ip over mpls docs, and that he is not sure it fits here in ngtrans. He suggested that the authors should go to talk to Internet area director as it is not applicable here. ============ Friday, December 14 at 0900-1000 === Discussion of new ngtrans charter and future ngtrans work - chairs SLIDES: Tony Hain presented the new charter revision goals. - Document operational requirements and recommended practises for major pieces of the Internet infrastructure in a mixed world of IPv4 only, IPv6 only and dual stack nodes. Those pieces include, but are not limited to: Routing, DNS, Mail, Network monitoring, Web, Multicast, VoIP,... This work is to be done in cooperation with the relevant experts and/or the relevant working groups when applicable. - Serve as a review board and body of competence and coordination for IPv6 transition and operational issues that span multiple IETF working groups. This includes providing technical input to the IESG/IAB, IANA, the Internet Address Registries and operational communities, with regard to IPv6 transition and operation related issues, e.g., address allocation policies and procedures and operational management mechanisms. - Coordinate 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. - Keep all IPv6 transition tool documents moving along publication / standardization track. Those tools enable transition to a mixed world of IPv4 only, IPv6 only and dual stack nodes. They falls into three categories: - dual-stack tools which assure that both protocols are supported equally throughout the infrastructure. - tunneling tools to enable IPv6 island to communicate over an IPv4 infrastructure - translation tools that enable communication between IP4 and IPv6 nodes. As a large number of tools are already documented, new tools would have to justify the problem space they are solving that is not already addressed by existing tools/mechanisms. - Document how to use those tools in major transition scenarios and document how those tools interact together. The non goals of this working group are: - Define extensions to IPv6. this is done in the ipv6 working group. - Develop multi-homing solutions. This is done in the multi6 working group. - Define particular extensions for IPv6 to existing Internet protocols. This is done in the relevant working groups. - Define or document tools/mechanisms/scenarios that are only applicable to very specific environment and are not representative enough of a wide community. Brian Carpenter commented that new schemes need be described with scenarios before issue comes up. Also, what about retiring under-utilized tools (e.g., 6over4). Tony felt that missing pieces will pop out of work on transition scenarios, and unused ones will as well. Francis Dupont noted that 6over4 not on any list in ngtrans. Tony replied that it isn't an ngtrans project. If appropriate to discard 6over4 as ngtrans progresses to a better understanding of what's important and what's not, the IPv6 WG will be asked to reconsider 6over4. Brian Zill, as one developer, noted that he wouldn't care if 6over4 went away. Bob Hinden commented that Nokia has an implementation of 6over4. Tony asked for input on new project criteria. He noted that refused projects will go to the mail list for confirmation. The new rules for new ngtrans project are: • it fits within the ngtrans charter • it addresses a relevant issue in a timely fashion must apply to a wide audience • there is sufficient interest in the wg unsolicited projects must be presented to the list to generate discussion, after a presentation to the group, interest must be shown on the list • the issue has not been solved previously must show why current mechanisms are insufficient Perry Metzger said that if someone comes up with a really great idea, overwhelming support should ovedride rules, but in general not; the rules are good. Christian Huitema commented that we are done making new tools, that we should fix broken stuff, and we shouldn't invent new ones. Randy Bush, wearing his AD hat, said that as we turn from ngtoys to ngtrans, we may find serious scenarios that reveal gaps that need to be filled. Itojun noted that transition scenarios may be different for different environments. He is not sure we can agree on single scenario. Tony replied that we need to get lots of ops community feedback from folks who will use these tools. The meeting adjourned. end --- From fink@es.net Thu Jan 3 17:02:57 2002 From: fink@es.net (Bob Fink) Date: Thu, 03 Jan 2002 09:02:57 -0800 Subject: pTLA request for POZMAN - review closes 17 January 2002 Message-ID: <5.1.0.14.0.20020103085345.00ad9240@imap2.es.net> 6bone Folk, POZMAN has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 17 January 2002. Please send your comments to me or the list. Thanks, Bob === >Date: Thu, 3 Jan 2002 13:55:31 +0100 (MET) >From: Bartosz Gajda >To: Bob Fink >cc: ipv6-support@man.poznan.pl >Subject: requesting IPv6 ptla address space > > >Hello Bob, > >I am sendig you our request for ptla IPv6 address space. >I used as a form document from www.6bone.net. > >If you have some more questions please contact me. > > >Kind regards and happy New Year! ;-) > >Bart > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Bartosz Gajda | Poznan Supercomputing and Networking Center > mailto:gajda@man.poznan.pl | ul. Noskowskiego 10 > http://www.man.poznan.pl | 61-704 Poznan, POLAND > BG1740-RIPE tel:(+48 61)858-2072,858-2015 fax:(+48 61) 8525-954 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >* >*7. Guidelines for 6Bone pTLA sites >* >* The following rules apply to qualify for a 6Bone pTLA allocation. It >* should be recognized that holders of 6Bone pTLA allocations are >* expected to provide production quality backbone network services for >* the 6Bone. >* >* 1. The pTLA Applicant must have a minimum of three (3) months >* qualifying experience as a 6Bone end-site or pNLA transit. During >* the entire qualifying period the Applicant must be operationally >* providing the following: >* >We have been assigned IPv6 address space form ICM in Poland (polish >6bone), It was 4 months ago at 28th of Aug 2001 >our address space is: >3ffe:8010:a5::/48 > > >* a. Fully maintained, up to date, 6Bone Registry entries for their >* ipv6-site inet6num, mntner, and person objects, including each >* tunnel that the Applicant has. > >we have following objects registered in 6bone whois database: >inet6num: 3FFE:8010:A5::/48 >ipv6-site: POZMAN >mntner: POZMAN-MNT >person: Bartosz Gajda >person: Wiktor Procyk >* >* b. Fully maintained, and reliable, BGP4+ peering and connectivity >* between the Applicant's boundary router and the appropriate >* connection point into the 6Bone. This router must be IPv6 >* pingable. This criteria is judged by members of the 6Bone >* Operations Group at the time of the Applicant's pTLA request. > >we have working and stable router based on zebra and SuSE linux. >We have configured and operational following tunnels and BGP sessions: > >Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down >State/PfxRcd >3ffe:8010:a5::1 4 8664 9286 1382 0 0 0 22:57:58 >357 >3ffe:8010:a5::5 4 3320 3166 1359 0 0 0 11:55:25 >190 >3ffe:8010:a5::9 4 15694 1384 1382 0 0 0 22:57:56 >4 >3ffe:8010:a5::d 4 8256 1392 6817 0 0 0 22:57:56 >2 >3ffe:8010:a5::11 > 4 8664 22552 6629 0 0 0 21:19:37 >267 >3ffe:8010:a5::15 > 4 109 2672 1357 0 0 0 11:55:31 >244 >3ffe:8010:a5::21 > 4 58502 2433 1172 0 0 0 02:43:47 >363 >3ffe:8010:a5:1::3 > 4 10 1378 5393 0 0 0 22:41:24 >1 >3ffe:8010:a5:1::101 > 4 8364 0 0 0 0 0 00:01:50 >Connect >* >* c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) >* entries for the Applicant's router(s) and at least one host >* system. > >we have configured IPv6 DNS on our main operational DNS server: >150.254.173.3 (primary) >150.254.173.2 (secondary) > >You can ask about the following entiries: >www.ipv6.man.poznan.pl >ipv6-gw.man.poznan.pl >plum.ipv6.man.poznan.pl >ipv6-gw.ipv6.man.poznan.pl > >* >* d. A fully maintained, and reliable, IPv6-accessible system >* providing, at a mimimum, one or more web pages, describing the >* Applicant's IPv6 services. This server must be IPv6 pingable. > >We have running apache 2.0 server which is IPv4 and IPv6 accessible at: >www.ipv6.man.poznan.pl > >* 2. The pTLA Applicant MUST have the ability and intent to provide >* "production-quality" 6Bone backbone service. Applicants must >* provide a statement and information in support of this claim. >* This MUST include the following: >* >* a. A support staff of two persons minimum, three preferable, with >* person attributes registered for each in the ipv6-site object >* for the pTLA applicant. > >We have two persons: >person: Bartosz Gajda >person: Wiktor Procyk > >* b. A common mailbox for support contact purposes that all support >* staff have acess to, pointed to with a notify attribute in the >* ipv6-site object for the pTLA Applicant. > >we have email address: >ipv6-support@man.poznan.pl >information concerning this is available on our web >server: www.ipv6.man.poznan.pl > >* >* 3. The pTLA Applicant MUST have a potential "user community" that >* would be served by its becoming a pTLA, e.g., the Applicant is a >* major provider of Internet service in a region, country, or focus >* of interest. Applicant must provide a statement and information in >* support this claim. > >Poznan Supercomputing and Networking Center (PSNC) is >an operator of Polish National Scientific POL-34/155 network. >This network is mostly based on ATM and SDH technology >supporting 155 Mb/s and 34 MB/s speed rates. >In this moment POL-34/155 embraced the majority of polish >metropolitan networks: >MAN Bielsko - Biała >MAN Białystok >MAN Bydgoszcz >MAN Częstochowa >MAN Elblag >MAN Gdańsk >MAN Koszalin >MAN Kraków >MAN Lublin >MAN Łód^ß >MAN Olsztyn >MAN Poznań >MAN Rzeszów >MAN Szczecin >MAN ^Ělask >MAN Toruń >MAN Zielona Góra >MAN Wrocław >MAN Opole >ICM Warszawa > >PSNC also act as an operator of Metropolitan Area Network in Poznan city. >You can find more informations concerning POL-34/155 network >on web site: >http://www.man.poznan.pl/pol34/ >and also about Network Operation Center: >http://noc.man.poznan.pl/ > >The other activities of PSNC are as follows: >- computations in a metacomputer enviroment >- integration of scientific research on computing methods >- promotion of new high performance computing and networking technologies > >We are LIR registered in Ripe-NCC as a Large as pl.pozman >We have more than 40 customers connected to our network and registered in >Ripe database. > >* >* 4. The pTLA Applicant MUST commit to abide by the current 6Bone >* operational rules and policies as they exist at time of its >* application, and agree to abide by future 6Bone backbone >* operational rules and policies as they evolve by consensus of the >* 6Bone backbone and user community. > >We agree to abide by the current 6Bone operational rules and policies. > >* >* When an Applicant seeks to receive a pTLA allocation, it will apply >* to the 6Bone Operations Group (see section 8 below) by providing to >* the Group information in support of its claims that it meets the >* criteria above. >* >*8. 6Bone Operations Group >* >* The 6Bone Operations Group is the group in charge of monitoring and >* policing adherence to the current rules. Membership in the 6Bone >* Operations Group is mandatory for, and restricted to, sites connected >* to the 6Bone. >* >* The 6Bone Operations Group is currently defined by those members of >* the existing 6Bone mailing list who represent sites participating in >* the 6Bone. Therefore it is incumbent on relevant site contacts to >* join the 6Bone mailing list. Instructions on how to join the list are >* maintained on the 6Bone web site at < http://www.6bone.net>. > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Bartosz Gajda | Poznan Supercomputing and Networking Center > mailto:gajda@man.poznan.pl | ul. Noskowskiego 10 > http://www.man.poznan.pl | 61-704 Poznan, POLAND > BG1740-RIPE tel:(+48 61)858-2072,858-2015 fax:(+48 61) 8525-954 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From fink@es.net Thu Jan 3 17:02:57 2002 From: fink@es.net (Bob Fink) Date: Thu, 03 Jan 2002 09:02:57 -0800 Subject: pTLA request for POZMAN - review closes 17 January 2002 Message-ID: <5.1.0.14.0.20020103085345.00ad9240@imap2.es.net> 6bone Folk, POZMAN has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 17 January 2002. Please send your comments to me or the list. Thanks, Bob === >Date: Thu, 3 Jan 2002 13:55:31 +0100 (MET) >From: Bartosz Gajda >To: Bob Fink >cc: ipv6-support@man.poznan.pl >Subject: requesting IPv6 ptla address space > > >Hello Bob, > >I am sendig you our request for ptla IPv6 address space. >I used as a form document from www.6bone.net. > >If you have some more questions please contact me. > > >Kind regards and happy New Year! ;-) > >Bart > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Bartosz Gajda | Poznan Supercomputing and Networking Center > mailto:gajda@man.poznan.pl | ul. Noskowskiego 10 > http://www.man.poznan.pl | 61-704 Poznan, POLAND > BG1740-RIPE tel:(+48 61)858-2072,858-2015 fax:(+48 61) 8525-954 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > >* >*7. Guidelines for 6Bone pTLA sites >* >* The following rules apply to qualify for a 6Bone pTLA allocation. It >* should be recognized that holders of 6Bone pTLA allocations are >* expected to provide production quality backbone network services for >* the 6Bone. >* >* 1. The pTLA Applicant must have a minimum of three (3) months >* qualifying experience as a 6Bone end-site or pNLA transit. During >* the entire qualifying period the Applicant must be operationally >* providing the following: >* >We have been assigned IPv6 address space form ICM in Poland (polish >6bone), It was 4 months ago at 28th of Aug 2001 >our address space is: >3ffe:8010:a5::/48 > > >* a. Fully maintained, up to date, 6Bone Registry entries for their >* ipv6-site inet6num, mntner, and person objects, including each >* tunnel that the Applicant has. > >we have following objects registered in 6bone whois database: >inet6num: 3FFE:8010:A5::/48 >ipv6-site: POZMAN >mntner: POZMAN-MNT >person: Bartosz Gajda >person: Wiktor Procyk >* >* b. Fully maintained, and reliable, BGP4+ peering and connectivity >* between the Applicant's boundary router and the appropriate >* connection point into the 6Bone. This router must be IPv6 >* pingable. This criteria is judged by members of the 6Bone >* Operations Group at the time of the Applicant's pTLA request. > >we have working and stable router based on zebra and SuSE linux. >We have configured and operational following tunnels and BGP sessions: > >Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down >State/PfxRcd >3ffe:8010:a5::1 4 8664 9286 1382 0 0 0 22:57:58 >357 >3ffe:8010:a5::5 4 3320 3166 1359 0 0 0 11:55:25 >190 >3ffe:8010:a5::9 4 15694 1384 1382 0 0 0 22:57:56 >4 >3ffe:8010:a5::d 4 8256 1392 6817 0 0 0 22:57:56 >2 >3ffe:8010:a5::11 > 4 8664 22552 6629 0 0 0 21:19:37 >267 >3ffe:8010:a5::15 > 4 109 2672 1357 0 0 0 11:55:31 >244 >3ffe:8010:a5::21 > 4 58502 2433 1172 0 0 0 02:43:47 >363 >3ffe:8010:a5:1::3 > 4 10 1378 5393 0 0 0 22:41:24 >1 >3ffe:8010:a5:1::101 > 4 8364 0 0 0 0 0 00:01:50 >Connect >* >* c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) >* entries for the Applicant's router(s) and at least one host >* system. > >we have configured IPv6 DNS on our main operational DNS server: >150.254.173.3 (primary) >150.254.173.2 (secondary) > >You can ask about the following entiries: >www.ipv6.man.poznan.pl >ipv6-gw.man.poznan.pl >plum.ipv6.man.poznan.pl >ipv6-gw.ipv6.man.poznan.pl > >* >* d. A fully maintained, and reliable, IPv6-accessible system >* providing, at a mimimum, one or more web pages, describing the >* Applicant's IPv6 services. This server must be IPv6 pingable. > >We have running apache 2.0 server which is IPv4 and IPv6 accessible at: >www.ipv6.man.poznan.pl > >* 2. The pTLA Applicant MUST have the ability and intent to provide >* "production-quality" 6Bone backbone service. Applicants must >* provide a statement and information in support of this claim. >* This MUST include the following: >* >* a. A support staff of two persons minimum, three preferable, with >* person attributes registered for each in the ipv6-site object >* for the pTLA applicant. > >We have two persons: >person: Bartosz Gajda >person: Wiktor Procyk > >* b. A common mailbox for support contact purposes that all support >* staff have acess to, pointed to with a notify attribute in the >* ipv6-site object for the pTLA Applicant. > >we have email address: >ipv6-support@man.poznan.pl >information concerning this is available on our web >server: www.ipv6.man.poznan.pl > >* >* 3. The pTLA Applicant MUST have a potential "user community" that >* would be served by its becoming a pTLA, e.g., the Applicant is a >* major provider of Internet service in a region, country, or focus >* of interest. Applicant must provide a statement and information in >* support this claim. > >Poznan Supercomputing and Networking Center (PSNC) is >an operator of Polish National Scientific POL-34/155 network. >This network is mostly based on ATM and SDH technology >supporting 155 Mb/s and 34 MB/s speed rates. >In this moment POL-34/155 embraced the majority of polish >metropolitan networks: >MAN Bielsko - Biała >MAN Białystok >MAN Bydgoszcz >MAN Częstochowa >MAN Elblag >MAN Gdańsk >MAN Koszalin >MAN Kraków >MAN Lublin >MAN Łód^ß >MAN Olsztyn >MAN Poznań >MAN Rzeszów >MAN Szczecin >MAN ^Ělask >MAN Toruń >MAN Zielona Góra >MAN Wrocław >MAN Opole >ICM Warszawa > >PSNC also act as an operator of Metropolitan Area Network in Poznan city. >You can find more informations concerning POL-34/155 network >on web site: >http://www.man.poznan.pl/pol34/ >and also about Network Operation Center: >http://noc.man.poznan.pl/ > >The other activities of PSNC are as follows: >- computations in a metacomputer enviroment >- integration of scientific research on computing methods >- promotion of new high performance computing and networking technologies > >We are LIR registered in Ripe-NCC as a Large as pl.pozman >We have more than 40 customers connected to our network and registered in >Ripe database. > >* >* 4. The pTLA Applicant MUST commit to abide by the current 6Bone >* operational rules and policies as they exist at time of its >* application, and agree to abide by future 6Bone backbone >* operational rules and policies as they evolve by consensus of the >* 6Bone backbone and user community. > >We agree to abide by the current 6Bone operational rules and policies. > >* >* When an Applicant seeks to receive a pTLA allocation, it will apply >* to the 6Bone Operations Group (see section 8 below) by providing to >* the Group information in support of its claims that it meets the >* criteria above. >* >*8. 6Bone Operations Group >* >* The 6Bone Operations Group is the group in charge of monitoring and >* policing adherence to the current rules. Membership in the 6Bone >* Operations Group is mandatory for, and restricted to, sites connected >* to the 6Bone. >* >* The 6Bone Operations Group is currently defined by those members of >* the existing 6Bone mailing list who represent sites participating in >* the 6Bone. Therefore it is incumbent on relevant site contacts to >* join the 6Bone mailing list. Instructions on how to join the list are >* maintained on the 6Bone web site at < http://www.6bone.net>. > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Bartosz Gajda | Poznan Supercomputing and Networking Center > mailto:gajda@man.poznan.pl | ul. Noskowskiego 10 > http://www.man.poznan.pl | 61-704 Poznan, POLAND > BG1740-RIPE tel:(+48 61)858-2072,858-2015 fax:(+48 61) 8525-954 >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From lewis@tislabs.com Fri Jan 4 20:54:32 2002 From: lewis@tislabs.com (Edward Lewis) Date: Fri, 4 Jan 2002 15:54:32 -0500 Subject: Question on address configuration Message-ID: We're starting up a 6Bone connected set of machines and have come across a question regarding setting up a server. (If this isn't 6Bone fodder, please send me a redirect.) I'd like to have my DNS server at 3ffe:817::3. I can configure an interface to come up at that address. But I would also like to have this machine be able to listen to a router's advertisement of 3ffe:817::/64 as the local (globally routed) network address and then append ::3 to get the setting. E.g., Could (linux) ifcfg-eth0 have a line IPV6ADDR="::3" which tells the router solicitor to append that to the router's prefix? I understand autoconf, and have been able to set that up, getting prefix:enet-number as the IPv6 address. Like I said, by playing with the ifconfig (or appropriate network interface configuration command) I can also just set up the 128 bit address. If there isn't already a way to assign an address in the way I've described, this may be an issue. I'd like to take advantage of router advertisements so that I can renumber by just changing the router (and a few lines in DNS, assuming A6). If I use autoconf I can do this - but if my server's interface card dies and is replaced, my server's well-known address is changed. With DNS and the /etc/resolv.conf file, I'd have to visit every machine to make this change. Perhaps this isn't a clear description of the problem. Yeah, an application like DNS shouldn't depend on the network (IPv6) address - but this is DNS. Maybe I do need to forego the advantages of autoconf for servers. Maybe I have the wrong mindset about address assignments. Perhaps my clients should put a site-local address in /etc/resolv.conf, and I should pay the price for static assignments for my publically accessable [name] servers. PS Typing "ping6 3ffe:817::3" is a lot easier than: "ping6 3ffe:817::what:ever:that:card:is" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. From michel@arneill-py.sacramento.ca.us Sat Jan 5 04:21:00 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 4 Jan 2002 20:21:00 -0800 Subject: Question on address configuration Message-ID: <2B81403386729140A3A899A8B39B046405DE22@server2000.arneill-py.sacramento.ca.us> Edward, I do not know how to do that on linux, and I do understand why you would want to do it although I don't think I would want to do it myself. I can suggest a workaround: On routers and on some NICs, you can manually configure the MAC address. I have not done that for a while on a NIC, but 3Com 3C59x have a config utility. It is likely that linux would read the manually configured MAC address to build its own IPv6 address from the RA. Most people will prefer a statically configured IPv6 address for a DNS server anyway. Something I don't get: from your text it appears that you own 3ffe:817::/32 and I don't see that block in the 6bone database. Michel. From pekkas@netcore.fi Sat Jan 5 17:45:59 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sat, 5 Jan 2002 19:45:59 +0200 (EET) Subject: Question on address configuration In-Reply-To: Message-ID: On Fri, 4 Jan 2002, Edward Lewis wrote: > E.g., Could (linux) ifcfg-eth0 have a line IPV6ADDR="::3" which tells the > router solicitor to append that to the router's prefix? > > I understand autoconf, and have been able to set that up, getting > prefix:enet-number as the IPv6 address. Like I said, by playing with the > ifconfig (or appropriate network interface configuration command) I can > also just set up the 128 bit address. No, that isn't possible. I think this would be an interesting development; basically a simple implementation of user-space router solicitation client would be required. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From nsayer@quack.kfu.com Sun Jan 6 23:19:57 2002 From: nsayer@quack.kfu.com (Nick Sayer) Date: Sun, 06 Jan 2002 15:19:57 -0800 Subject: Question on address configuration References: Message-ID: <3C38DB9D.4090001@quack.kfu.com> Why not simply use site-local addresses for the well-known aliases? In fact, there is a draft document somewhere (about DNS autodiscovery?) that suggests using fec0:0:0:ffff::{1,2,3} as DNS servers. The beauty of site-local addressing is that it won't change as your prefix changes. That makes it perfect for situations as you describe. Edward Lewis wrote: > We're starting up a 6Bone connected set of machines and have come across a > question regarding setting up a server. (If this isn't 6Bone fodder, > please send me a redirect.) > > I'd like to have my DNS server at 3ffe:817::3. I can configure an > interface to come up at that address. But I would also like to have this > machine be able to listen to a router's advertisement of 3ffe:817::/64 as > the local (globally routed) network address and then append ::3 to get the > setting. > > E.g., Could (linux) ifcfg-eth0 have a line IPV6ADDR="::3" which tells the > router solicitor to append that to the router's prefix? > > I understand autoconf, and have been able to set that up, getting > prefix:enet-number as the IPv6 address. Like I said, by playing with the > ifconfig (or appropriate network interface configuration command) I can > also just set up the 128 bit address. > > If there isn't already a way to assign an address in the way I've > described, this may be an issue. I'd like to take advantage of router > advertisements so that I can renumber by just changing the router (and a > few lines in DNS, assuming A6). If I use autoconf I can do this - but if > my server's interface card dies and is replaced, my server's well-known > address is changed. With DNS and the /etc/resolv.conf file, I'd have to > visit every machine to make this change. > > Perhaps this isn't a clear description of the problem. Yeah, an > application like DNS shouldn't depend on the network (IPv6) address - but > this is DNS. Maybe I do need to forego the advantages of autoconf for > servers. Maybe I have the wrong mindset about address assignments. > Perhaps my clients should put a site-local address in /etc/resolv.conf, and > I should pay the price for static assignments for my publically accessable > [name] servers. > > PS Typing "ping6 3ffe:817::3" is a lot easier than: > "ping6 3ffe:817::what:ever:that:card:is" > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Opinions expressed are property of my evil twin, not my employer. > > > From pekkas@netcore.fi Mon Jan 7 08:22:41 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Mon, 7 Jan 2002 10:22:41 +0200 (EET) Subject: Question on address configuration In-Reply-To: <20020106172411.A1396@litech.org> Message-ID: On Sun, 6 Jan 2002, Nathan Lutchansky wrote: > On Sat, Jan 05, 2002 at 07:45:59PM +0200, Pekka Savola wrote: > > On Fri, 4 Jan 2002, Edward Lewis wrote: > > > E.g., Could (linux) ifcfg-eth0 have a line IPV6ADDR="::3" which tells the > > > router solicitor to append that to the router's prefix? > > > > No, that isn't possible. > > > > I think this would be an interesting development; basically a simple > > implementation of user-space router solicitation client would be required. > > I should think the better solution would be to modify the IPv6 stack to > generate global addresses by combining advertised prefixes with the lower > 64 from each link-local address. Then you can add all your well-known > interface IDs as link-local addresses and your globals will just appear. > > Thus, if I have eth0 with > > - autoconfigured address fe80::2a0:56ff:fe94:4444 and > - manually configured address fe80::1, > > my global addresses would be generated from the advertised prefix of > 3ffe:2900:f10a:701::/64 to give > > - 3ffe:2900:f10a:701:2a0:56ff:fe94:4444 and > - 3ffe:2900:f10a:701::1. > > Now I have a well-known interface ID used in an autoconfigured prefix. > > I haven't thought about this enough to find any problems, and I haven't > checked to see if RFC 2462 would even allow this approach. But I can > certainly see benefits to doing autoconfiguration this way. -Nathan This is an interesting idea, and IMO, might be nice to have as a on/off togglable feature at least. The problem is that if someone adds a manual address to the link-locals, he might not want it in globals. One additional (but perhaps minor) problem here is DAD. If the node has fe80::1 as its address, it has already performed duplicate address detection for it. By the spec, the DAD check can be omitted if the suffix is the same, so no DAD would be performed if one configured 3ffe:ffff::1. For global addresses, this might be worse than for link-locals. But then again, DAD isn't (error/fool)proof anyway, so I don't think this is a too big issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From lewis@tislabs.com Mon Jan 7 15:14:21 2002 From: lewis@tislabs.com (Edward Lewis) Date: Mon, 7 Jan 2002 10:14:21 -0500 Subject: Question on address configuration In-Reply-To: References: <20020106172411.A1396@litech.org> Message-ID: Thanks for the various replies. At least I know I wasn't missing something in the configurations and also not trying to do something in violation of the spec. As I only have a handful of machines right now, I don't need to commit to one way or another, I have the luxury of being able to play around a bit. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. From lewis@tislabs.com Mon Jan 7 15:12:13 2002 From: lewis@tislabs.com (Edward Lewis) Date: Mon, 7 Jan 2002 10:12:13 -0500 Subject: Question on address configuration In-Reply-To: <2B81403386729140A3A899A8B39B046405DE22@server2000.arneill-py.sacramento.c a.us> Message-ID: At 11:21 PM -0500 1/4/02, Michel Py wrote: >Something I don't get: from your text it appears that you own >3ffe:817::/32 and >I don't see that block in the 6bone database. The delegation is young...;) I'm not sure if it is a /32 or a /higher. With the holidays just over, I'm sure it'll be worked out soon. Where is the 6bone database? I was hoping there was someway to verify address assignments. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. From michel@arneill-py.sacramento.ca.us Mon Jan 7 15:59:15 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 7 Jan 2002 07:59:15 -0800 Subject: Question on address configuration Message-ID: <2B81403386729140A3A899A8B39B046403D607@server2000.arneill-py.sacramento.ca.us> Edward, >> At 11:21 PM -0500 1/4/02, Michel Py wrote: >> Something I don't get: from your text it appears >> that you own 3ffe:817::/32 and >> I don't see that block in the 6bone database. > From: Edward Lewis [mailto:lewis@tislabs.com] > The delegation is young...;) I'm not sure if it is a > /32 or a /higher. With the holidays just over, I'm sure > it'll be worked out soon. > Where is the 6bone database? I was hoping there was someway > to verify address assignments. There is a link to the 6bone registry on the main 6bone web page, www.6bone.net Michel From michel@arneill-py.sacramento.ca.us Mon Jan 7 16:15:19 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 7 Jan 2002 08:15:19 -0800 Subject: Question on address configuration Message-ID: <2B81403386729140A3A899A8B39B046403D609@server2000.arneill-py.sacramento.ca.us> Has someone try to spin that idea in the ipv6 WG? Michel -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Monday, January 07, 2002 12:23 AM To: Nathan Lutchansky Cc: Edward Lewis; 6BONE List Subject: Re: Question on address configuration On Sun, 6 Jan 2002, Nathan Lutchansky wrote: > On Sat, Jan 05, 2002 at 07:45:59PM +0200, Pekka Savola wrote: > > On Fri, 4 Jan 2002, Edward Lewis wrote: > > > E.g., Could (linux) ifcfg-eth0 have a line IPV6ADDR="::3" which tells the > > > router solicitor to append that to the router's prefix? > > > > No, that isn't possible. > > > > I think this would be an interesting development; basically a simple > > implementation of user-space router solicitation client would be required. > > I should think the better solution would be to modify the IPv6 stack to > generate global addresses by combining advertised prefixes with the lower > 64 from each link-local address. Then you can add all your well-known > interface IDs as link-local addresses and your globals will just appear. > > Thus, if I have eth0 with > > - autoconfigured address fe80::2a0:56ff:fe94:4444 and > - manually configured address fe80::1, > > my global addresses would be generated from the advertised prefix of > 3ffe:2900:f10a:701::/64 to give > > - 3ffe:2900:f10a:701:2a0:56ff:fe94:4444 and > - 3ffe:2900:f10a:701::1. > > Now I have a well-known interface ID used in an autoconfigured prefix. > > I haven't thought about this enough to find any problems, and I haven't > checked to see if RFC 2462 would even allow this approach. But I can > certainly see benefits to doing autoconfiguration this way. -Nathan This is an interesting idea, and IMO, might be nice to have as a on/off togglable feature at least. The problem is that if someone adds a manual address to the link-locals, he might not want it in globals. One additional (but perhaps minor) problem here is DAD. If the node has fe80::1 as its address, it has already performed duplicate address detection for it. By the spec, the DAD check can be omitted if the suffix is the same, so no DAD would be performed if one configured 3ffe:ffff::1. For global addresses, this might be worse than for link-locals. But then again, DAD isn't (error/fool)proof anyway, so I don't think this is a too big issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From abdul.rouf@wipro.net Tue Jan 8 06:08:49 2002 From: abdul.rouf@wipro.net (Abdul Rouf Basheer) Date: Tue, 8 Jan 2002 11:08:49 +0500 Subject: Connection to 6Bone Message-ID: <1A55B0D6E6A6D4118CFA009027E0368004C5EDF7@BANGALORE> Hi, We are Class A ISP in India with POPS in 32 cities. our AS is 9796. We have two upstream providers, one is terrestrial and the other is satellite. Provider who has taken Bandwidth from global crossings termintes to NAP in US. Where as Provider satellite (Loral Orion) connects to base station in Huawei. >I wanted to connect to 6bone to one of NLA. I have tried sending mails to Mr. Rahul referenced name in ipv6-site:IPV6-BITS-IN, more than a week no response yet. Consider me a novice in IPv6 and pls. do help. Thanks in advance. > Cheers :-):-):-) > Abdul Rouf > Wipro Infotech Ltd., > Communication Services Division > * abdul.rouf@wipro.net > & : 080-5092563/65/98/99-Extn-127 > > From wizard@italiansky.com Tue Jan 8 11:35:19 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Tue, 8 Jan 2002 12:35:19 +0100 Subject: Contact person at sprintlink Message-ID: Hi to all, I'm looking for a contact person at sprintlink. Previous one seems to not responding no more.... Thanks to all Matteo Tescione Ip admin COMv6 From rrockell@sprint.net Tue Jan 8 13:58:34 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Tue, 8 Jan 2002 08:58:34 -0500 (EST) Subject: Contact person at sprintlink In-Reply-To: Message-ID: I am here. What can I do for you? Who did you use in the past? Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia (+1) 703-689-6322 Sprint IP Services : Thinking outside the 435 box ----------------------------------------------------------------------- On Tue, 8 Jan 2002, Matteo Tescione wrote: ->Hi to all, ->I'm looking for a contact person at sprintlink. ->Previous one seems to not responding no more.... ->Thanks to all -> ->Matteo Tescione ->Ip admin ->COMv6 -> From burgess@mitre.org Tue Jan 8 14:17:08 2002 From: burgess@mitre.org (Dave Burgess) Date: Tue, 08 Jan 2002 08:17:08 -0600 Subject: Contact person at sprintlink References: Message-ID: <3C3AFF64.4EE63D6B@mitre.org> You might be experiencing the same thing I was: SPAMHaus has listed all of Sprint's Corporate servers as SPAM hosts. If you are using Osirusoft or SPAMHaus in your E-Mail system, their mail is bouncing. Apparently, there are lawyers involved now. Matteo Tescione wrote: > Hi to all, > I'm looking for a contact person at sprintlink. > Previous one seems to not responding no more.... > Thanks to all > > Matteo Tescione > Ip admin > COMv6 From gcampos@campus.cem.itesm.mx Tue Jan 8 14:54:51 2002 From: gcampos@campus.cem.itesm.mx (M. en C. Gabriela A. Campos G.) Date: Tue, 08 Jan 2002 08:54:51 -0600 Subject: unsubcribe Message-ID: <3C3B083B.5E9777E7@campus.cem.itesm.mx> This is a multi-part message in MIME format. --------------045D996DA0FB45321C87C12A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit unsubcribe --------------045D996DA0FB45321C87C12A Content-Type: text/x-vcard; charset=us-ascii; name="gcampos.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for M. en C. Gabriela A. Campos G. Content-Disposition: attachment; filename="gcampos.vcf" begin:vcard n:; x-mozilla-html:FALSE url:http://research.cem.itesm.mx/gcampos/index.htm org:ITESM-CEM;Sistemas de Información version:2.1 email;internet:gcampos@campus.cem.itesm.mx adr;quoted-printable:;;Carr. Lago de Guadalupe Km 3.5,=0D=0ACol. Margarita Maza de Ju=E1rez,=0D=0AAtizap=E1n de Zaragoza, Edo. de M=E9xico=0D=0A;;;CP. 52926; fn:M. en C. Gabriela A. Campos G. end:vcard --------------045D996DA0FB45321C87C12A-- From chuck+6bone@snew.com Tue Jan 8 19:37:57 2002 From: chuck+6bone@snew.com (Chuck Yerkes) Date: Tue, 8 Jan 2002 11:37:57 -0800 Subject: Question on address configuration In-Reply-To: ; from lewis@tislabs.com on Fri, Jan 04, 2002 at 03:54:32PM -0500 References: Message-ID: <20020108113756.A28736@snew.com> Why not do the auto-conf and get the whole, and I'll call "true" address (that uses the Mac Address). And setup an alias address for the DNS function. I've regularly put multiple addresses on a single machine when multiple machines aren't needed. Your interface can carry several addresses (whether IPv6 or v4). Quoting Edward Lewis (lewis@tislabs.com): > We're starting up a 6Bone connected set of machines and have come across a > question regarding setting up a server. (If this isn't 6Bone fodder, > please send me a redirect.) > > I'd like to have my DNS server at 3ffe:817::3. I can configure an > interface to come up at that address. But I would also like to have this > machine be able to listen to a router's advertisement of 3ffe:817::/64 as > the local (globally routed) network address and then append ::3 to get the > setting. > > E.g., Could (linux) ifcfg-eth0 have a line IPV6ADDR="::3" which tells the > router solicitor to append that to the router's prefix? > > I understand autoconf, and have been able to set that up, getting > prefix:enet-number as the IPv6 address. Like I said, by playing with the > ifconfig (or appropriate network interface configuration command) I can > also just set up the 128 bit address. > > If there isn't already a way to assign an address in the way I've > described, this may be an issue. I'd like to take advantage of router > advertisements so that I can renumber by just changing the router (and a > few lines in DNS, assuming A6). If I use autoconf I can do this - but if > my server's interface card dies and is replaced, my server's well-known > address is changed. With DNS and the /etc/resolv.conf file, I'd have to > visit every machine to make this change. > > Perhaps this isn't a clear description of the problem. Yeah, an > application like DNS shouldn't depend on the network (IPv6) address - but > this is DNS. Maybe I do need to forego the advantages of autoconf for > servers. Maybe I have the wrong mindset about address assignments. > Perhaps my clients should put a site-local address in /etc/resolv.conf, and > I should pay the price for static assignments for my publically accessable > [name] servers. > > PS Typing "ping6 3ffe:817::3" is a lot easier than: > "ping6 3ffe:817::what:ever:that:card:is" > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis NAI Labs > Phone: +1 443-259-2352 Email: lewis@tislabs.com > > Opinions expressed are property of my evil twin, not my employer. > From kre@munnari.OZ.AU Wed Jan 9 02:38:23 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Wed, 09 Jan 2002 09:38:23 +0700 Subject: Question on address configuration In-Reply-To: <20020108113756.A28736@snew.com> References: <20020108113756.A28736@snew.com> Message-ID: <3209.1010543903@brandenburg.cs.mu.OZ.AU> Date: Tue, 8 Jan 2002 11:37:57 -0800 From: Chuck Yerkes Message-ID: <20020108113756.A28736@snew.com> | Why not do the auto-conf and get the whole, and I'll call "true" | address (that uses the Mac Address). And setup an alias address | for the DNS function. I've regularly put multiple addresses on | a single machine when multiple machines aren't needed. That doesn't make a lot of sense - multiple addresses are a fine facility to have, for when they're needed, but adding addresses just because they can be added makes no sense. If they all go in the DNS, then (because they're all reachable or not simultaneously when they have the same prefix) then when the host or net is down, others will waste time trying multiple variants on what is essentially the same thing, for no benefit whatever. On the other hand, if they're not in the DNS, and don't have some special purpose local use, then they might as well not exist, as no-one will ever use them. The original request pointed out what is pretty much a current implementation deficiency - it isn't a major one, as it doesn't prevent anyone from doing anything they need to do, it just makes it harder. Eventually I'd expect to see implementations improved so configuring the "token" part to be used for addresses (for one specific address, or for all addresses autoconfigured on an interface) is easy. kre ps: there's no point taking this to the ipngwg (or ipv6wg if its name has changed by now), this has nothing at all to do with the protocols - not even with the API, it is purely an implementation mtter. From bmanning@ISI.EDU Wed Jan 9 06:51:27 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Tue, 8 Jan 2002 22:51:27 -0800 Subject: Question on address configuration In-Reply-To: <3209.1010543903@brandenburg.cs.mu.OZ.AU> References: <20020108113756.A28736@snew.com> <3209.1010543903@brandenburg.cs.mu.OZ.AU> Message-ID: <20020109065127.GI971@zed.isi.edu> > The original request pointed out what is pretty much a current implementation > deficiency - it isn't a major one, as it doesn't prevent anyone from doing > anything they need to do, it just makes it harder. Eventually I'd expect to > see implementations improved so configuring the "token" part to be used for > addresses (for one specific address, or for all addresses autoconfigured > on an interface) is easy. > > kre > > ps: there's no point taking this to the ipngwg (or ipv6wg if its name has > changed by now), this has nothing at all to do with the protocols - not even > with the API, it is purely an implementation mtter. why does this (the original question) look alot like the old IPv4 form: 0.0.160.57 and the router prepends the prefix.... --bill From fink@es.net Wed Jan 9 16:04:02 2002 From: fink@es.net (Bob Fink) Date: Wed, 09 Jan 2002 08:04:02 -0800 Subject: pTLA request for CSTNET - review closes 23 January 2002 Message-ID: <5.1.0.14.0.20020109075053.063dd658@imap2.es.net> 6bone Folk, CSTNET has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 23 January 2002. Please send your comments to me or the list. Thanks, Bob === >From: "zhang hong" >To: "Bob Fink" >Cc: , "Ă« ΰ" , > "ŐĹ ÎÄ»Ô" >Subject: pTLA request for CSTNet >Date: Tue, 8 Jan 2002 16:18:20 +0800 >X-Mailer: Microsoft Outlook Express 6.00.2600.0000 >Hello Bob, > >Happy New year! >We are CSTNet in China. We would like to apply for a pTLA >allocation from 6Bone. CSTNet is one of the four major networks >directly linked to the global Internet in China. >CSTNet provides comprehensive network communication service >and Internet service to the scientific and technical circles, >scientific administrative departments, relevant government >departments and hi-tech enterprises all over China. The web >page is http://www.cstnet.net.cn , http://www.cnic.ac.cn > >We would like to request one pTLA block, conforming to RFC 2772 >pTLA prefix requests. > > >7. Guidelines for 6Bone pTLA sites > >The following rules apply to qualify for a 6Bone pTLA allocation. >It should be recognized that holders of 6Bone pTLA allocations >are expected to provide production quality backbone network >services for the 6Bone. > >1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. > During the entire qualifying period the Applicant must be > operationally providing the following: > >We have been assigned the IPv6 address from Sprint in US since >July 2000. Our address prefix is 3ffe:2900:e003/48. > >a. Fully maintained, up to date, 6Bone Registry entries for their > ipv6-site inet6num, mntner, and person objects, including each > tunnel that the Applicant has. > >The CSTNET has the following objects: > >inet6num: 3FFE:2900:E003::/48 >ipv6-site: CSTNET >mntner: MNT-CNNIC >mnt-by: MNT-CNNIC >person: Zhang Hong >person: Zhijie Ren >person: Luo Yan >person: Xia Qing >application: >ping www.ipv6.cnnic.net.cn >IPv4/IPv6 url www.ipv6.cnnic.net.cn > >We have 6 tunnels: >tunnel: IPv6 in IPv4 6bone.ipv6.cnnic.net.cn -> >sl-bb1-6bone.sprintlink.net SPRINT BGP4+ >tunnel: IPv6 in IPv4 6bone.ipv6.cnnic.net.cn -> >lorrie-pt.tunnel.ipv6.he.net HURRICANE BGP4+ >tunnel: IPv6 in IPv4 6bone.ipv6.cnnic.net.cn -> >6bone-gw3.cselt.it TILAB BGP4+ >tunnel: IPv6 in IPv4 6bone.ipv6.cnnic.net.cn -> >gateway.manis.net.my MIMOS BGP4+ >tunnel: IPv6 in IPv4 6bone.ipv6.cnnic.net.cn -> >ipv6-lab-gw.cisco.com CISCO BGP4+ >tunnel: IPv6 in IPv4 6bone.ipv6.cnnic.net.cn -> >ipv6-gw1.pa-x.dec.com DIGITAL-CA BGP4+ > > > >b. Fully maintained, and reliable, BGP4+ peering and connectivity > between the Applicant's boundary router and the appropriate > connection point into the 6Bone. This router must be IPv6 > pingable. This criteria is judged by members of the 6Bone > Operations Group at the time of the Applicant's pTLA request. > >Our BGP4+ conections are working on cisco 2611, this router is >6bone.ipv6.cnnic.net.cn and can be Ipv6 pingable. > > >c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > >Forward(AAAA) entries are as following: > >www IN AAAA 3ffe:2900:e003:0:200:21ff:fee4:59a0 >6bone IN AAAA 3ffe:2900:e003::65 > >Reverse(ip6.int) entries are as following: > >$ORIGIN 3.0.0.e.0.0.9.2.e.f.f.3.ip6.int. >0.a.9.5.4.e.e.f.f.f.1.2.0.0.2.0.0.0.0.0 14400 IN PTR >www.ipv6.cnnic.net.cn. >5.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 14400 IN PTR >6bone.ipv6.cnnic.net.cn. > > >d. A fully maintained, and reliable, IPv6-accessible system > providing, at a mimimum, one or more web pages, describing the > Applicant's IPv6 services. This server must be IPv6 pingable. > >Our Dual-Stack (IPv4/IPv6) web page is http://www.ipv6.cnnic.net.cn. >Here you could find some basic information about IPv6, and our >tunnels status can be found here. > > >2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > >a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > >We have 4 Persons: > >ZH-6BONE >REN-6BONE >LY-6BONE >XQ-6BONE > >b. A common mailbox for support contact purposes that all support > staff have acess to, pointed to with a notify attribute in the > ipv6-site object for the pTLA Applicant. > >Ipv6group@cnnic.net.cn > >3. The pTLA Applicant MUST have a potential "user community" that > would be served by its becoming a pTLA, e.g., the Applicant is a > major provider of Internet service in a region, country, or focus > of interest. Applicant must provide a statement and information in > support this claim. > >CSTNet is one of the four major networks directly linked to the >global Internet in China. CSTNet provides comprehensive network >communication service and Internet service to the scientific and >technical circles, scientific administrative departments, >relevant government departments and hi-tech enterprises all over >China. There are over 1000 access networks, 300,000 computers >directly linked to CSTNet and 800,000 end-users distributed in >30 provinces or cities across the country. The web page is >http://www.cstnet.net.cn , http://www.cnic.ac.cn > >4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus of the > 6Bone backbone and user community. > >We undertand the 6bone operational rules and we are strongly agree >with them . We will abide by the current and the future 6bone >operational rules and policies. > > When an Applicant seeks to receive a pTLA allocation, it will apply > to the 6Bone Operations Group (see section 8 below) by providing to > the Group information in support of its claims that it meets the > criteria above. > >8. 6Bone Operations Group > > The 6Bone Operations Group is the group in charge of monitoring and > policing adherence to the current rules. Membership in the 6Bone > Operations Group is mandatory for, and restricted to, sites > connected to the 6Bone. > > The 6Bone Operations Group is currently defined by those members of > the existing 6Bone mailing list who represent sites participating in > the 6Bone. Therefore it is incumbent on relevant site contacts to > join the 6Bone mailing list. Instructions on how to join the list are > maintained on the 6Bone web site at < http://www.6bone.net>. > > > >Regards from China! >Thank you very much! > >Zhang Hong >zhangh@cnnic.net.cn From mlehman@microsoft.com Wed Jan 9 16:10:21 2002 From: mlehman@microsoft.com (Matthew Lehman) Date: Wed, 9 Jan 2002 08:10:21 -0800 Subject: Question on address configuration Message-ID: What about a well-known anycast address for the DNS server to listen on. The clients could use the well-known address and would only require configuration once, it's reasonably scalable (just add more DNS servers listening on the address), and it does not require any special changes to any protocols. It does require anycast listening support and I don't know of any platforms that currently have it. Someone on the list might know more about implementations in the works. -Matthew -----Original Message----- From: Robert Elz [mailto:kre@munnari.OZ.AU] Sent: Tuesday, January 08, 2002 6:38 PM To: Chuck Yerkes Cc: Edward Lewis; 6BONE List Subject: Re: Question on address configuration Date: Tue, 8 Jan 2002 11:37:57 -0800 From: Chuck Yerkes Message-ID: <20020108113756.A28736@snew.com> | Why not do the auto-conf and get the whole, and I'll call "true" | address (that uses the Mac Address). And setup an alias address | for the DNS function. I've regularly put multiple addresses on | a single machine when multiple machines aren't needed. That doesn't make a lot of sense - multiple addresses are a fine facility to have, for when they're needed, but adding addresses just because they can be added makes no sense. If they all go in the DNS, then (because they're all reachable or not simultaneously when they have the same prefix) then when the host or net is down, others will waste time trying multiple variants on what is essentially the same thing, for no benefit whatever. On the other hand, if they're not in the DNS, and don't have some special purpose local use, then they might as well not exist, as no-one will ever use them. The original request pointed out what is pretty much a current implementation deficiency - it isn't a major one, as it doesn't prevent anyone from doing anything they need to do, it just makes it harder. Eventually I'd expect to see implementations improved so configuring the "token" part to be used for addresses (for one specific address, or for all addresses autoconfigured on an interface) is easy. kre ps: there's no point taking this to the ipngwg (or ipv6wg if its name has changed by now), this has nothing at all to do with the protocols - not even with the API, it is purely an implementation mtter. From drwho@timelords.org Wed Jan 9 16:22:16 2002 From: drwho@timelords.org (Billy) Date: Wed, 9 Jan 2002 10:22:16 -0600 Subject: Contact person at sprintlink In-Reply-To: ; from rrockell@sprint.net on Tue, Jan 08, 2002 at 08:58:34AM -0500 References: Message-ID: <20020109102216.C79657@timelords.org> Rob kicks major heinie.. he's awesome, and will be very helpful for you if you are nice to him! :) - Bill W On Tue, Jan 08, 2002 at 08:58:34AM -0500, Robert J. Rockell wrote: > Date: Tue, 8 Jan 2002 08:58:34 -0500 (EST) > From: "Robert J. Rockell" > To: Matteo Tescione > Cc: <6bone@ISI.EDU> > Subject: Re: Contact person at sprintlink > > I am here. What can I do for you? Who did you use in the past? > > Thanks > Rob Rockell > Principal Engineer > SprintLink Europe/Asia > (+1) 703-689-6322 > Sprint IP Services : Thinking outside the 435 box > ----------------------------------------------------------------------- > > On Tue, 8 Jan 2002, Matteo Tescione wrote: > > ->Hi to all, > ->I'm looking for a contact person at sprintlink. > ->Previous one seems to not responding no more.... > ->Thanks to all > -> > ->Matteo Tescione > ->Ip admin > ->COMv6 > -> > -- ------------------------------------------- If you're not outraged, you're not paying attention! From pekkas@netcore.fi Wed Jan 9 19:15:14 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Wed, 9 Jan 2002 21:15:14 +0200 (EET) Subject: Question on address configuration In-Reply-To: Message-ID: On Wed, 9 Jan 2002, Matthew Lehman wrote: > What about a well-known anycast address for the DNS server to listen on. > The clients could use the well-known address and would only require > configuration once, it's reasonably scalable (just add more DNS servers > listening on the address), and it does not require any special changes ^^^^^^^^^^^^^^^^^^^ > to any protocols. ^^^^^^^^^^^^^^^^ Are you sure about this? This is different from IPv4 "anycast". IPv6 anycast address cannot be used as a source address. Therefore, according to e.g.: draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt many DNS implementations may check the source address of the replies to the queries; thus use of anycast in this scenario might require protocol/implementation changes. > It does require anycast listening support and I don't > know of any platforms that currently have it. Someone on the list might > know more about implementations in the works. Anycast Listening is not a problem, e.g. KAME/BSD have had it for a long time now, USAGI for Linux just got it. FWIW, I've used IPv6 anycast address for about half a year in a 6to4 relay setup. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From mlehman@microsoft.com Wed Jan 9 19:38:05 2002 From: mlehman@microsoft.com (Matthew Lehman) Date: Wed, 9 Jan 2002 11:38:05 -0800 Subject: Question on address configuration Message-ID: > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, January 09, 2002 11:15 AM > To: Matthew Lehman > Cc: 6BONE List; Edward Lewis > Subject: RE: Question on address configuration > > On Wed, 9 Jan 2002, Matthew Lehman wrote: > > What about a well-known anycast address for the DNS server to listen on. > > The clients could use the well-known address and would only require > > configuration once, it's reasonably scalable (just add more DNS servers > > listening on the address), and it does not require any special changes > ^^^^^^^^^^^^^^^^^^^ > > to any protocols. > ^^^^^^^^^^^^^^^^ > > Are you sure about this? This is different from IPv4 "anycast". IPv6 > anycast address cannot be used as a source address. Therefore, according > to e.g.: > > draft-ietf-ipngwg-ipv6-anycast-analysis-00.txt > > many DNS implementations may check the source address of the replies to > the queries; thus use of anycast in this scenario might require > protocol/implementation changes. I agree. I just don't think getting the server or resolver to be anycast aware requires an rfc or new protocol. I do think there would need to be some implementations changes as I don't believe there is a way to make this work currently. I could be easily be wrong. > > It does require anycast listening support and I don't > > know of any platforms that currently have it. Someone on the list might > > know more about implementations in the works. > > Anycast Listening is not a problem, e.g. KAME/BSD have had it for a long > time now, USAGI for Linux just got it. > > FWIW, I've used IPv6 anycast address for about half a year in a 6to4 relay > setup. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From kre@munnari.OZ.AU Thu Jan 10 06:19:19 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 10 Jan 2002 13:19:19 +0700 Subject: Question on address configuration In-Reply-To: References: Message-ID: <2167.1010643559@brandenburg.cs.mu.OZ.AU> Date: Wed, 9 Jan 2002 08:10:21 -0800 From: "Matthew Lehman" Message-ID: | What about a well-known anycast address for the DNS server to listen on. This is a fine topic to discuss, though this is not really the right place, but it has nothing at all to do with the topic that was being discussed to which you replied. This thread used to be about a method to configure a node with a user selected 64 bit token (to use instead of the MAC address) and then have the node use that exactly as it would the MAC address for auto-configuration. Currently nodes (that most people seem to have seen anyway) allow only the MAC address to be used for autoconf of addresses (some may allow the MAC address to be altered, but doing that isn't the aim) - or they allow you to manually configure the whole address, which then requires knowledge of the prefix that apply to the link. How one finds DNS servers has nothing at all to do with this... kre From lewis@tislabs.com Thu Jan 10 14:48:08 2002 From: lewis@tislabs.com (Edward Lewis) Date: Thu, 10 Jan 2002 09:48:08 -0500 Subject: Question on address configuration In-Reply-To: <2167.1010643559@brandenburg.cs.mu.OZ.AU> References: Message-ID: At 1:19 AM -0500 1/10/02, Robert Elz wrote: >How one finds DNS servers has nothing at all to do with this... Your points up to this are accurate. But I wouldn't agree that there is no relationship to finding DNS servers. Reading the replies and thinking more about this situation (and why two of us IPv6 newcomers found this), we realized that this problem is rather DNS-centric. Any other server out there can use autoconfig with the MAC address and rely on DNS for name to number mapping. If the MAC card on, say, an SMTP server dies, a new one is installed and the DNS zone data modified. There are only two places a DNS server's IP has to be fixed. One is in the (pardon the UNIX-centricity here) /etc/resolve.conf file and in the server's delegating zone data (e.g., what Verisign says about your .com NS servers). Solving the /etc/resolv.conf problem can be done a few different ways (including putting recursive servers on site/local-addresses. But if the glue records can't be updated at the parent, this is a problem... One unwritten assumption I make in designing a DNS set up is to run two servers, one that is recursive (answering general questions) and another (set) that is authoritative (answering only specific questions). ("Why" is for the DNS mail lists.) So it seems natural to have some site-local addressed servers. However, this won't help me when I am on the road and dialing in via other networks. But then again neither will an anycast approach if name servers restrict whom they permit to launch recursive queries. (And thus we're back to why I need to set the IP[v6] address.) Hmmmm. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NAI Labs Phone: +1 443-259-2352 Email: lewis@tislabs.com Opinions expressed are property of my evil twin, not my employer. From wizard@italiansky.com Thu Jan 10 16:48:23 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Thu, 10 Jan 2002 17:48:23 +0100 Subject: Little question Message-ID: <006301c199f6$9e65a2b0$0700000a@local.comv6.com> This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C199FE.FFE4EB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi to all, i have a little question: while reading rfc 2546 regarding 6bone routing practice, i don't = understand very well what does it means when says "Site border router = MUST NOT advertise prefixes more specific than the /48 ones allocated by = their ISP."=20 I was looking in several rfcs regarding ipv6 about the possibility for = request a pTla using a private As number or the AS from the upstream = provider (reference to rfc2270, "Using a Dedicated AS for Sites Homed = to a Single Provider"). Can anyone help me? Thanks to all in advance=20 Matteo Tescione IP & Security Manager INCOM s.r.l.=20 Sitename:Comv6; www.comv6.com ------=_NextPart_000_0060_01C199FE.FFE4EB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi to all, i have a little = question:
while reading rfc 2546 regarding 6bone = routing=20 practice, i don't understand very well what does it means when says = "Site border=20 router MUST NOT advertise prefixes more specific than the /48 ones=20 allocated by their ISP."
I was looking in several rfcs = regarding ipv6=20 about the possibility for request a pTla using a private As number or = the AS=20 from the upstream provider (reference to rfc2270, "Using a Dedicated AS = for=20 Sites  Homed to a Single Provider").
Can anyone help = me?
Thanks to all in advance=20
 
Matteo Tescione
IP & Security Manager
INCOM s.r.l.
Sitename:Comv6; www.comv6.com
 
------=_NextPart_000_0060_01C199FE.FFE4EB60-- From fink@es.net Thu Jan 10 18:48:37 2002 From: fink@es.net (Bob Fink) Date: Thu, 10 Jan 2002 10:48:37 -0800 Subject: Little question In-Reply-To: <006301c199f6$9e65a2b0$0700000a@local.comv6.com> Message-ID: <5.1.0.14.0.20020110104433.00afebc8@imap2.es.net> Matteo, At 05:48 PM 1/10/2002 +0100, Matteo Tescione wrote: >Hi to all, i have a little question: >while reading rfc 2546 regarding 6bone routing practice, i don't >understand very well what does it means when says "Site border router MUST >NOT advertise prefixes more specific than the /48 ones allocated by their >ISP." RFC2546 is obsolete and replaced by RFC2772. You should read section 4 and then ask me specific questions you may have. >I was looking in several rfcs regarding ipv6 about the possibility for >request a pTla using a private As number or the AS from the upstream >provider (reference to rfc2270, "Using a Dedicated AS for Sites Homed to >a Single Provider"). We do not allocate pTLAs unless the requester has their own AS number for their exclusive IPv6 use (their IPv4 ASN will do). Bob From wizard@italiansky.com Thu Jan 10 19:39:27 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Thu, 10 Jan 2002 20:39:27 +0100 Subject: Little Problem Message-ID: <004101c19a0e$84285560$0700000a@local.comv6.com> This is a multi-part message in MIME format. ------=_NextPart_000_003E_01C19A16.E5A79E10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Bob, thanks a lot for your quick answer. Now everything is just most clear but in rfc2772 i can't see why a site without their own asn cannot use the upstream provider's asn to request = a pTLA. Can you explain me this? Best Regards, Matteo > ----- Original Message ----- > From: "Bob Fink" > To: "Matteo Tescione" > Cc: "6BONE List" <6bone@isi.edu> > Sent: Thursday, January 10, 2002 7:48 PM > Subject: Re: Little question > > > > Matteo, > > > > At 05:48 PM 1/10/2002 +0100, Matteo Tescione wrote: > > >Hi to all, i have a little question: > > >while reading rfc 2546 regarding 6bone routing practice, i don't > > >understand very well what does it means when says "Site border = router > MUST > > >NOT advertise prefixes more specific than the /48 ones allocated by their > > >ISP." > > > > RFC2546 is obsolete and replaced by RFC2772. You should read section = 4 and > > then ask me specific questions you may have. > > > > > > >I was looking in several rfcs regarding ipv6 about the possibility = for > > >request a pTla using a private As number or the AS from the = upstream > > >provider (reference to rfc2270, "Using a Dedicated AS for Sites = Homed to > > >a Single Provider"). > > > > We do not allocate pTLAs unless the requester has their own AS = number for > > their exclusive IPv6 use (their IPv4 ASN will do). > > > > > > Bob > > > ------=_NextPart_000_003E_01C19A16.E5A79E10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Bob,=20 thanks a lot for your quick answer.
Now everything is just most clear = but in=20 rfc2772 i can't see why a site
without their own asn cannot use the = upstream=20 provider's asn to request a
pTLA. Can you explain me this?
Best=20 Regards,
Matteo

> ----- Original Message -----
> = From: "Bob=20 Fink" <fink@es.net>
>=20 To: "Matteo Tescione" <wizard@italiansky.com>
> Cc: "6BONE List" = <6bone@isi.edu>
>=20 Sent: Thursday, January 10, 2002 7:48 PM
> Subject: Re: Little=20 question
>
>
> > Matteo,
> >
> > = At 05:48=20 PM 1/10/2002 +0100, Matteo Tescione wrote:
> > >Hi to all, i = have a=20 little question:
> > >while reading rfc 2546 regarding 6bone = routing=20 practice, i don't
> > >understand very well what does it = means when=20 says "Site border router
> MUST
> > >NOT advertise = prefixes=20 more specific than the /48 ones allocated by
their
> >=20 >ISP."
> >
> > RFC2546 is obsolete and replaced by = RFC2772.=20 You should read section 4
and
> > then ask me specific = questions you=20 may have.
> >
> >
> > >I was looking in = several=20 rfcs regarding ipv6 about the possibility for
> > >request a = pTla=20 using a private As number or the AS from the upstream
> > = >provider=20 (reference to rfc2270, "Using a Dedicated AS for Sites  = Homed
to
>=20 > >a Single Provider").
> >
> > We do not = allocate pTLAs=20 unless the requester has their own AS number
for
> > their = exclusive=20 IPv6 use (their IPv4 ASN will do).
> >
> >
> = >=20 Bob
> >
>
------=_NextPart_000_003E_01C19A16.E5A79E10-- From fink@es.net Thu Jan 10 20:27:55 2002 From: fink@es.net (Bob Fink) Date: Thu, 10 Jan 2002 12:27:55 -0800 Subject: Little Problem In-Reply-To: <004101c19a0e$84285560$0700000a@local.comv6.com> Message-ID: <5.1.0.14.0.20020110122625.0638ed68@imap2.es.net> At 08:39 PM 1/10/2002 +0100, Matteo Tescione wrote: >Hello Bob, thanks a lot for your quick answer. >Now everything is just most clear but in rfc2772 i can't see why a site >without their own asn cannot use the upstream provider's asn to request a >pTLA. Can you explain me this? If you are a pTLA their is no upstream IPv6 provider. If you mean use your IPv4 provider's ASN, then you prevent them from ever using it for v6 and I'm sure they wouldn't like that :-) The issue is having a unique ASN in the global routing infrastructure. Bob From Marc.Blanchet@viagenie.qc.ca Fri Jan 11 20:29:33 2002 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Fri, 11 Jan 2002 15:29:33 -0500 Subject: Little Problem In-Reply-To: <5.1.0.14.0.20020110122625.0638ed68@imap2.es.net> References: <5.1.0.14.0.20020110122625.0638ed68@imap2.es.net> Message-ID: <125490000.1010780973@classic> another twist on the same line, trying to help: - you could use private AS numbers to do peering for some reasons - however, to be a pTLA, then you need an allocated AS number, unique, so that your routes are tagged to you on the global routing table. Marc. -- jeudi, janvier 10, 2002 12:27:55 -0800 Bob Fink wrote/a écrit: > At 08:39 PM 1/10/2002 +0100, Matteo Tescione wrote: >> Hello Bob, thanks a lot for your quick answer. >> Now everything is just most clear but in rfc2772 i can't see why a site >> without their own asn cannot use the upstream provider's asn to request a >> pTLA. Can you explain me this? > > If you are a pTLA their is no upstream IPv6 provider. If you mean use > your IPv4 provider's ASN, then you prevent them from ever using it for v6 > and I'm sure they wouldn't like that :-) > > The issue is having a unique ASN in the global routing infrastructure. > > > Bob > ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From rrockell@sprint.net Fri Jan 11 21:35:13 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Fri, 11 Jan 2002 16:35:13 -0500 (EST) Subject: Little Problem In-Reply-To: <125490000.1010780973@classic> Message-ID: Optimally, if we follow *current* aggregation rules, one would never need an ASN, except in pTLA situation, as different block allocated per upstream 'provider'... so static routing works fine. Just my $.02 Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia (+1) 703-689-6322 Sprint IP Services : Thinking outside the 435 box ----------------------------------------------------------------------- On Fri, 11 Jan 2002, Marc Blanchet wrote: ->another twist on the same line, trying to help: ->- you could use private AS numbers to do peering for some reasons ->- however, to be a pTLA, then you need an allocated AS number, unique, so ->that your routes are tagged to you on the global routing table. -> ->Marc. -> -> ->-- jeudi, janvier 10, 2002 12:27:55 -0800 Bob Fink wrote/a ->écrit: -> ->> At 08:39 PM 1/10/2002 +0100, Matteo Tescione wrote: ->>> Hello Bob, thanks a lot for your quick answer. ->>> Now everything is just most clear but in rfc2772 i can't see why a site ->>> without their own asn cannot use the upstream provider's asn to request a ->>> pTLA. Can you explain me this? ->> ->> If you are a pTLA their is no upstream IPv6 provider. If you mean use ->> your IPv4 provider's ASN, then you prevent them from ever using it for v6 ->> and I'm sure they wouldn't like that :-) ->> ->> The issue is having a unique ASN in the global routing infrastructure. ->> ->> ->> Bob ->> -> -> -> ->------------------------------------------ ->Marc Blanchet ->Viagénie ->tel: +1-418-656-9254x225 -> ->------------------------------------------ ->http://www.freenet6.net: IPv6 connectivity ->------------------------------------------ ->http://www.normos.org: IETF(RFC,draft), -> IANA,W3C,... standards. ->------------------------------------------ -> From michel@arneill-py.sacramento.ca.us Sat Jan 12 04:30:54 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 11 Jan 2002 20:30:54 -0800 Subject: Little Problem Message-ID: <2B81403386729140A3A899A8B39B046405DE41@server2000.arneill-py.sacramento.ca.us> Robert, >> Marc Blanchet wrote: >> another twist on the same line, trying to help: >> you could use private AS numbers to do peering for some reasons >> however, to be a pTLA, then you need an allocated AS number, unique, so >> that your routes are tagged to you on the global routing table. > Robert J. Rockell wrote: > Optimally, if we follow *current* aggregation rules, one would never > need an ASN, except in pTLA situation, as different block allocated > per upstream 'provider'... so static routing works fine. Just my $.02 This is not correct. By looking at my own situation: I am dual-homed (IPv6) to two different pTLAs (Viagenie and Caladan). I have BGP peering with both using a private BGP ASN (#65432). Although there are ways around that (complicated ones), the main reason it actually works is because nobody else is using that ASN. World, please take note: ASN #65432 (easy to remember) is no longer public but now the exclusive property of Michel Py. How easy, I did not even have to register for it hehehehe. I have missed the beginning of this thread (maybe it started on a list that I di not subscribe to), but in the current situation people that are NOT pTLAs still need an ASN if there are multihomed. Michel. From 6BONE List <6bone@ISI.EDU> Sat Jan 12 13:46:35 2002 From: 6BONE List <6bone@ISI.EDU> (Paul Aitken) Date: Sat, 12 Jan 2002 13:46:35 +0000 Subject: Little Problem References: <2B81403386729140A3A899A8B39B046405DE41@server2000.arneill-py.sacramento.ca.us> Message-ID: <3C403E3B.2030903@cisco.com> Michel Py wrote: > I am dual-homed (IPv6) to two different pTLAs (Viagenie and Caladan). > I have BGP peering with both using a private BGP ASN (#65432). > > Although there are ways around that (complicated ones), the main reason > it actually works is because nobody else is using that ASN. At least, nobody else at Viagenie and Caladan ;) > World, please take note: ASN #65432 (easy to remember) is no longer > public but now the exclusive property of Michel Py. No it's not. You just need to arrange this with Viagenie and Caladan. They should be filtering routes that use private ASN's so those ASN's can be reused elsewhere. See http://www.cisco.com/warp/customer/459/32.html and http://www.cisco.com/warp/customer/459/36.html. The examples are IPv4, but the same commands work equally well for IPv6. Having said that, I do see a few private ASN's in use: 64700, 65001, 65302, 65304, 65305 and 65525. Hmmm. > in the current situation people that > are NOT pTLAs still need an ASN if there are multihomed. You only need an ASN if you're using BGP, and not everyone is. But true, being multihomed without BGP (and therefore your own ASN) would be pointless. -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. From michel@arneill-py.sacramento.ca.us Sat Jan 12 16:34:33 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 12 Jan 2002 08:34:33 -0800 Subject: Little Problem Message-ID: <2B81403386729140A3A899A8B39B046403D649@server2000.arneill-py.sacramento.ca.us> Paul, >> Michel Py wrote: >> I am dual-homed (IPv6) to two different pTLAs (Viagenie and Caladan). >> I have BGP peering with both using a private BGP ASN (#65432). >> Although there are ways around that (complicated ones), the main reason >> it actually works is because nobody else is using that ASN. > Paul Aitken wrote: > At least, nobody else at Viagenie and Caladan ;) Correct. However, if everyone did that, we would quickly have collisions among the 1,000 or so available private ASNs. I do not think pTLAs have a srong interest in maintaining a list of private ASNs they peer with. >> World, please take note: ASN #65432 (easy to remember) is no longer >> public but now the exclusive property of Michel Py. > No it's not. Nice try, no cigar. > You just need to arrange this with Viagenie and Caladan. They > should be filtering routes that use private ASN's so those ASN's > can be reused elsewhere. I think they do. > Having said that, I do see a few private ASN's in use: 64700, 65001, > 65302, 65304, 65305 and 65525. Hmmm. In the 6bone context, I do not see a problem with that, but it does not scale at all. If BGP is to be used in any form or fashion for IPv6 multihoming, we will soon need 32-bit ASNs. Michel. From Marc.Blanchet@viagenie.qc.ca Sat Jan 12 21:46:26 2002 From: Marc.Blanchet@viagenie.qc.ca (Marc Blanchet) Date: Sat, 12 Jan 2002 16:46:26 -0500 Subject: Little Problem In-Reply-To: <2B81403386729140A3A899A8B39B046405DE41@server2000.arneill-py.sacramento.ca.us> References: <2B81403386729140A3A899A8B39B046405DE41@server2000.arneill-py.sa cramento.ca.us> Message-ID: <14090000.1010871985@classic> -- vendredi, janvier 11, 2002 20:30:54 -0800 Michel Py wrote/a écrit: > Robert, > >>> Marc Blanchet wrote: >>> another twist on the same line, trying to help: >>> you could use private AS numbers to do peering for some reasons >>> however, to be a pTLA, then you need an allocated AS number, unique, > so >>> that your routes are tagged to you on the global routing table. > >> Robert J. Rockell wrote: >> Optimally, if we follow *current* aggregation rules, one would never >> need an ASN, except in pTLA situation, as different block allocated >> per upstream 'provider'... so static routing works fine. Just my $.02 > > This is not correct. By looking at my own situation: > I am dual-homed (IPv6) to two different pTLAs (Viagenie and Caladan). > I have BGP peering with both using a private BGP ASN (#65432). I need to look at our configuration (I no longer daily managing it: I'll check and come back about it) but normally, we (your peer) should not advertise a private ASN to the rest of the world, (i.e. you routes should not be specifically advertise with this AS) so are you sure that you are really multihomed in the global routing table? if yes, then you got a free ticket that may not stay long... ;-)) Marc. > > Although there are ways around that (complicated ones), the main reason > it > actually works is because nobody else is using that ASN. > > World, please take note: ASN #65432 (easy to remember) is no longer > public > but now the exclusive property of Michel Py. > How easy, I did not even have to register for it hehehehe. > > I have missed the beginning of this thread (maybe it started on a list > that I di not subscribe to), but in the current situation people that > are NOT pTLAs still need an ASN if there are multihomed. > > Michel. ------------------------------------------ Marc Blanchet Viagénie tel: +1-418-656-9254x225 ------------------------------------------ http://www.freenet6.net: IPv6 connectivity ------------------------------------------ http://www.normos.org: IETF(RFC,draft), IANA,W3C,... standards. ------------------------------------------ From michel@arneill-py.sacramento.ca.us Sat Jan 12 22:16:29 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 12 Jan 2002 14:16:29 -0800 Subject: Little Problem Message-ID: <2B81403386729140A3A899A8B39B046405DE43@server2000.arneill-py.sacramento.ca.us> Marc, > Marc Blanchet wrote: > I need to look at our configuration (I no longer daily managing it: > I'll check and come back about it) but normally, we (your peer) > should not advertise a private ASN to the rest of the world, > (i.e. you routes should not be specifically advertise with this AS) Correct; my routes should not been advertised at all, actually. > so are you sure that you are really multihomed in the global > routing table? I'm sure I am not, but not because "my" private ASN is being filtered (it does not matter). Because none of my /48 prefixes are making it back to the DFZ, because they are summarized, which is the way it should be. Since there is no IPv6 multihoming solution as we speak, I just have manual redundancy. > If yes, then you got a free ticket that may not stay long... ;-)) You are making my point; I should not have to hijack a private ASN. Michel. From kre@munnari.OZ.AU Mon Jan 14 14:22:30 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 14 Jan 2002 21:22:30 +0700 Subject: Question on address configuration In-Reply-To: References: Message-ID: <5876.1011018150@brandenburg.cs.mu.OZ.AU> Date: Thu, 10 Jan 2002 09:48:08 -0500 From: Edward Lewis Message-ID: | Your points up to this are accurate. But I wouldn't agree that there is no | relationship to finding DNS servers. You're arguing yet another point, unrelated to either of the other ones. Or perhaps slightly related to the original, but not at all to the other one. | Reading the replies and thinking more about this situation (and why two of | us IPv6 newcomers found this), we realized that this problem is rather | DNS-centric. No, that's just one use. | Any other server out there can use autoconfig with the MAC | address and rely on DNS for name to number mapping. Sure, they can. But it isn't an issue of who can do what, but who must do what. I can use MAC address based tokens for my systems, and usually, that's what I'll do. But I have a choice, I can use anything I like, any numbering scheme I prefer, and if I choose to number my systems 1 2 3 ... in the expectation that I can keep doing that for eternity, using a new unique number for for each new system (or even redefined system) without ever running out of the 64 bit space, then I should be permitted to do just that. I might need to use a DHCP server to make my admin load manageable of course, or I might just configure the number in the system if I have a centralised systems receiving dept, where everything is delivered and locally configured before being sent to the end user. If I'm using a DHCP server though, at the very least I'm going to have to configure its address, not because it needs to be stable, but because it has no DHCP server to request an address from. And it can't simply use its MAC address, as someday that might clash with my 1 2 3 ... (after I eventually have to give up on keeping the meaning of the "global" bit...) In any case, this is an issue of choice, in IPv6 we have 3 methods of address generation - autoconfigured from MAC address, assigned by a DHCP server, and manually configured. We shouldn't be causing the 3rd one to be harder than it should otherwise be, nor should we be causing other problems (like making it much harder to renumber a network) just because people would like to manually configure the part of their addresses that they get to assign (in both v4 and v6 you're stuck with the prefix offered to you if you want to interoperate, but in both you can be as imaginative as you like with the remaining bits). Certainly DNS servers, DHCP servers, routers, and even SMTP servers (thanks all the same, but I don't want a 2 day mail dead spot while my old DNS records TTL times out...) are the most likely candidates for configured addresses, but any host can have it. Implementations that I'm aware of all allow this already - all they don't do is the compromise where the prefix comes from RA messages (just like fully autoconfigured addresses), and the token comes from configuration. This really should be added. kre From fink@es.net Tue Jan 15 17:05:52 2002 From: fink@es.net (Bob Fink) Date: Tue, 15 Jan 2002 09:05:52 -0800 Subject: new threaded 6bone mail archive Message-ID: <5.1.0.14.0.20020115090537.00a750b8@imap2.es.net> 6bone folk, Recently the WWU maintained threaded mail archive for the 6bone has departed. Will Maton has kindly arranged for a new threaded 6bone mail archive. The 6bone web page has been updated. Thanks to Will. In addition, the flat 6bone mail archive had a lost path to the real archive. This has now been fixed and the entire flat archive is again available. Thanks to Bill Manning and our friends at ISI. Bob From fink@es.net Wed Jan 16 01:08:19 2002 From: fink@es.net (Bob Fink) Date: Tue, 15 Jan 2002 17:08:19 -0800 Subject: pTLA request for T-NET - review closes 11 February 2002 Message-ID: <5.1.0.14.0.20020115165756.031c3da0@imap2.es.net> 6bone Folk, T-NET has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 11 February 2002 (an extended time as I will be on travel 24 Jan - 10 Feb). Please send your comments to me or the list. Thanks, Bob === >Hi Bob, > >I'd like to request a pTLA for T-NET, please find relevant info below. > >Sincerely, > >Krisztian Vago > >------------------------------------------------------------------------- >7. Guidelines for 6Bone pTLA sites > > The following rules apply to qualify for a 6Bone pTLA allocation. It > should be recognized that holders of 6Bone pTLA allocations are > expected to provide production quality backbone network services for > the 6Bone. > > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. During > the entire qualifying period the Applicant must be operationally > providing the following: > >T-NET is in 6bone since March of 2001 > > > a. Fully maintained, up to date, 6Bone Registry entries for their > ipv6-site inet6num, mntner, and person objects, including each > tunnel that the Applicant has. > >ipv6-site: T-NET >origin: AS1955 Insered explanation of use of AS1955 >HUNGARNET is an association and also the computer network of Hungarian >institutions ofhigher education, research and development, libraries and >other public collections.HUNGARNET as an association represents Hungary >in the international networking organizations. >MADNET is a network at Marton Aron Dormitory. We have five dormitories in >Hungary and we have more or less 9000-10000 students. >Our network is a very special network in Hungary. >We are belong to Computer and Automation Research Institute, Hungarian >Academy of Sciences network (SZTAKI) and we are connected via IIF >(National Information Infrastucture Development Program) >We are the only network in Hungary which is in favour Ministry of Culture >and Education. >We are totaly state-owned network and our projects are spoonfeeded. Via >IIF (and SZTAKI) we are authorized using ASn 1955 for IPv6 activites in >6Bone. End insert >descr: T-NET Project > Budapest, Hungary >country: HU >prefix: 3FFE:400:1090::/48 >prefix: 3FFE:8120:FFFD::/48 >prefix: 3FFE:1001:560::/48 >prefix: 3FFE:200:45::/48 >application: ping 6bone-gw.asterix.gimp.hu >application: www www.ipv6.asterix.gimp.hu >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >6bone.uni-muenster.de JOIN BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >6bone-gw.zapor-u.gtnet.hu ZAPOR-U BGP4+ >tunnel: IPv6 in IPv6 6bone-gw.asterix.gimp.hu -> asterix.mad.hu >ASTERIX BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >holub.satimex.tvnet.hu FAKONET STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> mail.ithink.hu >FAKONET STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >parbb1.routers.fr.fastnetxp.net FASTNETXP BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >6bone-gw.ipv6.sics.se SICS STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> ns.bgyarmat.hu >BGYARMAT STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> gw.6b0ne.hu PAMPI BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> cern-atm7.cern.ch >CERN BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >lon2-dr61.v6.eu.ntt.net TLA-2001 STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >6bone-gw1.edisontel.it EDISONTEL BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> 6bone.ircnet.hu >GTNET BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> rtr1.ipv6.he.net >HURRICANE BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> rap.viagenie.qc.ca >VIAGENIE BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> 6bone-gw3.cselt.it >CSELT BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> 6b1.ams7.nl.uu.net >NLNET BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >gep18-1762.nyircatv.broadband.hu D-BOX STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >server.komjata-koll.sulinet.hu DR-AGON STATIC >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> puffi.pszfb.hu >PUFFI-NET STATIC >tunnel: IPv6 in IPV6 6bone-gw.asterix.gimp.hu -> ipv6.bitchx.hu TEMA >BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >B945-5F50.newrange.tvnetwork.hu KV1-6BONE BGP4+ >tunnel: IPv6 in IPv4 6bone-gw.asterix.gimp.hu -> >maximus.linuxnetwork.hu LINUXNETWORK6 STATIC >contact: TNET1-6BONE >contact: TTN1-6BONE >contact: PR3-6BONE >contact: SS9-6BONE >remarks: FreeBSD router running MRT routing daemon >remarks: ipv6-site is operational >remarks: primary DNS server ns1.asterix.gimp.hu is operational >remarks: secondary DNS server ns2.asterix.gimp.hu is operational >url: http://www.ipv6.asterix.gimp.hu >mnt-by: MNT-T-NET >changed: vagok@asterix.direct.hu 20011227 >changed: vagok@asterix.gimp.hu 20020112 >source: 6BONE > > > > b. Fully maintained, and reliable, BGP4+ peering and connectivity > between the Applicant's boundary router and the appropriate > connection point into the 6Bone. This router must be IPv6 > pingable. This criteria is judged by members of the 6Bone > Operations Group at the time of the Applicant's pTLA request. > >We have BGP connection with JOIN CERN CSELT NLNET EDISONTEL VIAGENIE ... > >Our router (6bone-gw.asterix.gimp.hu) is IPv6 pingable. > > c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) > entries for the Applicant's router(s) and at least one host > system. > > >host -t aaaa 6bone-gw.asterix.gimp.hu > 6bone-gw.asterix.direct.hu IPv6 address 3ffe:400:1090:0:a00:36ff:fe64:6903 > 6bone-gw.asterix.direct.hu IPv6 address 3ffe:8120:fffd:0:a00:36ff:fe64:6903 > >host -t ptr >3.0.9.6.4.6.e.f.f.f.6.3.0.0.a.0.0.0.0.0.0.9.0.1.0.0.4.0.e.f.f.3.ip6.int > 3.0.9.6.4.6.e.f.f.f.6.3.0.0.a.0.0.0.0.0.0.9.0.1.0.0.4.0.e.f.f.3.ip6.int > domain name pointer 6bone-gw.asterix.gimp.hu > >primary DNS server ns1.asterix.gimp.hu >secondary DNS server ns2.asterix.gimp.hu > > d. A fully maintained, and reliable, IPv6-accessible system > providing, at a mimimum, one or more web pages, describing the > Applicant's IPv6 services. This server must be IPv6 pingable. > >We have IPv6 www (www6.asterix.gimp.hu) ftp (ftp6.asterix.gimp.hu), >telnet, and pop3 services. > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. Applicants must > provide a statement and information in support of this claim. > This MUST include the following: > > a. A support staff of two persons minimum, three preferable, with > person attributes registered for each in the ipv6-site object > for the pTLA applicant. > > contact: PR3-6BONE > contact: TTN1-6BONE > contact: SS9-6BONE > > b. A common mailbox for support contact purposes that all support > staff have acess to, pointed to with a notify attribute in the > ipv6-site object for the pTLA Applicant. > > >person: T-Net Project Team >address: Kunigunda u.35 B-436 >address: 1037 Budapest >address: Hungary >phone: +36 20 9357523 >e-mail: ipv6@asterix.gimp.hu >nic-hdl: TNET1-6BONE >notify: ipv6@asterix.gimp.hu >mnt-by: MNT-T-NET >changed: auto-dbm@whois.6bone.net 20011029 >changed: vagok@asterix.gimp.hu 20020112 >source: 6BONE > > 3. The pTLA Applicant MUST have a potential "user community" that > would be served by its becoming a pTLA, e.g., the Applicant is a > major provider of Internet service in a region, country, or focus > of interest. Applicant must provide a statement and information in > support this claim. > >We have five dormitories in Hungary which connected via us to >IPv6. Our dormitories have relationship with: > >ELTE - Eotvos Lorand University of Sciences >BMF - Technical College of Budapest >PSZFB - College of Finance and Accountancy >PTE - Pecs University > >Now there is two college (PSZFB, BMF - Kando - ) which are connected to >IPv6 network via us. We have IPv6 connection with SULINET (solution for >inernet access to primary and high schools). And we have a few private >tunnels. > >We are planing building IPv6 connection with the other universities as >well. Otherwhise we offer connection to IPv6 everyone who would like to >join. Other small projects (GTNET, PAMPI, TEMA) will be integrated to >T-NET in the near future. > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus of the > 6Bone backbone and user community. > >We agree with any current and any future 6Bone operational rules and >policies. > > 8. 6Bone Operations Group > > The 6Bone Operations Group is the group in charge of monitoring and > policing adherence to the current rules. Membership in the 6Bone > Operations Group is mandatory for, and restricted to, sites connected > to the 6Bone. > > The 6Bone Operations Group is currently defined by those members of > the existing 6Bone mailing list who represent sites participating in > the 6Bone. Therefore it is incumbent on relevant site contacts to > join the 6Bone mailing list. Instructions on how to join the list are > maintained on the 6Bone web site at < http://www.6bone.net>. > >I have joined the mailinglist. > >------------------------------------------------------------------------------- From nsayer@quack.kfu.com Wed Jan 16 15:13:50 2002 From: nsayer@quack.kfu.com (Nick Sayer) Date: Wed, 16 Jan 2002 07:13:50 -0800 Subject: Question on address configuration References: <5876.1011018150@brandenburg.cs.mu.OZ.AU> Message-ID: <3C4598AE.9040700@quack.kfu.com> Robert Elz wrote: > >Certainly DNS servers, DHCP servers, routers, and even SMTP servers (thanks >all the same, but I don't want a 2 day mail dead spot while my old DNS >records TTL times out...) are the most likely candidates for configured >addresses, but any host can have it. Implementations that I'm aware of >all allow this already - all they don't do is the compromise where the >prefix comes from RA messages (just like fully autoconfigured addresses), >and the token comes from configuration. This really should be added. > >kre > Everything you said is true, but I would add the small postscript that in 99% of the cases where you would find it truly desirable to set up a well known address, you would be better off making that address site-local rather than based on the (routable) prefix. Your arguments about an SMTP server's DNS TTL can be made about any DNS records -- if the TTLs are causing you heartburn you should lower them. People typically want to configure manual addresses so that they don't have to keep rewriting resolv.conf files (or equiv). The best way to handle that is to look at the latest DNS autolocation draft (I forget the name offhand), which suggests fec0:0:0:ffff::[1,2,3]. Doing this you won't have to *ever* change references to the server even if your prefix changes. You are right, however, in that since the spec allows even pointless silly behavior implementations should be prepared for it. Perhaps those implementations that use rtsol (kame) can modify rtsol to provide an additional argument to allow you to specify the suffix. From mlehman@microsoft.com Wed Jan 16 16:16:20 2002 From: mlehman@microsoft.com (Matthew Lehman) Date: Wed, 16 Jan 2002 08:16:20 -0800 Subject: Question on address configuration Message-ID: > -----Original Message----- > From: Nick Sayer [mailto:nsayer@quack.kfu.com] > Sent: Wednesday, January 16, 2002 7:14 AM > To: Robert Elz > Cc: Edward Lewis; 6BONE List > Subject: Re: Question on address configuration > > Robert Elz wrote: > > > > >Certainly DNS servers, DHCP servers, routers, and even SMTP servers > (thanks > >all the same, but I don't want a 2 day mail dead spot while my old DNS > >records TTL times out...) are the most likely candidates for configured > >addresses, but any host can have it. Implementations that I'm aware of > >all allow this already - all they don't do is the compromise where the > >prefix comes from RA messages (just like fully autoconfigured addresses), > >and the token comes from configuration. This really should be added. > > > >kre > > > Everything you said is true, but I would add the small postscript that > in 99% of the cases where you would find it truly desirable to set up a > well known address, you would be better off making that address > site-local rather than based on the (routable) prefix. Your arguments > about an SMTP server's DNS TTL can be made about any DNS records -- if > the TTLs are causing you heartburn you should lower them. People > typically want to configure manual addresses so that they don't have to > keep rewriting resolv.conf files (or equiv). The best way to handle that > is to look at the latest DNS autolocation draft (I forget the name > offhand), which suggests fec0:0:0:ffff::[1,2,3]. Doing this you won't > have to *ever* change references to the server even if your prefix > changes. I think the draft Nick is referencing is at: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-03.t xt There's also a related draft at: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-anal ysis-00.txt > > You are right, however, in that since the spec allows even pointless > silly behavior implementations should be prepared for it. Perhaps those > implementations that use rtsol (kame) can modify rtsol to provide an > additional argument to allow you to specify the suffix. > > From mcr@sandelman.ottawa.on.ca Wed Jan 16 21:26:39 2002 From: mcr@sandelman.ottawa.on.ca (Michael Richardson) Date: Wed, 16 Jan 2002 16:26:39 -0500 Subject: Question on address configuration In-Reply-To: Your message of "Wed, 16 Jan 2002 07:13:50 PST." <3C4598AE.9040700@quack.kfu.com> Message-ID: <200201162126.g0GLQd815381@marajade.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Nick" == Nick Sayer writes: Nick> Everything you said is true, but I would add the small postscript Nick> that in 99% of the cases where you would find it truly desirable to Nick> set up a well known address, you would be better off making that Nick> address site-local rather than based on the (routable) prefix. Your I agree. But it doesn't change the fact that I have to put something in my parent zone's NS record, and I'd rather it was stable - this is a consideration independant of address renumbering. This has to do with surviving hardware failures, etc... ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPEXwDYqHRg3pndX9AQGfGwQA2Z43Ftwwc/kdAG4y9/pSLFCD4zWlKNrj w5EgZoa/H46gfWl/FhTrz9DhfRTFw+6o69kQi1+bTg/dniZNbLZEQDK3144iWnzu Dhmf/HBnRl6ZuzFWMJrA2zGJuCYegUhmGG5wa+q/hrQ/TwWno5Q9cgwyhAdXS/3p Vg9Gwlxoexc= =98BI -----END PGP SIGNATURE----- From itojun@iijlab.net Thu Jan 17 02:32:19 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Thu, 17 Jan 2002 11:32:19 +0900 Subject: bogus route: 2001::/16 Message-ID: <13552.1011234739@itojun.org> we are seeing a bogus route, namely 2001::/16, advertised from AS 1003. please stop it. thanks. itojun bgpd@otm6-gate1# sh ipv6 bgp 2001::/16 BGP routing table entry for 2001::/16 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 2001:200:0:1800::9c4:0 2001:200:0:1800::12a9:1 2001:200:0:1800::2513:0 2001:200:0:1800::2516:1 2001:200:0:1800::2518:1 2001:200:0:1800::2527:1 2001:200:0:1800::4697:1 2001:200:0:1800::4716:1 2001:200:0:1800::4725:1 2001:200:0:1800::6461:1 2001:200:0:1800::7514:1 2001:200:0:1800::9600:1 2001:200:0:1800:0:1:13:0 2001:200:0:1800:0:1:7522:0 2001:200:0:1800:200:f8ff:fe01:6c53 2001:200:0:1800:2e0:b0ff:fe2d:1f01 2001:240:100:ff::1 2001:240:100:ff::2 2500 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 2001:200:0:1800::9c4:0 from 2001:200:0:1800::9c4:0 (203.178.140.203) (fe80::9c4:0) Origin incomplete, localpref 100, valid, external Last update: Thu Jan 17 08:40:26 2002 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 2001:200:0:1800::4691:1 from 2001:200:0:1800::4691:1 (203.181.69.181) Origin incomplete, metric 3, localpref 100, valid, external, best Last update: Thu Jan 17 08:40:16 2002 From kfarnes@qinetiq.com Thu Jan 17 09:26:37 2002 From: kfarnes@qinetiq.com (Kevin Farnes) Date: Thu, 17 Jan 2002 09:26:37 +0000 Subject: Creating an ipv6-site object Message-ID: <3C4698CD.3562.4BFBAE@localhost> I am in the process of trying to establish an IPv6 tunnel from our site. I am trying to setup the relevant ipv6-site object within the registry. Unfortunately I have a slight problem. One of the required fields is the Origin field, the AS number advertising the router. Unfortunately I don't have my own AS number. What should I put in this field to allow me to create the ipv6-object? Should it be the AS number of the pTLA/pNLA providing my connection? Your help would be appreciated. Kevin Farnes Senior Engineer QinetiQ kfarnes@qinetiq.com---------------------------------------------------------- Mr. K. Farnes Senior Engineer North Site A114, QinetiQ, St. Andrews Rd, Malvern, Worcs, WR14 3PS UK Tel : +44 (0)1684 894156 Fax : +44 (0)1684 894303 E-Mail : kfarnes@qinetiq.com ---------------------------------------------------------- From pekkas@netcore.fi Thu Jan 17 09:39:42 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 17 Jan 2002 11:39:42 +0200 (EET) Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa Message-ID: Hi, As ip6.arpa has been BCP for some time now, would it make sense to delegate the reverses under ip6.arpa to all pTLA's, to the same servers as with ip6.int? (at the moment, not even e.f.f.3.ip6.arpa has been delegated.) There are resolvers using only ip6.arpa already. (Whether that's a wise transition decision is another question, but it does conform to *best* current practise :-). E.g. reverses in RIPE-assigned 2001::/16 -addresses were delegated in this fashion and work great. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From ggm@apnic.net Thu Jan 17 11:52:55 2002 From: ggm@apnic.net (George Michaelson) Date: Thu, 17 Jan 2002 21:52:55 +1000 Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: Your message of "Thu, 17 Jan 2002 11:39:42 +0200." Message-ID: <24681.1011268375@apnic.net> > E.g. reverses in RIPE-assigned 2001::/16 -addresses were delegated in this > fashion and work great. For APNIC we have decided to pre-seed the whois structures with records taken from ip6.int which are modified to block zonefile creation, which means delegated parties can open it up when they are happy their local server can handle ip6.arpa reverses, using normal Regional Internet Registry methods to modify their whois domain: object. So far only a small handful of people have ip6.arpa delegations, and I suspect only a small amount of resolver software handles it, so dual delegation might be wise for some time. Maybe when its more 50:50 we'll cut over so ip6.int is made a clone of ip6.arpa instead. cheers -George -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net From wizard@italiansky.com Thu Jan 17 12:58:54 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Thu, 17 Jan 2002 13:58:54 +0100 Subject: Creating an ipv6-site object References: <3C4698CD.3562.4BFBAE@localhost> Message-ID: <000e01c19f56$b8071400$8cf51150@local.comv6.com> Kevin, if you don't have an Asn you can use one of the private range... what kind of peering your think about? Matteo ----- Original Message ----- From: "Kevin Farnes" To: <6bone@ISI.EDU> Sent: Thursday, January 17, 2002 10:26 AM Subject: Creating an ipv6-site object > I am in the process of trying to establish an IPv6 tunnel from our > site. I am trying to setup the relevant ipv6-site object within the > registry. Unfortunately I have a slight problem. > > One of the required fields is the Origin field, the AS number > advertising the router. Unfortunately I don't have my own AS > number. What should I put in this field to allow me to create the > ipv6-object? Should it be the AS number of the pTLA/pNLA > providing my connection? > > Your help would be appreciated. > > Kevin Farnes > Senior Engineer > QinetiQ > kfarnes@qinetiq.com--------------------------------------------------------- - > Mr. K. Farnes > Senior Engineer > North Site A114, QinetiQ, > St. Andrews Rd, Malvern, > Worcs, WR14 3PS > UK > Tel : +44 (0)1684 894156 Fax : +44 (0)1684 894303 > E-Mail : kfarnes@qinetiq.com > ---------------------------------------------------------- > From rrockell@sprint.net Thu Jan 17 13:14:11 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 17 Jan 2002 08:14:11 -0500 (EST) Subject: bogus route: 2001::/16 In-Reply-To: <13552.1011234739@itojun.org> Message-ID: Hello, I remember we spoke about connecting at Ny6ix? I am at the IX now, and as soon as my cross-connect is made, we should be able to speak IPv6 at that site. Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia (+1) 703-689-6322 Sprint IP Services : Thinking outside the 435 box ----------------------------------------------------------------------- On Thu, 17 Jan 2002 itojun@iijlab.net wrote: -> we are seeing a bogus route, namely 2001::/16, advertised from -> AS 1003. please stop it. thanks. -> ->itojun -> -> ->bgpd@otm6-gate1# sh ipv6 bgp 2001::/16 ->BGP routing table entry for 2001::/16 ->Paths: (2 available, best #2, table Default-IP-Routing-Table) -> Advertised to non peer-group peers: -> 2001:200:0:1800::9c4:0 2001:200:0:1800::12a9:1 2001:200:0:1800::2513:0 2001:200:0:1800::2516:1 2001:200:0:1800::2518:1 2001:200:0:1800::2527:1 2001:200:0:1800::4697:1 2001:200:0:1800::4716:1 2001:200:0:1800::4725:1 2001:200:0:1800::6461:1 2001:200:0:1800::7514:1 2001:200:0:1800::9600:1 2001:200:0:1800:0:1:13:0 2001:200:0:1800:0:1:7522:0 2001:200:0:1800:200:f8ff:fe01:6c53 2001:200:0:1800:2e0:b0ff:fe2d:1f01 2001:240:100:ff::1 2001:240:100:ff::2 -> 2500 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 -> 2001:200:0:1800::9c4:0 from 2001:200:0:1800::9c4:0 (203.178.140.203) -> (fe80::9c4:0) -> Origin incomplete, localpref 100, valid, external -> Last update: Thu Jan 17 08:40:26 2002 -> -> 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 -> 2001:200:0:1800::4691:1 from 2001:200:0:1800::4691:1 (203.181.69.181) -> Origin incomplete, metric 3, localpref 100, valid, external, best -> Last update: Thu Jan 17 08:40:16 2002 -> From rrockell@sprint.net Thu Jan 17 13:14:32 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 17 Jan 2002 08:14:32 -0500 (EST) Subject: bogus route: 2001::/16 In-Reply-To: <13552.1011234739@itojun.org> Message-ID: Sorry to cc list. That was not meant for 6bone@isi.edu... maybe manning still moderates :) Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia (+1) 703-689-6322 Sprint IP Services : Thinking outside the 435 box ----------------------------------------------------------------------- On Thu, 17 Jan 2002 itojun@iijlab.net wrote: -> we are seeing a bogus route, namely 2001::/16, advertised from -> AS 1003. please stop it. thanks. -> ->itojun -> -> ->bgpd@otm6-gate1# sh ipv6 bgp 2001::/16 ->BGP routing table entry for 2001::/16 ->Paths: (2 available, best #2, table Default-IP-Routing-Table) -> Advertised to non peer-group peers: -> 2001:200:0:1800::9c4:0 2001:200:0:1800::12a9:1 2001:200:0:1800::2513:0 2001:200:0:1800::2516:1 2001:200:0:1800::2518:1 2001:200:0:1800::2527:1 2001:200:0:1800::4697:1 2001:200:0:1800::4716:1 2001:200:0:1800::4725:1 2001:200:0:1800::6461:1 2001:200:0:1800::7514:1 2001:200:0:1800::9600:1 2001:200:0:1800:0:1:13:0 2001:200:0:1800:0:1:7522:0 2001:200:0:1800:200:f8ff:fe01:6c53 2001:200:0:1800:2e0:b0ff:fe2d:1f01 2001:240:100:ff::1 2001:240:100:ff::2 -> 2500 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 -> 2001:200:0:1800::9c4:0 from 2001:200:0:1800::9c4:0 (203.178.140.203) -> (fe80::9c4:0) -> Origin incomplete, localpref 100, valid, external -> Last update: Thu Jan 17 08:40:26 2002 -> -> 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 -> 2001:200:0:1800::4691:1 from 2001:200:0:1800::4691:1 (203.181.69.181) -> Origin incomplete, metric 3, localpref 100, valid, external, best -> Last update: Thu Jan 17 08:40:16 2002 -> From bmanning@ISI.EDU Thu Jan 17 13:27:26 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 17 Jan 2002 05:27:26 -0800 Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: References: Message-ID: <20020117132726.GA34054@zed.isi.edu> It would have been nice if the RIRs and ICANN had considered this when they enabled ip6.arpa. As it stands, they have beeen asked, repeatedly by me, and now at the RIPE mtg as to why it has still not been done. --bill From rmk@arm.linux.org.uk Thu Jan 17 13:39:26 2002 From: rmk@arm.linux.org.uk (Russell King) Date: Thu, 17 Jan 2002 13:39:26 +0000 Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: ; from pekkas@netcore.fi on Thu, Jan 17, 2002 at 11:39:42AM +0200 References: Message-ID: <20020117133926.B12731@flint.arm.linux.org.uk> On Thu, Jan 17, 2002 at 11:39:42AM +0200, Pekka Savola wrote: > As ip6.arpa has been BCP for some time now, would it make sense to > delegate the reverses under ip6.arpa to all pTLA's, to the same servers as > with ip6.int? (at the moment, not even e.f.f.3.ip6.arpa has been > delegated.) Last time I looked at the RFCs and compared them with glibc, I found glibc was buggy. ip6.int uses a nibble-based format. ip6.arpa uses a bitstring. Unfortunately, the glibc people just replaced ip6.int with ip6.arpa, which is obviously not correct. See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57870 I've had no feedback from this bug, nor any feedback from the glibc maintainers. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From pekkas@netcore.fi Thu Jan 17 14:18:15 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 17 Jan 2002 16:18:15 +0200 (EET) Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: <20020117133926.B12731@flint.arm.linux.org.uk> Message-ID: On Thu, 17 Jan 2002, Russell King wrote: > On Thu, Jan 17, 2002 at 11:39:42AM +0200, Pekka Savola wrote: > > As ip6.arpa has been BCP for some time now, would it make sense to > > delegate the reverses under ip6.arpa to all pTLA's, to the same servers as > > with ip6.int? (at the moment, not even e.f.f.3.ip6.arpa has been > > delegated.) > > Last time I looked at the RFCs and compared them with glibc, I found > glibc was buggy. No. > ip6.int uses a nibble-based format. ip6.arpa uses a bitstring. > Unfortunately, the glibc people just replaced ip6.int with ip6.arpa, > which is obviously not correct. The only thing RFC 3152 basically says is that delegations from ip6.int should be moved under ip6.arpa. The author of the RFC has clarified this to mean that nibble-structure should still be used with ip6.arpa. (nothing prevents from putting bitlabels there too, of course.) IMO, this should have been clearly mentioned in the draft, as it just confuses people (it confused me, and it has confused you). -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From juanph@ccc.uba.ar Thu Jan 17 14:28:22 2002 From: juanph@ccc.uba.ar (Juan Pablo Herrera) Date: Thu, 17 Jan 2002 11:28:22 -0300 (ART) Subject: Contact point Message-ID: Hello everybody. I'm loocking for a contact point in argentina. Juan Pablo Herrera Centro de Comunicacion Cientifica Universidad de Buenos Aires From kfarnes@qinetiq.com Thu Jan 17 14:44:30 2002 From: kfarnes@qinetiq.com (Kevin Farnes) Date: Thu, 17 Jan 2002 14:44:30 +0000 Subject: Creating an ipv6-site object In-Reply-To: <000e01c19f56$b8071400$8cf51150@local.comv6.com> Message-ID: <3C46E34E.16844.16F01C5@localhost> There is that potential if all else fails. However, this does make life a little bit more difficult for connection points as they must then ensure that this ASN does not get distributed. I suppose I could just put a suitable number in the field to allow the object to be created and just never use it. However, I would have thought that was cheating a could lead to confusion later. I would have thought, however, that the system would be capable of allowing sites to be created without the necessity of having to have their own ASN number. The current thoughts between myself and the connection point I have been talking to would be to use Static routing which keeps life nice and simple for both parties. Kevin > > Kevin, if you don't have an Asn you can use one of the private > range... what kind of peering your think about? Matteo ----- Original > Message ----- From: "Kevin Farnes" To: > <6bone@ISI.EDU> Sent: Thursday, January 17, 2002 10:26 AM Subject: > Creating an ipv6-site object > > > > I am in the process of trying to establish an IPv6 tunnel from our > > site. I am trying to setup the relevant ipv6-site object within the > > registry. Unfortunately I have a slight problem. > > > > One of the required fields is the Origin field, the AS number > > advertising the router. Unfortunately I don't have my own AS > > number. What should I put in this field to allow me to create the > > ipv6-object? Should it be the AS number of the pTLA/pNLA providing > > my connection? > > > > Your help would be appreciated. > > > > Kevin Farnes > > Senior Engineer > > QinetiQ > > > kfarnes@qinetiq.com--------------------------------------------------- > ------ - > Mr. K. Farnes > Senior Engineer > North Site A114, QinetiQ, > > St. Andrews Rd, Malvern, > Worcs, WR14 3PS > UK > Tel : +44 (0)1684 > 894156 Fax : +44 (0)1684 894303 > E-Mail : > kfarnes@qinetiq.com > > ---------------------------------------------------------- > > ---------------------------------------------------------- Mr. K. Farnes Senior Engineer North Site A114, QinetiQ, St. Andrews Rd, Malvern, Worcs, WR14 3PS UK Tel : +44 (0)1684 894156 Fax : +44 (0)1684 894303 E-Mail : kfarnes@qinetiq.com ---------------------------------------------------------- From wizard@italiansky.com Thu Jan 17 14:59:03 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Thu, 17 Jan 2002 15:59:03 +0100 Subject: Creating an ipv6-site object References: <3C46E34E.16844.16F01C5@localhost> Message-ID: <000901c19f67$80f17440$8cf51150@local.comv6.com> Maybe you're right, the point is only whatever you want to do with your ipv6-site, if you plan to use bgp peering with many site for a better connection into 6bone, you would like to use a private asn and not an As from your provider's upstream or something else, i think that your provider doesn't agree so much to let a leaf site use their ASn, in fact if you have only a static routing with it's site you don't have to use as, simple point the ::/0 to provider's tunnel, but if you plan to grow your connection in the backbone i suggest you to use an asn from private range.... Best regards, Matteo ----- Original Message ----- From: "Kevin Farnes" To: <6bone@ISI.EDU>; "Matteo Tescione" Sent: Thursday, January 17, 2002 3:44 PM Subject: Re: Creating an ipv6-site object > There is that potential if all else fails. However, this does make life a > little bit more difficult for connection points as they must then ensure > that this ASN does not get distributed. I suppose I could just put a > suitable number in the field to allow the object to be created and just > never use it. However, I would have thought that was cheating a > could lead to confusion later. > > I would have thought, however, that the system would be capable of > allowing sites to be created without the necessity of having to have > their own ASN number. > > The current thoughts between myself and the connection point I > have been talking to would be to use Static routing which keeps life > nice and simple for both parties. > > Kevin > > > > > Kevin, if you don't have an Asn you can use one of the private > > range... what kind of peering your think about? Matteo ----- Original > > Message ----- From: "Kevin Farnes" To: > > <6bone@ISI.EDU> Sent: Thursday, January 17, 2002 10:26 AM Subject: > > Creating an ipv6-site object > > > > > > > I am in the process of trying to establish an IPv6 tunnel from our > > > site. I am trying to setup the relevant ipv6-site object within the > > > registry. Unfortunately I have a slight problem. > > > > > > One of the required fields is the Origin field, the AS number > > > advertising the router. Unfortunately I don't have my own AS > > > number. What should I put in this field to allow me to create the > > > ipv6-object? Should it be the AS number of the pTLA/pNLA providing > > > my connection? > > > > > > Your help would be appreciated. > > > > > > Kevin Farnes > > > Senior Engineer > > > QinetiQ > > > > > kfarnes@qinetiq.com--------------------------------------------------- > > ------ - > Mr. K. Farnes > Senior Engineer > North Site A114, QinetiQ, > > > St. Andrews Rd, Malvern, > Worcs, WR14 3PS > UK > Tel : +44 (0)1684 > > 894156 Fax : +44 (0)1684 894303 > E-Mail : > > kfarnes@qinetiq.com > > > ---------------------------------------------------------- > > > > > ---------------------------------------------------------- > Mr. K. Farnes > Senior Engineer > North Site A114, QinetiQ, > St. Andrews Rd, Malvern, > Worcs, WR14 3PS > UK > Tel : +44 (0)1684 894156 Fax : +44 (0)1684 894303 > E-Mail : kfarnes@qinetiq.com > ---------------------------------------------------------- > From fink@es.net Thu Jan 17 15:21:58 2002 From: fink@es.net (Bob Fink) Date: Thu, 17 Jan 2002 07:21:58 -0800 Subject: Creating an ipv6-site object In-Reply-To: <3C46E34E.16844.16F01C5@localhost> References: <000e01c19f56$b8071400$8cf51150@local.comv6.com> Message-ID: <5.1.0.14.0.20020117071232.032377f8@imap2.es.net> Kevin, At 02:44 PM 1/17/2002 +0000, Kevin Farnes wrote: >There is that potential if all else fails. However, this does make life a >little bit more difficult for connection points as they must then ensure >that this ASN does not get distributed. I suppose I could just put a >suitable number in the field to allow the object to be created and just >never use it. However, I would have thought that was cheating a >could lead to confusion later. If you are a pTLA you must have your own ASN. If you are not a pTLA, you have the choice of the ASN of your upstream address allocation (tho it would be polite to ask them first), or a private range ASN. It is always the responsibility of your peers to not propagate it if you are not a pTLA, unless there is agreement to do so for some real reason, and the uniqueness of the ASN is taken into account. >I would have thought, however, that the system would be capable of >allowing sites to be created without the necessity of having to have >their own ASN number. If we didn't require it no none would fill it in. >The current thoughts between myself and the connection point I >have been talking to would be to use Static routing which keeps life >nice and simple for both parties. Well, even in this simple case BGP has uses, hence an ASN. Anyway, pick your upstream's ASN or a random private range ASN. Thanks, Bob From paitken@cisco.com Thu Jan 17 15:34:38 2002 From: paitken@cisco.com (Paul Aitken) Date: Thu, 17 Jan 2002 15:34:38 +0000 Subject: Contact point References: Message-ID: <3C46EF0E.1040301@cisco.com> Juan Pablo Herrera wrote: > > Hello everybody. > I'm loocking for a contact point in argentina. http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/bycountry.html#AR ? -- Paul Aitken IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX From rmk@arm.linux.org.uk Thu Jan 17 15:39:37 2002 From: rmk@arm.linux.org.uk (Russell King) Date: Thu, 17 Jan 2002 15:39:37 +0000 Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: ; from pekkas@netcore.fi on Thu, Jan 17, 2002 at 04:18:15PM +0200 References: <20020117133926.B12731@flint.arm.linux.org.uk> Message-ID: <20020117153936.C12731@flint.arm.linux.org.uk> On Thu, Jan 17, 2002 at 04:18:15PM +0200, Pekka Savola wrote: > The only thing RFC 3152 basically says is that delegations from ip6.int > should be moved under ip6.arpa. Umm, my reading of it implies that: 1. ip6.arpa domain space is to be used, as defined by RFC2874 2. ip6.int references are deprecated. 3. new implementations should use ip6.arpa 4. IANA should delegate the ip6.arpa domain. RFC2874 defines the ip6.arpa to use bitlabels, which appear to be distinctly different from the nibble-based represenation. For example, try: 1 # dig -t PTR 1.5.7.0.0.c.e.f.f.f.7.5.0.1.2.0.1.0.0.0.2.0.0.2.0.6.2.8.e.f.f.3.ip6.int @195.92.249.255 2 # dig -t PTR 1.5.7.0.0.c.e.f.f.f.7.5.0.1.2.0.1.0.0.0.2.0.0.2.0.6.2.8.e.f.f.3.ip6.arpa @195.92.249.255 3 # dig -t PTR '\[x3ffe826020020001021057fffec00751].ip6.arpa' @195.92.249.255 To make all 3 of the above work, I've had to add the following to the DNS on that machine: $ORIGIN 0.0.c.e.f.f.f.7.5.0.1.2.0.1.0.0.0.2.0.0.2.0.6.2.8.e.f.f.3.ip6.int. 1.5.7 PTR tika.arm.linux.org.uk. $ORIGIN 2.0.0.2.0.6.2.8.e.f.f.3.ip6.arpa 8.7.a.0.0.c.e.f.f.f.7.5.0.1.2.0.1.0.0.0 CNAME 8.7.a.0.0.c.e.f.f.f.7.5.0.1.2.0.1.0.0.0.2.0.0.2.0.6.2.8.e.f.f.3.ip6.int. $ORIGIN \[x3FFE826020020001021057FFFEC00/116].ip6.arpa. \[x751/12] PTR tika.arm.linux.org.uk. If I drop the bitlabel, then the bitlabel (3) lookup stops working. If I drop the CNAME, then lookup (2) stops working. The above is using bind 9.1.0. I'd really like someone to clarify what the real situation is, and whether my interpretations of RFC1886, RFC2874 and RFC3152 are correct. (Lastly, is there a better mailing list to be discussing this stuff on?) -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From fink@es.net Thu Jan 17 16:03:24 2002 From: fink@es.net (Bob Fink) Date: Thu, 17 Jan 2002 08:03:24 -0800 Subject: 6bone pTLA 3FFE:8320::/28 allocated to POZMAN Message-ID: <5.1.0.14.0.20020117080132.032f7a40@imap2.es.net> POZMAN has been allocated pTLA 3FFE:8320::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to either bmanning@isi.edu or hostmaster@ep.net.] Thanks, Bob From michel@arneill-py.sacramento.ca.us Thu Jan 17 16:49:54 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 17 Jan 2002 08:49:54 -0800 Subject: Creating an ipv6-site object Message-ID: <2B81403386729140A3A899A8B39B046406C224@server2000.arneill-py.sacramento.ca.us> Mmmm I see some more private ASN hijacking on the horizon -----Original Message----- From: Matteo Tescione [mailto:wizard@italiansky.com] Sent: Thursday, January 17, 2002 4:59 AM To: Kevin Farnes; 6bone@ISI.EDU Subject: Re: Creating an ipv6-site object Kevin, if you don't have an Asn you can use one of the private range... what kind of peering your think about? Matteo ----- Original Message ----- From: "Kevin Farnes" To: <6bone@ISI.EDU> Sent: Thursday, January 17, 2002 10:26 AM Subject: Creating an ipv6-site object > I am in the process of trying to establish an IPv6 tunnel from our > site. I am trying to setup the relevant ipv6-site object within the > registry. Unfortunately I have a slight problem. > > One of the required fields is the Origin field, the AS number > advertising the router. Unfortunately I don't have my own AS > number. What should I put in this field to allow me to create the > ipv6-object? Should it be the AS number of the pTLA/pNLA > providing my connection? > > Your help would be appreciated. > > Kevin Farnes > Senior Engineer > QinetiQ > kfarnes@qinetiq.com--------------------------------------------------------- - > Mr. K. Farnes > Senior Engineer > North Site A114, QinetiQ, > St. Andrews Rd, Malvern, > Worcs, WR14 3PS > UK > Tel : +44 (0)1684 894156 Fax : +44 (0)1684 894303 > E-Mail : kfarnes@qinetiq.com > ---------------------------------------------------------- > From fink@es.net Thu Jan 17 17:19:05 2002 From: fink@es.net (Bob Fink) Date: Thu, 17 Jan 2002 09:19:05 -0800 Subject: Creating an ipv6-site object In-Reply-To: <2B81403386729140A3A899A8B39B046406C224@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020117090903.032e9980@imap2.es.net> For everyone not familiar with ASNs one should read the APNIC FAQ on ASNs: and specifically public and private ASNs: >When is a Public Autonomous System number required? >A Public AS number is required only when an AS is exchanging routing >information with other Autonomous Systems on the public Internet. That is, >all routes orginating from an AS is visible on the Internet. > >When can I use a Private Autonomous System number? >A Private AS number should be used if an AS requires to do BGP with a >single provider. As the routing policy between the AS and the provider >will not be visible in the Internet, a Private AS Number can be used for >this purpose. >The IANA has reserved AS64512 through to AS65535 to be used as private ASes. And RFC1930: and from section 8 on IGP issues: "As stated above, many router vendors require an identifier for tagging their IGP processes. However, this tag does not need to be globally unique. In practice this information is never seen by exterior routing protocols. If already running an exterior routing protocol, it is perfectly reasonable to use your AS number as an IGP tag; if you do not, choosing from the private use range is also acceptable (see "Reserved AS Numbers"). Merely running an IGP is not grounds for registration of an AS number. " Thanks, Bob === At 08:49 AM 1/17/2002 -0800, Michel Py wrote: >Mmmm I see some more private ASN hijacking on the horizon > >-----Original Message----- >From: Matteo Tescione [mailto:wizard@italiansky.com] >Sent: Thursday, January 17, 2002 4:59 AM >To: Kevin Farnes; 6bone@ISI.EDU >Subject: Re: Creating an ipv6-site object > >Kevin, if you don't have an Asn you can use one of the private range... what >kind of peering your think about? >Matteo >----- Original Message ----- >From: "Kevin Farnes" >To: <6bone@ISI.EDU> >Sent: Thursday, January 17, 2002 10:26 AM >Subject: Creating an ipv6-site object > > > > I am in the process of trying to establish an IPv6 tunnel from our > > site. I am trying to setup the relevant ipv6-site object within the > > registry. Unfortunately I have a slight problem. > > > > One of the required fields is the Origin field, the AS number > > advertising the router. Unfortunately I don't have my own AS > > number. What should I put in this field to allow me to create the > > ipv6-object? Should it be the AS number of the pTLA/pNLA > > providing my connection? > > > > Your help would be appreciated. > > > > Kevin Farnes > > Senior Engineer > > QinetiQ > > >kfarnes@qinetiq.com--------------------------------------------------------- >- > > Mr. K. Farnes > > Senior Engineer > > North Site A114, QinetiQ, > > St. Andrews Rd, Malvern, > > Worcs, WR14 3PS > > UK > > Tel : +44 (0)1684 894156 Fax : +44 (0)1684 894303 > > E-Mail : kfarnes@qinetiq.com > > ---------------------------------------------------------- > > From bruce_campbell@ripe.net Thu Jan 17 17:35:00 2002 From: bruce_campbell@ripe.net (Bruce Campbell) Date: Thu, 17 Jan 2002 18:35:00 +0100 (CET) Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa Message-ID: ( Resent from the correct subscribed address ) On Thu, 17 Jan 2002, Pekka Savola wrote: > The only thing RFC 3152 basically says is that delegations from ip6.int > should be moved under ip6.arpa. Would people find the following useful?: A repetitive walk through the ip6.int tree, and checking the listed nameservers for the matching ip6.arpa entry. This would essentially build up a list of ip6.int delegations that are ready to be delegated under ip6.arpa, without creating a lame ip6.arpa entry. A little bit more work will be able to send auto/manual notifications to the parent delegations when such a condition is met. ( Personally, I don't think any entity should blindly delegate anything without making sure that the nameservers for the delegations are valid for that delegation. ) Kind regards, --==-- Bruce. Not speaking for the RIPE NCC at this point, but at the RIPE Meeting. From michel@arneill-py.sacramento.ca.us Thu Jan 17 18:20:53 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 17 Jan 2002 10:20:53 -0800 Subject: Creating an ipv6-site object Message-ID: <2B81403386729140A3A899A8B39B046406C22E@server2000.arneill-py.sacramento.ca.us> >> Kevin Farnes wrote: >> The current thoughts between myself and the connection point I >> have been talking to would be to use Static routing which keeps >> life nice and simple for both parties. > Bob Fink wrote: > Well, even in this simple case BGP has uses, hence an ASN. Anyway, > pick your upstream's ASN or a random private range ASN. Can you have multiple ipv6-site objects with the same ASN in the 6bone database maintained by our friends at Viagenie? From fink@es.net Thu Jan 17 18:56:17 2002 From: fink@es.net (Bob Fink) Date: Thu, 17 Jan 2002 10:56:17 -0800 Subject: Creating an ipv6-site object In-Reply-To: <2B81403386729140A3A899A8B39B046406C22E@server2000.arneill- py.sacramento.ca.us> Message-ID: <5.1.0.14.0.20020117105253.032e9d38@imap2.es.net> At 10:20 AM 1/17/2002 -0800, Michel Py wrote: > >> Kevin Farnes wrote: > >> The current thoughts between myself and the connection point I > >> have been talking to would be to use Static routing which keeps > >> life nice and simple for both parties. > > Bob Fink wrote: > > Well, even in this simple case BGP has uses, hence an ASN. Anyway, > > pick your upstream's ASN or a random private range ASN. > >Can you have multiple ipv6-site objects with the same ASN in the >6bone database maintained by our friends at Viagenie? I honestly don't know. I've cc'd them here. It would make sense that they did to allow the same public asn use by multiple downstreams peering up to the pTLA/pNLA that allocated their address space and gave them the right to use their ASN. Bob From fink@es.net Thu Jan 17 19:07:05 2002 From: fink@es.net (Bob Fink) Date: Thu, 17 Jan 2002 11:07:05 -0800 Subject: pTLA request for T-NET - review closes 11 February 2002 In-Reply-To: <5.1.0.14.0.20020117181624.02796a50@mail.dante.org.uk> References: <5.1.0.14.0.20020115165756.031c3da0@imap2.es.net> Message-ID: <5.1.0.14.0.20020117105929.032f43b0@imap2.es.net> Janos, At 06:23 PM 1/17/2002 +0000, Janos Mohacsi wrote: >Dear 6BONE participants, > I think t-net should not apply for 6BONE pTLA with AS number > AS1955. AS1955 is maintained by Hungarnet/NIIF. Do you have permission > from Istvan Tetenyi, or Miklos Nagy about using AS1955 for that purpose? I queried them specifically about this in my pre-scan of their application, and their response was in the revised request that they did. >By the way Hungarnet already have IPv6 subTLA. Why don't you ask them >to provide you NLA or SLA? If Hungarnet is using AS1955 for their subTLA, then T-NET will not be allowed to use it for their pTLA application will have to be denied unless they find a new public ASN to use. I will have to hear from HUNGARNET on this. Bob From rain@bluecherry.net Thu Jan 17 21:05:40 2002 From: rain@bluecherry.net (Ben Winslow) Date: 17 Jan 2002 15:05:40 -0600 Subject: Contact point In-Reply-To: <3C46EF0E.1040301@cisco.com> References: <3C46EF0E.1040301@cisco.com> Message-ID: <1011301541.29901.39.camel@halcyon> --=-2yZyFPQI/siKi3tYhmF0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-01-17 at 09:34, Paul Aitken wrote: > Juan Pablo Herrera wrote: > > >=20 > > Hello everybody. > > I'm loocking for a contact point in argentina. >=20 > http://www.cs-ipv6.lancs.ac.uk/ipv6/6Bone/Whois/bycountry.html#AR ? >=20 > --=20 > Paul Aitken > IPv6 Development, Cisco Systems Ltd, Edinburgh, Scotland. EH6 6LX >=20 The only problem here is that I've found a /lot/ of the whois information (which is linked to for each site) to be out of date, at least for the US sites. I tried poking through this list for sites that I have good routing to (I'm concerned about latency), and I've received bounced mails or no replies... Currently, I'm making due with two tunnels from automated providers (Hurricane Electric and Freenet6/Viagenie)--I'm using the HE tunnel for local addresses and most of the traffic, and the Freenet6 tunnel for a few tunnels I'm delegating elsewhere as well as traffic to other Freenet6/Viagenie hosts. Unfortunately, I don't have a fantastic route to either of these. I looked into 6to4 tunneling, however I can't find any 6to4 to 6bone gateways with halfway-decent routing, either. (I'm also not sure that I could get reverse DNS delegated to my site, but I may as well ask that while I'm at it: Will reverse DNS be delegated to 6to4 hosts upon request?) Can anyone offer any other suggestions? --=20 Ben Winslow (rain@bluecherry.net) : When you are in it up to your System Administrator : ears, keep your mouth shut. =20 Bluecherry Internet Services :=20 http://www.bluecherry.net/ :=20 (573) 592-0800 :=20 --=-2yZyFPQI/siKi3tYhmF0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Rzyk2/SfDQAyrVERAjtBAJwOqSp46yhfbGrV2SiGDVZQb6rMkgCgkMOE CRMxLD2ZL1iWcHDif3SRoME= =g2F4 -----END PGP SIGNATURE----- --=-2yZyFPQI/siKi3tYhmF0-- From Jocelyn.Picard@viagenie.qc.ca Thu Jan 17 22:45:56 2002 From: Jocelyn.Picard@viagenie.qc.ca (Jocelyn Picard) Date: Thu, 17 Jan 2002 17:45:56 -0500 Subject: Creating an ipv6-site object In-Reply-To: <2B81403386729140A3A899A8B39B046406C22E@server2000.arneill- py.sacramento.ca.us> Message-ID: <4.3.2.7.2.20020117173316.02868f40@jazz.viagenie.qc.ca> At 10:20 AM 17/01/2002 -0800, Michel Py wrote: >>> Kevin Farnes wrote: >>> The current thoughts between myself and the connection point I >>> have been talking to would be to use Static routing which keeps >>> life nice and simple for both parties. >> Bob Fink wrote: >> Well, even in this simple case BGP has uses, hence an ASN. Anyway, >> pick your upstream's ASN or a random private range ASN. > >Can you have multiple ipv6-site objects with the same ASN in the >6bone database maintained by our friends at Viagenie? Hello, yes you can. Lot of site routed using a static route use their upstream's ASN in 6bone database. Jocelyn ps: David Kessens is maintaining the database, we are only maintaining the web interface! From kre@munnari.OZ.AU Thu Jan 17 13:21:52 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 17 Jan 2002 20:21:52 +0700 Subject: Question on address configuration In-Reply-To: <3C4598AE.9040700@quack.kfu.com> References: <3C4598AE.9040700@quack.kfu.com> <5876.1011018150@brandenburg.cs.mu.OZ.AU> Message-ID: <564.1011273712@brandenburg.cs.mu.OZ.AU> Date: Wed, 16 Jan 2002 07:13:50 -0800 From: Nick Sayer Message-ID: <3C4598AE.9040700@quack.kfu.com> | Everything you said is true, but I would add the small postscript that | in 99% of the cases where you would find it truly desirable to set up a | well known address, I wasn't really talking about well known addresses necessarily, just addresses where I choose the suffix, rather than the system picking its own. | you would be better off making that address | site-local rather than based on the (routable) prefix. Site local, global, it makes no difference. The prefix still comes from the router (I don't want to configure my subnet number any more than I do my ISP provided prefix - those the node should dynamically learn). | Your arguments | about an SMTP server's DNS TTL can be made about any DNS records -- if | the TTLs are causing you heartburn you should lower them. Of course. But lowering them affects cache effectiveness, and since the address is mostly stable, there's no need to do that. If there's to be a planned change, then sure, I'll reduce the TTL. But for an unexpected change, it is far easier just to keep the same address as I had before. That way the TTL can remain large enough to be sensible most of the time. Otherwise I'd have to keep it at around 5 or 10 minutes - because predicting when an ethernet card (or whole system) will die, and need to be replaced with no warning, is beyond my abilities. | People | typically want to configure manual addresses so that they don't have to | keep rewriting resolv.conf files (or equiv). Please stop deciding you know why I want to do what I want to do, and then providing an alternate means to achieve that. That's not a very useful method of discussion. kre From bmanning@ISI.EDU Fri Jan 18 05:05:40 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Thu, 17 Jan 2002 21:05:40 -0800 Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: References: Message-ID: <20020118050540.GB35804@zed.isi.edu> I regularly walk the ip6.int tree and have started to do the same for ip6.arpa. On Thu, Jan 17, 2002 at 06:35:00PM +0100, Bruce Campbell wrote: > > ( Resent from the correct subscribed address ) > > On Thu, 17 Jan 2002, Pekka Savola wrote: > > > The only thing RFC 3152 basically says is that delegations from ip6.int > > should be moved under ip6.arpa. > > Would people find the following useful?: > > A repetitive walk through the ip6.int tree, and checking the > listed nameservers for the matching ip6.arpa entry. > > This would essentially build up a list of ip6.int delegations that are > ready to be delegated under ip6.arpa, without creating a lame ip6.arpa > entry. > > A little bit more work will be able to send auto/manual notifications to > the parent delegations when such a condition is met. > > ( Personally, I don't think any entity should blindly delegate anything > without making sure that the nameservers for the delegations are valid > for that delegation. ) > > Kind regards, > > --==-- > Bruce. > > Not speaking for the RIPE NCC at this point, but at the RIPE Meeting. > > > From kre@munnari.OZ.AU Fri Jan 18 06:00:58 2002 From: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 18 Jan 2002 13:00:58 +0700 Subject: Please make 3ffe::/16 reverse-delegations under ip6.arpa In-Reply-To: <20020117153936.C12731@flint.arm.linux.org.uk> References: <20020117153936.C12731@flint.arm.linux.org.uk> <20020117133926.B12731@flint.arm.linux.org.uk> Message-ID: <3839.1011333658@brandenburg.cs.mu.OZ.AU> Date: Thu, 17 Jan 2002 15:39:37 +0000 From: Russell King Message-ID: <20020117153936.C12731@flint.arm.linux.org.uk> | RFC2874 defines the ip6.arpa to use bitlabels, which appear to be distinctly | different from the nibble-based represenation. No it doesn't. 2874 says that the bitlabels for reverse lookups go in ip6.arpa. That's a different thing entirely from claiming that ip6.arpa is restricted to bit labels. kre From Ronald.vanderPol@rvdp.org Fri Jan 18 07:38:55 2002 From: Ronald.vanderPol@rvdp.org (Ronald van der Pol) Date: Fri, 18 Jan 2002 08:38:55 +0100 Subject: bogus route: 2001::/16 In-Reply-To: <13552.1011234739@itojun.org> References: <13552.1011234739@itojun.org> Message-ID: <20020118073855.GB604@rvdp.org> On Thu, Jan 17, 2002 at 11:32:19 +0900, itojun@iijlab.net wrote: > we are seeing a bogus route, namely 2001::/16, advertised from > AS 1003. please stop it. thanks. It's 1103 and this is us, surfnet. I contacted Itojun offline because we are not announcing the prefix to 3274. We also do not see 2001::/16 in our routing table. We don't see the route, Itojun still does. Could the other ASes in the path below have a check? I suspect it is a buggy BGP implementation somewhere which is holding the route. rvdp > itojun > > > bgpd@otm6-gate1# sh ipv6 bgp 2001::/16 > BGP routing table entry for 2001::/16 > Paths: (2 available, best #2, table Default-IP-Routing-Table) > Advertised to non peer-group peers: > 2001:200:0:1800::9c4:0 2001:200:0:1800::12a9:1 2001:200:0:1800::2513:0 2001:200:0:1800::2516:1 2001:200:0:1800::2518:1 2001:200:0:1800::2527:1 2001:200:0:1800::4697:1 2001:200:0:1800::4716:1 2001:200:0:1800::4725:1 2001:200:0:1800::6461:1 2001:200:0:1800::7514:1 2001:200:0:1800::9600:1 2001:200:0:1800:0:1:13:0 2001:200:0:1800:0:1:7522:0 2001:200:0:1800:200:f8ff:fe01:6c53 2001:200:0:1800:2e0:b0ff:fe2d:1f01 2001:240:100:ff::1 2001:240:100:ff::2 > 2500 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 > 2001:200:0:1800::9c4:0 from 2001:200:0:1800::9c4:0 (203.178.140.203) > (fe80::9c4:0) > Origin incomplete, localpref 100, valid, external > Last update: Thu Jan 17 08:40:26 2002 > > 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 > 2001:200:0:1800::4691:1 from 2001:200:0:1800::4691:1 (203.181.69.181) > Origin incomplete, metric 3, localpref 100, valid, external, best > Last update: Thu Jan 17 08:40:16 2002 From arun.mahabier@cmg.nl Fri Jan 18 08:00:21 2002 From: arun.mahabier@cmg.nl (Arun Mahabier) Date: Fri, 18 Jan 2002 09:00:21 +0100 Subject: 6bone pTLA 3FFE:8320::/28 allocated to POZMAN Message-ID: I would like to stop receiving e-mail from this newsgroup. who can telle me how te do this. Met vriendelijke groeten, Arun Mahabier CMG Trade, Transport & Industry B.V. Divisie Infrastructure & Networking Consultancy Industry Kralingseweg 241-249 Postbus 8566 3009 AN Rotterdam Telefoon CMG: (+31) 010 - 253 75 96 Fax CMG: (+31) 010 - 253 70 61 E-mail: arun.mahabier@cmg.nl -----Original Message----- From: Bob Fink [mailto:fink@es.net] Sent: donderdag 17 januari 2002 17:03 To: 6BONE List Cc: Bartosz Gajda Subject: 6bone pTLA 3FFE:8320::/28 allocated to POZMAN POZMAN has been allocated pTLA 3FFE:8320::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to either bmanning@isi.edu or hostmaster@ep.net.] Thanks, Bob From tony@lava.net Fri Jan 18 08:49:59 2002 From: tony@lava.net (Antonio Querubin) Date: Thu, 17 Jan 2002 22:49:59 -1000 (HST) Subject: bogus route: 2001::/16 In-Reply-To: <20020118073855.GB604@rvdp.org> Message-ID: On Fri, 18 Jan 2002, Ronald van der Pol wrote: > Date: Fri, 18 Jan 2002 08:38:55 +0100 > From: Ronald van der Pol > To: itojun@iijlab.net > Cc: 6bone@ISI.EDU > Subject: Re: bogus route: 2001::/16 > > On Thu, Jan 17, 2002 at 11:32:19 +0900, itojun@iijlab.net wrote: > > > we are seeing a bogus route, namely 2001::/16, advertised from > > AS 1003. please stop it. thanks. > > It's 1103 and this is us, surfnet. I contacted Itojun offline because > we are not announcing the prefix to 3274. We also do not see 2001::/16 > in our routing table. We don't see the route, Itojun still does. Could > the other ASes in the path below have a check? I suspect it is a buggy > BGP implementation somewhere which is holding the route. We do not see 2001::/16 in our routing tables here at LavaNet, ASN 6435. > > bgpd@otm6-gate1# sh ipv6 bgp 2001::/16 > > BGP routing table entry for 2001::/16 > > Paths: (2 available, best #2, table Default-IP-Routing-Table) > > Advertised to non peer-group peers: > > 2001:200:0:1800::9c4:0 2001:200:0:1800::12a9:1 2001:200:0:1800::2513:0 2001:200:0:1800::2516:1 2001:200:0:1800::2518:1 2001:200:0:1800::2527:1 2001:200:0:1800::4697:1 2001:200:0:1800::4716:1 2001:200:0:1800::4725:1 2001:200:0:1800::6461:1 2001:200:0:1800::7514:1 2001:200:0:1800::9600:1 2001:200:0:1800:0:1:13:0 2001:200:0:1800:0:1:7522:0 2001:200:0:1800:200:f8ff:fe01:6c53 2001:200:0:1800:2e0:b0ff:fe2d:1f01 2001:240:100:ff::1 2001:240:100:ff::2 > > 2500 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 > > 2001:200:0:1800::9c4:0 from 2001:200:0:1800::9c4:0 (203.178.140.203) > > (fe80::9c4:0) > > Origin incomplete, localpref 100, valid, external > > Last update: Thu Jan 17 08:40:26 2002 > > > > 4691 8002 6726 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 > > 2001:200:0:1800::4691:1 from 2001:200:0:1800::4691:1 (203.181.69.181) > > Origin incomplete, metric 3, localpref 100, valid, external, best > > Last update: Thu Jan 17 08:40:16 2002 From pim@ipng.nl Fri Jan 18 15:38:54 2002 From: pim@ipng.nl (Pim van Pelt) Date: Fri, 18 Jan 2002 16:38:54 +0100 Subject: [pim@ipng.nl: NetBSD kame - strange behavior] Message-ID: <20020118153854.GB6014@bfib.colo.bit.nl> Hi 6bone folk, It has come to my attention that NetBSD (at least 1.5-1.5.2) have some peculiarity in the KAME stack for IPv6 regarding linklocal on the loopback interface. Let us take a NetBSD box: $ uname -a NetBSD biscuit 1.5 NetBSD 1.5 (PEERING) #1 and an OpenBSD box: $ uname -a OpenBSD ghoul 3.0 GHOUL#2 i386 Regarding the NetBSD one, look at its lo0 device: [NetBSD 1.5] $ ifconfig lo0 lo0: flags=8009 mtu 33228 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 and conclude that fe80::1 is the linklocal address for lo0. Pinging this address works, obviously: [NetBSD 1.5] $ ping6 -c 3 fe80::1%lo0 PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::1%lo0 16 bytes from fe80::1%lo0, icmp_seq=0 hlim=64 time=0.654 ms 16 bytes from fe80::1%lo0, icmp_seq=1 hlim=64 time=1.581 ms 16 bytes from fe80::1%lo0, icmp_seq=2 hlim=64 time=0.679 ms --- fe80::1%lo0 ping6 statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.654/0.971/1.581/0.431 ms However, NetBSD (as opposed to FreeBSD and OpenBSD) listens to any fe80::/10 address on lo0. Look: [NetBSD 1.5] $ ping6 -c 3 fe80::dead:babe:c0ff:ee%lo0 PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::dead:babe:c0ff:ee%lo0 16 bytes from fe80::dead:babe:c0ff:ee%lo0, icmp_seq=0 hlim=64 time=0.732 ms 16 bytes from fe80::dead:babe:c0ff:ee%lo0, icmp_seq=1 hlim=64 time=1.524 ms 16 bytes from fe80::dead:babe:c0ff:ee%lo0, icmp_seq=2 hlim=64 time=0.781 ms --- fe80::dead:babe:c0ff:ee%lo0 ping6 statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/std-dev = 0.732/1.012/1.524/0.362 ms My coffee bringing dead babe is alive! This results in a somewhat logical observation that: [NetBSD 1.5] $ ping6 ff02::1%gif53 PING6(56=40+8+8 bytes) fe80::210:4bff:fe09:1b16%gif53 --> ff02::1%gif53 16 bytes from fe80::210:4bff:fe09:1b16%lo0, icmp_seq=0 hlim=64 time=1.36 ms 16 bytes from fe80::206:5bff:fe11:1c38%gif53, icmp_seq=0 hlim=64 time=23.051 ms(DUP!) See that the first reply (the localhost) comes from lo0! For reference (you may check this) OpenBSD and FreeBSD, both, reply from the GIF interface and not lo0: [OpenBSD 3.0] $ ping6 ff02::1%gif1 PING6(56=40+8+8 bytes) fe80::260:8ff:fe46:4b3f%gif1 --> ff02::1%gif1 16 bytes from fe80::260:8ff:fe46:4b3f%gif1, icmp_seq=0 hlim=64 time=0.948 ms 16 bytes from fe80::250:4ff:fe4e:222d%gif1, icmp_seq=0 hlim=64 time=33.468 ms(DUP!) so that pinging an unconfigured address at lo0 does not work on on f/oBSD: [OpenBSD 3.0] $ ping6 -c 3 fe80::dead:babe:c0ff:ee%lo0 PING6(56=40+8+8 bytes) fe80::1%lo0 --> fe80::dead:babe:c0ff:ee%lo0 --- fe80::dead:babe:c0ff:ee%lo0 ping6 statistics --- 3 packets transmitted, 0 packets received, 100% packet loss In short (glad you made it this far :), why does NetBSD do this ? groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From michael@kjorling.com Fri Jan 18 16:25:18 2002 From: michael@kjorling.com (Michael Kjorling) Date: Fri, 18 Jan 2002 17:25:18 +0100 (CET) Subject: AAAA, A6, or both? Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First of all, if this is off topic for this list I apologize in advance and do not want anyone to feel obligated to read this. It seems like I am (finally) getting hooked up to the 6bone and getting some public address space, so suddenly another issue becomes more critical: what DNS record type to use for forward mapping. There are AAAA and A6, and as far as I gather a lot of confusion as to which should be used (not to mention reverse mapping, but at least there we're only talking about one record *type*). So, my question is, which should I use: A6, AAAA, or both? I don't have many machines for the moment so the maintenance burden of the AAAA approach is pretty much nada, and I would like to be able to serve content over IPv6 to as many as possible. Could anyone please advise me as to which approach I should take? Every time I read up on this I only get more confused. Thanks a lot in advance, Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e "There is something to be said about not trying to be glamorous and popular and cool. Just be real -- and life will be real." (Joyce Sequichie Hifler, September 13 2001, www.hifler.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8SEx0KqN7/Ypw4z4RAjNSAJ9UQCEjtE4lxTSh7ykfRECbSsLXuACfc29Y yNzMoATTKGE52NuPQ7REKYI= =Pb9t -----END PGP SIGNATURE----- From Jan Oravec Fri Jan 18 17:06:23 2002 From: Jan Oravec (Jan Oravec) Date: Fri, 18 Jan 2002 18:06:23 +0100 Subject: bogus route: 2001::/16 In-Reply-To: <20020118073855.GB604@rvdp.org>; from Ronald.vanderPol@rvdp.org on Fri, Jan 18, 2002 at 08:38:55AM +0100 References: <13552.1011234739@itojun.org> <20020118073855.GB604@rvdp.org> Message-ID: <20020118180623.A77987@ipv6.isternet.sk> > It's 1103 and this is us, surfnet. I contacted Itojun offline because > we are not announcing the prefix to 3274. We also do not see 2001::/16 > in our routing table. We don't see the route, Itojun still does. Could > the other ASes in the path below have a check? I suspect it is a buggy > BGP implementation somewhere which is holding the route. We see 2001::/16, someone has buggy BGP implementation which creates such "long paths", we can see a lot of them. SKBYS-0000> sh bgp 2001::/16 BGP routing table entry for 2001::/16 Paths: (3 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 2001:658:0:1::1 3ffe:80e8:1:3::2 3ffe:80ef:1:: 3ffe:80ef:100:: 3ffe:80ef:800:: 3ffe:80ef:900:: 5594 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) 3ffe:80e1:8000:10::2 from 3ffe:80ef:1:: (195.168.1.69) Origin incomplete, localpref 100, valid, internal Last update: Fri Jan 18 13:35:32 2002 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) 2001:730:3::1:e from 3ffe:80ef:300:: (62.140.29.9) Origin incomplete, localpref 100, valid, internal, best Last update: Fri Jan 18 12:59:03 2002 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) 2001:730:3::1:e from 3ffe:80ef:900:: (62.140.29.9) Origin incomplete, localpref 100, valid, internal Originator: 62.140.29.9, Cluster list: 62.89.127.130 Last update: Fri Jan 18 12:59:00 2002 These announcements of these long paths are stable (actually 4 hours up). We peer with 2611 and they are announcing us much different ASPATH for 2001::/16. If we receive different ASPATH from 5594 going thru 2611, it means that something was corrupted on 5594, 2200 or 2611. These long ASPATHs are very common on 6bone, it seems that some popular implementation of BGP is broken. They are commonly appearing when prefix is being removed from routing tables and may appear if implementation of BGP has corrupted ASPATH loop-check. Actually I am implementing BGP+IGP daemon, because except zebra there is no decent routing daemon able to do very advanced routing we need for project. We are now using slightly modified zebra, but it has still enough bugs. Best Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' jan.oravec@xs26.net From michel@arneill-py.sacramento.ca.us Fri Jan 18 18:09:56 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Jan 2002 10:09:56 -0800 Subject: bogus route: 2001::/16 Message-ID: <2B81403386729140A3A899A8B39B046405DE5B@server2000.arneill-py.sacramento.ca.us> >> itojun@iijlab.net wrote: >> we are seeing a bogus route, namely 2001::/16, advertised from >> AS 1003. please stop it. thanks. > Ronald van der Pol wrote: > It's 1103 and this is us, surfnet. I contacted Itojun offline > because we are not announcing the prefix to 3274. We also do not > see 2001::/16 in our routing table. We don't see the route, Itojun > still does. Could the other ASes in the path below have a check? > I suspect it is a buggy BGP implementation somewhere which is > holding the route. $0.02 from my side outside the path: cisco3640#sh bgp ipv6 2001::/16 20834 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 I think that the problem is within AS 8733 or AS 6774. Note: I see some other prefixes out of whack, namely: 2001:280::/35 2001:738::/35 3FFE:1900::/24 3FFE:2F00::/24 3FFE:3400::/24 3FFE:8060::/28 3FFE:80D0::/28 Might help to narrow it down. Michel. *> 2001:280::/35 ---------------- 3FFE:B00:C18::8C 10566 3265 6939 5609 6830 15589 1275 680 5539 4589 8733 5511 4697 3425 293 109 22 65513 17715 3263 1654 3274 1103 1849 3320 2549 513 ? 3FFE:8270:0:1::40 20834 10566 3265 6939 5609 6830 15589 1275 680 5539 4589 8733 5511 4697 3425 293 109 22 65513 17715 3263 1654 3274 1103 1849 3320 2549 513 ? *> 2001:738::/35 ---------------- 3FFE:B00:C18::8C 10566 5594 5378 1752 5539 8319 1275 3265 6939 8002 8664 15694 8627 790 3274 1103 2611 5511 2500 4697 3425 293 6175 6726 9044 513 20834 i *> 3FFE:1900::/24 ----------------- 3FFE:B00:C18::8C 10566 6175 10318 33 6939 2549 3274 1103 766 278 8002 6726 20834 8664 59650 59650 ? *> 3FFE:2F00::/24 ----------------- 3FFE:B00:C18::8C 10566 3265 7521 4697 14277 6435 109 15589 1275 20834 2549 3274 1654 8954 33 17715 3263 1103 2611 6774 8733 5511 2497 6939 145 12199 10318 6175 237 ? *> 3FFE:3400::/24 ----------------- 3FFE:8270:0:1::40 20834 3274 6175 10318 12199 237 3748 9270 2200 3425 293 1275 15589 5609 6939 14277 209 517 8954 10566 5594 559 1122 5539 6726 8664 2020 7777 ? *> 3FFE:8060::/28 ----------------- 3FFE:8270:0:1::40 20834 3274 6175 10318 33 3265 513 2549 5408 2603 1275 15589 10566 17715 109 6939 5424 i *> 3FFE:80D0::/28 ----------------- 3FFE:B00:C18::8C 10566 5594 6726 33 2497 4697 3425 293 5609 8954 1200 3265 1275 2607 2852 3263 1103 1849 3320 2549 3274 8319 3561 145 12199 237 i 3FFE:8270:0:1::40 20834 10566 5594 6726 33 2497 4697 3425 293 5609 8954 1200 3265 1275 2607 2852 3263 1103 1849 3320 2549 3274 8319 3561 145 12199 237 i From pim@ipng.nl Fri Jan 18 19:09:26 2002 From: pim@ipng.nl (Pim van Pelt) Date: Fri, 18 Jan 2002 20:09:26 +0100 Subject: AAAA, A6, or both? In-Reply-To: References: Message-ID: <20020118190926.GB15477@bfib.colo.bit.nl> | First of all, if this is off topic for this list I apologize in | advance and do not want anyone to feel obligated to read this. It's on topic, and perhaps more than you'd think. | Could anyone please advise me as to which approach I should take? | Every time I read up on this I only get more confused. You should use AAAA and disregard anything you ever read about A6. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From wizard@italiansky.com Fri Jan 18 20:28:51 2002 From: wizard@italiansky.com (Matteo Tescione) Date: Fri, 18 Jan 2002 21:28:51 +0100 Subject: bogus route: 2001::/16 Message-ID: <00aa01c1a05e$be736c90$8cf51150@local.comv6.com> This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C1A067.1FDAC070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If it can help I see on my side: Francisco#sh bgp ipv6 2001::/16 BGP routing table entry for 2001::/16, version 4905 Paths: (2 available, best #2) 20834 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 = 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 3FFE:8270:0:1::22 from 3FFE:8270:0:1::22 (80.71.0.50) Origin incomplete, localpref 100, valid, external 1752 8627 4589 6774 8733 6830 6726 1275 762 6175 6435 109 1251 3265 = 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 2001:618:400::A023:EB02 from 2001:618:400::A023:EB02 (193.113.58.80) Origin incomplete, localpref 100, valid, external, best Matteo ------=_NextPart_000_00A7_01C1A067.1FDAC070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If it can help I see on my = side:
 
Francisco#sh bgp ipv6 2001::/16
BGP = routing=20 table entry for 2001::/16, version 4905
Paths: (2 available, best=20 #2)
  20834 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 = 1251=20 3265 7521 7521
7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 = 1103
    3FFE:8270:0:1::22 from 3FFE:8270:0:1::22=20 (80.71.0.50)
      Origin incomplete, = localpref 100,=20 valid, external
  1752 8627 4589 6774 8733 6830 6726 1275 762 = 6175 6435=20 109 1251 3265 7521 7521
7521 7521 4697 3425 293 4554 8954 10566 5408 = 2549=20 3274 1103
    2001:618:400::A023:EB02 from=20 2001:618:400::A023:EB02 = (193.113.58.80)
      Origin=20 incomplete, localpref 100, valid, external, best
 
Matteo
------=_NextPart_000_00A7_01C1A067.1FDAC070-- From helios@balios.org Fri Jan 18 20:46:57 2002 From: helios@balios.org (Helios de Creisquer) Date: Fri, 18 Jan 2002 21:46:57 +0100 Subject: AAAA, A6, or both? In-Reply-To: References: Message-ID: <20020118204657.GC6216@balios.org> On Fri, Jan 18, 2002 at 05:25:18PM +0100, Michael Kjorling wrote: > we're only talking about one record *type*). So, my question is, which > should I use: A6, AAAA, or both? I don't have many machines for the > moment so the maintenance burden of the AAAA approach is pretty much > nada, and I would like to be able to serve content over IPv6 to as > many as possible. > > Could anyone please advise me as to which approach I should take? > Every time I read up on this I only get more confused. Hi ! Seems to me the A6 records obsoleted the AAAA records... but I would use both cause of resolvers... it seems that some versions around here ask only for AAAA and not A6... Cheers, -- Helios de Creisquer http://www.tuxfamily.org/ http://www.vhffs.org/ +33 (0)6 70 71 20 29 http://www.gnu.org/ GPG(1024D/96EB1C44): FB11 8B80 4D86 D9C2 DE0C 11D7 2FA8 A5CC 96EB 1C44 From rmk@arm.linux.org.uk Fri Jan 18 20:54:50 2002 From: rmk@arm.linux.org.uk (Russell King) Date: Fri, 18 Jan 2002 20:54:50 +0000 Subject: bogus route: 2001::/16 In-Reply-To: <20020118180623.A77987@ipv6.isternet.sk>; from wsx@wsx6.net on Fri, Jan 18, 2002 at 06:06:23PM +0100 References: <13552.1011234739@itojun.org> <20020118073855.GB604@rvdp.org> <20020118180623.A77987@ipv6.isternet.sk> Message-ID: <20020118205450.E2059@flint.arm.linux.org.uk> On Fri, Jan 18, 2002 at 06:06:23PM +0100, Jan Oravec wrote: > SKBYS-0000> sh bgp 2001::/16 > BGP routing table entry for 2001::/16 > Paths: (3 available, best #2, table Default-IP-Routing-Table) > Advertised to non peer-group peers: > 2001:658:0:1::1 3ffe:80e8:1:3::2 3ffe:80ef:1:: 3ffe:80ef:100:: 3ffe:80ef:800:: 3ffe:80ef:900:: > 5594 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) > 3ffe:80e1:8000:10::2 from 3ffe:80ef:1:: (195.168.1.69) > Origin incomplete, localpref 100, valid, internal > Last update: Fri Jan 18 13:35:32 2002 > > 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) > 2001:730:3::1:e from 3ffe:80ef:300:: (62.140.29.9) > Origin incomplete, localpref 100, valid, internal, best > Last update: Fri Jan 18 12:59:03 2002 > > 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) > 2001:730:3::1:e from 3ffe:80ef:900:: (62.140.29.9) > Origin incomplete, localpref 100, valid, internal > Originator: 62.140.29.9, Cluster list: 62.89.127.130 > Last update: Fri Jan 18 12:59:00 2002 My path for 2001::/16 is: me: 45328 8277 8379 4589 6774 8733 6830 6726 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103 you: 6830 8733 2611 6774 4589 680 1275 ... etc ... Here's a couple of other AS paths for 2001::/16: 6939 5609 6830 8733 2611 6774 4589 680 1275 ... etc ... 8277 8379 4589 6774 8733 6830 6726 1275 ... etc ... Everything from AS1275 to AS1103 is identical in each case. Hope this helps. -- Russell King (rmk@arm.linux.org.uk) The developer of ARM Linux http://www.arm.linux.org.uk/personal/aboutme.html From michael@kjorling.com Fri Jan 18 21:53:49 2002 From: michael@kjorling.com (Michael Kjorling) Date: Fri, 18 Jan 2002 22:53:49 +0100 (CET) Subject: AAAA, A6, or both? In-Reply-To: <20020118190926.GB15477@bfib.colo.bit.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Jan 18 2002 20:09 +0100, Pim van Pelt wrote: > | First of all, if this is off topic for this list I apologize in > | advance and do not want anyone to feel obligated to read this. > It's on topic, and perhaps more than you'd think. Well then, at least I don't get flamed... :-) > | Could anyone please advise me as to which approach I should take? > | Every time I read up on this I only get more confused. > You should use AAAA and disregard anything you ever read about A6. > > groet, > Pim OK - I have received three other e-mails where various people suggest using both AAAA and A6 in order to support the maximum number of clients, and one of them pointing out as well that A6 chaining can be disabled by using a prefix length value of 0. And I really cannot see how it can hurt to use both. This brings up another matter, though - reverse lookups. ip6.arpa or ip6.int, bitlabels (like \[x3FFE/16]) or nibble (e.f.f.e.ip6.[arpa|int]) form? Both ip6.arpa and ip6.int are delegated off the root servers. Any input is much appreciated, as I am still very new to IPv6 (though fairly familiar with IPv4). Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e "There is something to be said about not trying to be glamorous and popular and cool. Just be real -- and life will be real." (Joyce Sequichie Hifler, September 13 2001, www.hifler.com) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8SJlyKqN7/Ypw4z4RAkKzAKDUwxuReJGQ3+CrL4QFpHU2e8CL7wCdGbLU ZVOnqvUa1uub3MM0k+7o8B0= =nEPg -----END PGP SIGNATURE----- From john@sixgirls.org Fri Jan 18 22:19:27 2002 From: john@sixgirls.org (John Klos) Date: Fri, 18 Jan 2002 17:19:27 -0500 (EST) Subject: AAAA, A6, or both? In-Reply-To: <20020118190926.GB15477@bfib.colo.bit.nl> Message-ID: > | Could anyone please advise me as to which approach I should take? > | Every time I read up on this I only get more confused. > You should use AAAA and disregard anything you ever read about A6. AAAA is depricated but still supported. If you fear that you might have systems that can't do RFC 2874 type A6 chains, BIND 9 has an option that allows RFC 1886 lookups to be done on A6 chains. I'd love to know what, if any, resolvers can do 1886 lookups but not 2874. Does anyone know? I am interested to know why you dismiss A6 out of hand with no information. Have you come across RFC 1886-only resolvers? John Klos Sixgirls Computing Labs From tony@lava.net Fri Jan 18 23:16:36 2002 From: tony@lava.net (Antonio Querubin) Date: Fri, 18 Jan 2002 13:16:36 -1000 (HST) Subject: AAAA, A6, or both? In-Reply-To: Message-ID: On Fri, 18 Jan 2002, John Klos wrote: > > | Could anyone please advise me as to which approach I should take? > > | Every time I read up on this I only get more confused. > > > You should use AAAA and disregard anything you ever read about A6. > > AAAA is depricated but still supported. If you fear that you might have > systems that can't do RFC 2874 type A6 chains, BIND 9 has an option that > allows RFC 1886 lookups to be done on A6 chains. > > I'd love to know what, if any, resolvers can do 1886 lookups but not 2874. > Does anyone know? > > I am interested to know why you dismiss A6 out of hand with no > information. Have you come across RFC 1886-only resolvers? Very few service providers have upgraded their production DNS to handle A6 so I suspect the vast majority of DNS currently in operation will still barf on A6 RRs. If I recall correctly, BIND 8.x and earlier, for example, will reject an entire zone if it sees RRs it doesn't understand, so it's not likely you'll see A6 become widespread until BIND 9.x is more widely deployed on DNS operating as secondary nameservers. From paul@clubi.ie Fri Jan 18 23:27:12 2002 From: paul@clubi.ie (Paul Jakma) Date: Fri, 18 Jan 2002 23:27:12 +0000 (GMT) Subject: ipv6 multihoming for non-TLA eligible sites Message-ID: hi, there has been some discussion in the past on this about how multi-homing is to work for ipv6 sites. as i understand it, there will be no equivalent of IPv4 'Provider Independent' address ranges with IPv6. Sites will only be able to get addresses from their ISPs TLA. my question is then, if the above is the case, how are IPv6 sites supposed to achieve ingress resiliency? are we to rely on all IPv6 clients implementing SRV lookups? thanks in advance, regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "Consider a spherical bear, in simple harmonic motion..." -- Professor in the UCB physics department From wmaton@ryouko.dgim.crc.ca Sat Jan 19 00:44:21 2002 From: wmaton@ryouko.dgim.crc.ca (William F. Maton) Date: Fri, 18 Jan 2002 19:44:21 -0500 (EST) Subject: ipv6 multihoming for non-TLA eligible sites In-Reply-To: Message-ID: On Fri, 18 Jan 2002, Paul Jakma wrote: > there has been some discussion in the past on this about how > multi-homing is to work for ipv6 sites. as i understand it, there > will be no equivalent of IPv4 'Provider Independent' address ranges > with IPv6. Sites will only be able to get addresses from their ISPs > TLA. > > my question is then, if the above is the case, how are IPv6 sites > supposed to achieve ingress resiliency? are we to rely on all IPv6 > clients implementing SRV lookups? While this doesn't answer your question completely, you may want to have a look at the IETF multi6 working group, stuck just for this type of discussion: http://www.ietf.org/html.charters/multi6-charter.html wfms From michel@arneill-py.sacramento.ca.us Sat Jan 19 02:33:04 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Jan 2002 18:33:04 -0800 Subject: ipv6 multihoming for non-TLA eligible sites Message-ID: <2B81403386729140A3A899A8B39B046405DE5C@server2000.arneill-py.sacramento.ca.us> Paul, This would be better discussed in the IETF multi6 mailing list. http://www.ietf.org/html.charters/multi6-charter.html > Paul Jakma wrote: > as i understand it, there will be no equivalent of IPv4 'Provider > Independent' address ranges with IPv6. Sites will only be able to > get addresses from their ISPs TLA. Although it is too early to tell (the requirements are being finished these days) there are at least three individual drafts that have PI addresses: http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt http://search.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-01.txt http://search.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-01.txt Michel. From ishii@mfeed.ad.jp Sat Jan 19 02:36:26 2002 From: ishii@mfeed.ad.jp (ISHII Toshinori) Date: Sat, 19 Jan 2002 11:36:26 +0900 Subject: bogus route: 2001::/16 In-Reply-To: <20020118180623.A77987@ipv6.isternet.sk> References: <13552.1011234739@itojun.org> <20020118073855.GB604@rvdp.org> <20020118180623.A77987@ipv6.isternet.sk> Message-ID: <6jadvbawyd.wl@saru.tokyo.mfeed.co.jp> At Fri, 18 Jan 2002 18:06:23 +0100, Jan Oravec wrote: > > We see 2001::/16, someone has buggy BGP implementation which creates such > "long paths", we can see a lot of them. > > SKBYS-0000> sh bgp 2001::/16 > BGP routing table entry for 2001::/16 > Paths: (3 available, best #2, table Default-IP-Routing-Table) > Advertised to non peer-group peers: > 2001:658:0:1::1 3ffe:80e8:1:3::2 3ffe:80ef:1:: 3ffe:80ef:100:: 3ffe:80ef:800:: 3ffe:80ef:900:: > 5594 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) > 3ffe:80e1:8000:10::2 from 3ffe:80ef:1:: (195.168.1.69) > Origin incomplete, localpref 100, valid, internal > Last update: Fri Jan 18 13:35:32 2002 > > 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) > 2001:730:3::1:e from 3ffe:80ef:300:: (62.140.29.9) > Origin incomplete, localpref 100, valid, internal, best > Last update: Fri Jan 18 12:59:03 2002 > > 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (Received from a RR-client) > 2001:730:3::1:e from 3ffe:80ef:900:: (62.140.29.9) > Origin incomplete, localpref 100, valid, internal > Originator: 62.140.29.9, Cluster list: 62.89.127.130 > Last update: Fri Jan 18 12:59:00 2002 > > These announcements of these long paths are stable (actually 4 hours up). It looks stable but.... I'm in as7521 but I do not aspath-prepend now. I stopped aspath-prepend 2 days ago. (> 4hours) Someone holds old incorrect bgp table and keep it. -- ishii @ mfeed.ad.jp From RJorgensen@CHELLO.com Sat Jan 19 03:09:46 2002 From: RJorgensen@CHELLO.com (Jorgensen, Roger) Date: Sat, 19 Jan 2002 04:09:46 +0100 Subject: bogus route: 2001::/16 Message-ID: <7CEA40C0E10C7D4FBE076AE7C3EFB78D05FCE9@nlcbbms03> Hi, First some aspath seen from us (6830 and 8733) nl-ams-re-02#show bgp ipv6 2001::/16 BGP routing table entry for 2001::/16, version 81675 Paths: (3 available, best #3) Advertised to non peer-group peers: 2001:730::1:3 2001:730::1:7 2001:730::1:9 2001:730::1:F 2001:730::1:19 2001:730::1:21 2001:730::1:23 2001:730::1:29 2001:730:0:2:2D0:B7FF:FE3E:AAE2 2001:740:0:102::1:0 3FFE:2000:0:40F::22F 3FFE:2501:100::21 3FFE:2900:1:5::1 3FFE:8270:0:1::52 3FFE:8271:201:2037::1 3FFE:82E2:0:101::1 15589 513 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (received & used) 2001:730::1:F from 2001:730::1:F (192.168.1.12) Origin incomplete, localpref 100, valid, external 20834 513 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (received & used) 3FFE:8270:0:1::52 from 3FFE:8270:0:1::52 (80.71.0.50) Origin incomplete, localpref 100, valid, external 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (received & used) 2001:730::1:5 from 2001:730::1:5 (195.162.197.71) Origin incomplete, localpref 100, valid, external, best That's what I see from 6830, from 8733 (also us) be-bru-re-01>show bgp ipv6 2001::/16 BGP routing table entry for 2001::/16, version 271023 Paths: (1 available, best #1) Advertised to non peer-group peers: 2001:730::1:4 3FFE:2501:100::1F 2611 6774 4589 680 1275 762 6175 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 2549 3274 1103, (received & used) 3FFE:80B0:1000:0:260:8FF:FE69:8E7E from 3FFE:2501:100::13 (195.162.197.69) Origin incomplete, localpref 100, valid, internal, best Something else that might be related to this, I've noticed long and often broken ASPATH several times (used ASPATH www2.ipv6.chello.com/bgp-stats that show a few of them) and they are almost always coming from Belgium (through 8733 for us). I can't explain where or why or anything more than the people before me has done, just wanted to show what we see since many seems to get 2001::/16 through us. Will have a look at 8733 to make sure there isn't anything there that cause problems. --- Roger Jorgensen (rjorgensen@chello.com) System Engineer @ engineering chello Broadband handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID > -----Original Message----- > From: Russell King [mailto:rmk@arm.linux.org.uk] > Sent: Friday, January 18, 2002 9:55 PM > To: Jan Oravec > Cc: Ronald van der Pol; 6bone@ISI.EDU > Subject: Re: bogus route: 2001::/16 > > > On Fri, Jan 18, 2002 at 06:06:23PM +0100, Jan Oravec wrote: > > SKBYS-0000> sh bgp 2001::/16 > > BGP routing table entry for 2001::/16 > > Paths: (3 available, best #2, table Default-IP-Routing-Table) > > Advertised to non peer-group peers: > > 2001:658:0:1::1 3ffe:80e8:1:3::2 3ffe:80ef:1:: > 3ffe:80ef:100:: 3ffe:80ef:800:: 3ffe:80ef:900:: > > 5594 2200 2611 6774 4589 680 1275 762 6175 6435 109 1251 > 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 > 2549 3274 1103, (Received from a RR-client) > > 3ffe:80e1:8000:10::2 from 3ffe:80ef:1:: (195.168.1.69) > > Origin incomplete, localpref 100, valid, internal > > Last update: Fri Jan 18 13:35:32 2002 > > > > 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 > 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 > 2549 3274 1103, (Received from a RR-client) > > 2001:730:3::1:e from 3ffe:80ef:300:: (62.140.29.9) > > Origin incomplete, localpref 100, valid, internal, best > > Last update: Fri Jan 18 12:59:03 2002 > > > > 6830 8733 2611 6774 4589 680 1275 762 6175 6435 109 1251 > 3265 7521 7521 7521 7521 4697 3425 293 4554 8954 10566 5408 > 2549 3274 1103, (Received from a RR-client) > > 2001:730:3::1:e from 3ffe:80ef:900:: (62.140.29.9) > > Origin incomplete, localpref 100, valid, internal > > Originator: 62.140.29.9, Cluster list: 62.89.127.130 > > Last update: Fri Jan 18 12:59:00 2002 > > My path for 2001::/16 is: > > me: 45328 8277 8379 4589 6774 8733 6830 6726 1275 762 6175 > 6435 109 1251 3265 7521 7521 7521 7521 4697 3425 293 4554 > 8954 10566 5408 2549 3274 1103 > you: 6830 8733 2611 6774 4589 680 1275 ... etc ... > > Here's a couple of other AS paths for 2001::/16: > > 6939 5609 6830 8733 2611 6774 4589 680 1275 ... etc ... > 8277 8379 4589 6774 8733 6830 6726 1275 ... etc ... > > Everything from AS1275 to AS1103 is identical in each case. Hope this > helps. > > -- > Russell King (rmk@arm.linux.org.uk) The > developer of ARM Linux > http://www.arm.linux.org.uk/personal/aboutme.html > From christian.bahls@stud.uni-rostock.de Sat Jan 19 03:43:16 2002 From: christian.bahls@stud.uni-rostock.de (Christian Bahls) Date: Sat, 19 Jan 2002 04:43:16 +0100 (CET) Subject: [pim@ipng.nl: NetBSD kame - strange behavior] (fwd) Message-ID: hope this will hit the list ---------- Forwarded message ---------- To: Pim van Pelt Subject: Re: [pim@ipng.nl: NetBSD kame - strange behavior] this goes to 6bone(hopefully .. as i can't see any of my previous postings regarding other topics on the list) .. to become serious .. hope you are familar with netstat .. do "netstat -n -r -f inet6" (man netstat) ignore everything that has an "R" in it (RTF_REJECT) that are all the routes that are discarded by KAME-stack (good policy by itojun) ok first one .. fe80::%lo0/64 fe80::1%lo0 U 0 0 33220 lo0 fe80::%lo0 is routed through fe80::1%lo0 .. "Hint" .. so next question is: what is lo0 supposed to do ? answer: discard packages after puting them onto the stack .. so every packet that gets routed to any link-lokal address scoped with %lo0 gets send back top your stack .. so why can't i ping 127.0.0.2 ?, would be the next question answer: 127.0.0.0/8 is "REJECTED" via 127.0.0.1 which is on lo0 127 127.0.0.1 UGRS 0 2 33220 lo0 127.0.0.1 127.0.0.1 UH 6 1972 33220 lo0 .. more advanced question: why do i see my %gif0 scoped ping being answered via lo0 ? answer: because the kernel has been told that this address is directly reachable by device lo0 ("U"sable+"H"ost) fe80::201:2fe:fe10:1201%gif0 ::1 UH 0 0 33220 lo0 to make a long answer short .. it seems to be a policy question and i do rather trust itojun (if it was him) on routing policy decisions christian bahls maths student university of rostock From chuck+6bone@snew.com Sat Jan 19 05:57:31 2002 From: chuck+6bone@snew.com (Chuck Yerkes) Date: Fri, 18 Jan 2002 21:57:31 -0800 Subject: AAAA, A6, or both? In-Reply-To: ; from tony@lava.net on Fri, Jan 18, 2002 at 01:16:36PM -1000 References: Message-ID: <20020118215731.A12384@snew.com> Quoting Antonio Querubin (tony@lava.net): > On Fri, 18 Jan 2002, John Klos wrote: > > I am interested to know why you dismiss A6 out of hand with no > > information. Have you come across RFC 1886-only resolvers? > > Very few service providers have upgraded their production DNS to handle A6 > so I suspect the vast majority of DNS currently in operation will still > barf on A6 RRs. If I recall correctly, BIND 8.x and earlier, for example, > will reject an entire zone if it sees RRs it doesn't understand, so it's > not likely you'll see A6 become widespread until BIND 9.x is more widely > deployed on DNS operating as secondary nameservers. BIND 8.3 will not barf on A6 records. Not sure that it knows what to do with them, but it's supposed to now accept "unknown RRs". This is handy when I have zones that are secondaried by BIND 8 people. From michael@kjorling.com Sat Jan 19 10:56:24 2002 From: michael@kjorling.com (Michael Kjorling) Date: Sat, 19 Jan 2002 11:56:24 +0100 (CET) Subject: AAAA, A6, or both? In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is not quite true. At least BIND 8.3.0 on NT will happily serve a zone with both AAAA (obviously) and A6 RRs (though 8.2.5 won't). However, I have no idea if it will follow A6 chains during resolution. But at least this shows that BIND 9 is not mandatory if you want to support A6 RRs in the DNS. Then I'd consider it a bigger problem that *none* of the root servers support IPv6 records, IPv6 transport, or publishes DNSSEC records. But this is just my two cents for the moment. Michael Kjörling On Jan 18 2002 13:16 -1000, Antonio Querubin wrote: > Very few service providers have upgraded their production DNS to handle A6 > so I suspect the vast majority of DNS currently in operation will still > barf on A6 RRs. If I recall correctly, BIND 8.x and earlier, for example, > will reject an entire zone if it sees RRs it doesn't understand, so it's > not likely you'll see A6 become widespread until BIND 9.x is more widely > deployed on DNS operating as secondary nameservers. - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e "There is something to be said about not trying to be glamorous and popular and cool. Just be real -- and life will be real." (Joyce Sequichie Hifler, September 13 2001, www.hifler.com) *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8SVDdKqN7/Ypw4z4RAveCAKCqnr/c83FffFlBBHcEkrHZK1vRYQCdHt2u zznfvDSqwLE9HUZKYXUH93g= =ynNY -----END PGP SIGNATURE----- From Jan Oravec Sat Jan 19 11:32:07 2002 From: Jan Oravec (Jan Oravec) Date: Sat, 19 Jan 2002 12:32:07 +0100 Subject: bogus route: 2001::/16 In-Reply-To: <4A96C3DC180245448514461934650DE703619A@nlcbbms04>; from SVanSteen@CHELLO.com on Sat, Jan 19, 2002 at 11:25:34AM +0100 References: <4A96C3DC180245448514461934650DE703619A@nlcbbms04> Message-ID: <20020119123207.A77268@ipv6.isternet.sk> Hello, > Okay I will filter those /16 out for now - not sure if that's the right > thing to do though. > that's not a solution, the solution is to find who creates that.. I would suggest if 5594, 2200 and 2611 show their routes for 2001::/16. -- Jan Oravec project coordinator XS26 - 'Access to IPv6' jan.oravec@xs26.net From berni@birkenwald.de Sat Jan 19 13:45:18 2002 From: berni@birkenwald.de (Bernhard Schmidt) Date: Sat, 19 Jan 2002 14:45:18 +0100 Subject: Announicing more specific routes Message-ID: <20020119134518.GA10787@thor.birkenwald.de> This mail is originally by Robert Blechinger, a co-worker at Cybernet. His mails don't appear on the 6bone mailing list for unknown reasons, so I'm forwarding it to the list. ----- Forwarded message from Robert Blechinger ----- Date: Fri, 18 Jan 2002 16:14:02 +0100 From: Robert Blechinger To: 6bone@isi.edu Subject: Announicing more specific routes User-Agent: Mutt/1.3.25i Hi all, i would like to ask all members of 6BONE and RIR to follow the rules written in RFC 2772, regarding the announcement of more specific routes. some days before i had about 350 different prefixes in my routingtable and about 150 of them were more specific ones. that was about 43% then i wrote to some pTLAs which anounced a lot of /64's and /48's from their own delegated assignment. but i don't want to write everybody mails rearding to this. there are also many SLA's and NLA's which announcing their more specific prefixes to everybody. Furthermore, some of them using private ASN to announce their prefixes to everybody and the partners (pTLA's) didn't filter out them. I think everybody will agree with me that we don't want to blow the global ipv6 routingtable as it is already in the ipv4 one. Visit http://sarah-hst.muc.eurocyber.net/ --> IPv6 AS-Path-Tree for the current status. <-------------------------------------------------------------------------> [RFC 2772] 4. Routing Policies for the 6bone ... All 6bone pTLAs MUST NOT advertise prefixes longer than a given pTLA delegation (currently /24 or /28) to other 6bone pTLAs unless special peering arrangements are implemented. When such special peering aggreements are in place between any two or more 6bone pTLAs, care MUST be taken not to leak the more specifics to other 6bone pTLAs not participating in the peering aggreement. ... <-------------------------------------------------------------------------> Kindly Regards Robert -- Blechinger Robert Cybernet AG - Networking email: rblechinger@cybernet-ag.net Phone: +49 89 99315 - 116 Fax: +49 89 99315 - 199 Love is just a kiss away... ----- End forwarded message ----- -- bye bye Bernhard From tony@lava.net Sat Jan 19 20:21:54 2002 From: tony@lava.net (Antonio Querubin) Date: Sat, 19 Jan 2002 10:21:54 -1000 (HST) Subject: AAAA, A6, or both? In-Reply-To: <20020118215731.A12384@snew.com> Message-ID: On Fri, 18 Jan 2002, Chuck Yerkes wrote: > Quoting Antonio Querubin (tony@lava.net): > > On Fri, 18 Jan 2002, John Klos wrote: > > > I am interested to know why you dismiss A6 out of hand with no > > > information. Have you come across RFC 1886-only resolvers? > > > > Very few service providers have upgraded their production DNS to handle A6 > > so I suspect the vast majority of DNS currently in operation will still > > barf on A6 RRs. If I recall correctly, BIND 8.x and earlier, for example, > > will reject an entire zone if it sees RRs it doesn't understand, so it's > > not likely you'll see A6 become widespread until BIND 9.x is more widely > > deployed on DNS operating as secondary nameservers. > > > BIND 8.3 will not barf on A6 records. Not sure that it knows > what to do with them, but it's supposed to now accept "unknown RRs". > > This is handy when I have zones that are secondaried by BIND 8 people. That's good to know but the idea is that there are still many DNS running pre-8.3 and pre-9.x BIND versions which will reject the entire zone if they detect unknown RRs. Until we see more DNS upgraded to recent software versions there'll continue to exist a natural tendency to avoid the use of A6 RRs in zone files. That competes with the "if it aint broke don't fix it" reluctance to upgrade software. And then there are those operators that never bother applying upgrades or patches and we all know those are few in number ... NOT! From pekkas@netcore.fi Sat Jan 19 22:37:02 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Sun, 20 Jan 2002 00:37:02 +0200 (EET) Subject: AAAA, A6, or both? In-Reply-To: Message-ID: Hi, I'll just point out the best advice so far, by Pim: "You should use AAAA and disregard anything you ever read about A6." For more information, see: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-00.txt or minutes from Dnsext/ngtrans joing meeting in IETF51 in London. On Sat, 19 Jan 2002, Antonio Querubin wrote: > On Fri, 18 Jan 2002, Chuck Yerkes wrote: > > > Quoting Antonio Querubin (tony@lava.net): > > > On Fri, 18 Jan 2002, John Klos wrote: > > > > I am interested to know why you dismiss A6 out of hand with no > > > > information. Have you come across RFC 1886-only resolvers? > > > > > > Very few service providers have upgraded their production DNS to handle A6 > > > so I suspect the vast majority of DNS currently in operation will still > > > barf on A6 RRs. If I recall correctly, BIND 8.x and earlier, for example, > > > will reject an entire zone if it sees RRs it doesn't understand, so it's > > > not likely you'll see A6 become widespread until BIND 9.x is more widely > > > deployed on DNS operating as secondary nameservers. > > > > > > BIND 8.3 will not barf on A6 records. Not sure that it knows > > what to do with them, but it's supposed to now accept "unknown RRs". > > > > This is handy when I have zones that are secondaried by BIND 8 people. > > That's good to know but the idea is that there are still many DNS running > pre-8.3 and pre-9.x BIND versions which will reject the entire zone if > they detect unknown RRs. Until we see more DNS upgraded to recent > software versions there'll continue to exist a natural tendency to avoid > the use of A6 RRs in zone files. That competes with the "if it aint broke > don't fix it" reluctance to upgrade software. And then there are those > operators that never bother applying upgrades or patches and we all know > those are few in number ... NOT! > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From michael@kjorling.com Sat Jan 19 23:09:56 2002 From: michael@kjorling.com (Michael Kjorling) Date: Sun, 20 Jan 2002 00:09:56 +0100 (CET) Subject: AAAA, A6, or both? In-Reply-To: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, there certainly is a valid point in that all too few upgrade their software, even when major security holes become known (I still see a DNS server every once in a while that is running versions of BIND that are vulnerable to exploits that have been fixed long ago - see http://www.isc.org/products/BIND/bind-security.html). But as long as you can ensure that your slave DNS servers won't barf at the zone (and hopefully you have some kind of relation with the people running it, if you're not running it yourself), you will be OK. It's a major difference between a name server not *asking* for a specific record type, and the same server rejecting zones that contain records of said type - A6, in this case. It could just as well have been some other type, perhaps completely unrelated to IPv6. (Remember MH, MD? LOC?) It seems that my seemingly fairly simple question has sparked a major debate - and I believe some of it good. I asked if I should use AAAA, A6, or both for IPv6 forward mapping. A lot of people suggested both. As long as one's secondaries can handle that, I see no problem with such an approach and it does allow you to support the greatest number of clients. As one person pointed out, it's possible to use A6 records in a kind of "AAAA emulation mode" by setting the prefix length to 0 (e.g. 'foo.bar.com. A6 0 dead:beef::c0:ffee') Here's another question that might spark an even bigger controversy: reverse lookups. Obviously one will use PTR records, but where in the DNS tree? Say, for example, that I have the IPv6 address space 3ffe:dead:beef::/48. What reverse zone(s) do I need to set up and get delegated from my upstream/tunnel provider in order to make it work properly? Michael Kjörling On Jan 19 2002 10:21 -1000, Antonio Querubin wrote: > > BIND 8.3 will not barf on A6 records. Not sure that it knows > > what to do with them, but it's supposed to now accept "unknown RRs". > > > > This is handy when I have zones that are secondaried by BIND 8 people. > > That's good to know but the idea is that there are still many DNS running > pre-8.3 and pre-9.x BIND versions which will reject the entire zone if > they detect unknown RRs. Until we see more DNS upgraded to recent > software versions there'll continue to exist a natural tendency to avoid > the use of A6 RRs in zone files. That competes with the "if it aint broke > don't fix it" reluctance to upgrade software. And then there are those > operators that never bother applying upgrades or patches and we all know > those are few in number ... NOT! - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0From 6bone-owner Sun Jan 20 05:26:58 2002 Return-Path: Received: (from majordom@localhost) by zephyr.isi.edu (8.9.3/8.9.3) id FAA08115 for 6bone-outgoing; Sun, 20 Jan 2002 05:26:58 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by zephyr.isi.edu (8.9.3/8.9.3) with ESMTP id FAA08110 for <6bone@zephyr.isi.edu>; Sun, 20 Jan 2002 05:26:55 -0800 (PST) Received: from varg.mcpoolen.se (varg.mcpoolen.se [213.88.238.204]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id g0KDRug28587 for <6bone@ISI.EDU>; Sun, 20 Jan 2002 05:27:56 -0800 (PST) Received: from varg.wolfpack (IDENT:michael@varg.wolfpack [192.168.1.1]) by varg.mcpoolen.se (8.11.6/8.11.6) with ESMTP id g0KDSwN18515; Sun, 20 Jan 2002 13:28:58 GMT Date: Sun, 20 Jan 2002 14:28:52 +0100 (CET) From: Michael Kjorling X-X-Sender: michael@varg.wolfpack To: 6bone <6bone@ISI.EDU> cc: Pekka Savola Subject: Re: AAAA, A6, or both? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-6bone@zephyr.isi.edu Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Interesting. Thank you for the pointer, Pekka. Michael Kjörling On Jan 20 2002 00:37 +0200, Pekka Savola wrote: > Hi, > > I'll just point out the best advice so far, by Pim: > > "You should use AAAA and disregard anything you ever read about A6." > > > For more information, see: > > http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-addresses-00.txt > > or minutes from Dnsext/ngtrans joing meeting in IETF51 in London. - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e "There is something to be said about not trying to be glamorous and popular and cool. Just be real -- and life will be real." (Joyce Sequichie Hifler, September 13 2001, www.hifler.com) *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8SsYZKqN7/Ypw4z4RAofuAKD6UPilvpqlVGZwLKe/TdAdFOMtAACaAxsD dRivW2AF1svOSDb+1T7oD6g= =yeE0 -----END PGP SIGNATURE----- From wmaton@ryouko.dgim.crc.ca Sun Jan 20 13:28:31 2002 From: wmaton@ryouko.dgim.crc.ca (William F. Maton) Date: Sun, 20 Jan 2002 08:28:31 -0500 (EST) Subject: bogus route: 2001::/16 Message-ID: Here's the view of 2001::/16 from AS818: crc-ipv6#sh bgp ipv6 2001::/16 BGP routing table entry for 2001::/16, version 280221 Paths: (3 available, best #1) Advertised to non peer-group peers: 2001:428:8:110::1 1752 8954 8664 9090 65527 7777, (received & used) 2001:618:1::A3 from 2001:618:1::A3 (213.121.24.91) Origin incomplete, localpref 100, valid, external, best 6509 3425 293 109 8954 8664 9090 65527 7777 2001:410:101::4 from 2001:410:101::4 (205.189.32.169) Origin incomplete, localpref 100, valid, external Community: 6509:6 6509 3425 293 109 8954 8664 9090 65527 7777, (received-only) 2001:410:101::4 from 2001:410:101::4 (205.189.32.169) Origin incomplete, localpref 100, valid, external crc-ipv6# wfms From fink@es.net Sun Jan 20 23:45:27 2002 From: fink@es.net (Bob Fink) Date: Sun, 20 Jan 2002 15:45:27 -0800 Subject: pTLA request for GLOBAL - review closes 11 February 2002 Message-ID: <5.1.0.14.0.20020120153031.032708a0@imap2.es.net> 6bone Folk, GLOBAL has requested a pTLA allocation and I find their request fully compliant with RFC2772. The open review period for this will close 11 February 2002 (an extended time as I will be on travel 24 Jan - 10 Feb). Please send your comments to me or the list. Note that this new pTLA will replace the existing pTLA IPF (3FFE:3400::/24), that is stopping operation. Their technical principal Jan-Ahrent Czmok has moved to Global Access where he is setting up new IPv6 services and thus wants a new pTLA based on his experience at IPF. I have asked that they reapply for a pTLA, and that the existing /24 will be de-allocated. Thanks, Bob === >Date: Sat, 19 Jan 2002 18:13:35 +0100 >From: Jan-Ahrent Czmok >To: Bob Fink >Cc: kocovski@gatel.net, Alain.Durand@sun.com, tonyhain@microsoft.com >Subject: Re: Request for 6bone pTLA >Organization: Global Access Telecommunications Inc. > >7. Guidelines for 6Bone pTLA sites > The following rules apply to qualify for a 6Bone pTLA allocation. It > should be recognized that holders of 6Bone pTLA allocations are > expected to provide production quality backbone network services for > the 6Bone. > > 1. The pTLA Applicant must have a minimum of three (3) months > qualifying experience as a 6Bone end-site or pNLA transit. > During the entire qualifying period the Applicant must be > operationally providing the following: > > a. Fully maintained, up to date, 6Bone Registry entries for > their ipv6-site inet6num, mntner, and person > objects, including each tunnel that the Applicant has. > >Answer--> All objects are fully maintained, please see: > inet6num: 3FFE:3400:1000::/48 > ipv6-site: GLOBAL > >Current tunnels--> > >IPV6 in IPv4 ipv6-gw.de.gatel.net -> cisco.ipv6.ipf.net IPF BGP4+ >IPv6 in IPv4 ipv6-gw.de.gatel.net -> swiPV6.switch.ch SWITCH BGP4+ >IPv6 in IPv4 ipv6-gw.de.gatel.net -> 6bone.uni-muenster.de JOIN BGP4+ >IPv6 in IPv4 ipv6-gw.de.gatel.net -> home.czmok.de CZMOK-NET STATIC > > -> our Nameserver(s) are dns1.us.gatel.net and dns1.de.gatel.net > > Also i would like to add that i used to work for IPF before; > its followup Gigabell AG is also a founding member of the ipv6-forum. > We also used to have a long history in the 6bone. > > I changed jobs at January 2002, so i would like to transfer my knowledge > and experience to Global Access. > > I will implement further project work and involvement in the ipv6-wg > at ripe in our Company. > > The IPF ipv6-site will cease soon. > > b. Fully maintained, and reliable, BGP4+ peering and >connectivity between the Applicant's boundary router >and the appropriate connection point into the 6Bone. This >router must be IPv6 pingable. This criteria is judged by >members of the 6Bone Operations Group at the time of the >Applicant's pTLA request. > >Answer--> We will upgrade our router to the latest cisco ios image > to have up-to-date features. We will also expand our ipv6 > network as soon as the current ios ipv6 implementation is > proven to be stable to the ocmplete backbone and will natively > do ipv6 peerings at decix + inxs. > > c. Fully maintained DNS forward (AAAA) and reverse >(ip6.int) entries for the Applicant's router(s) and at least one host > system. > >We will also upgrade one of our nameservers to the latest bind >implementation supporting AAAA and A6 records. > >ipv6-gw.de.gatel.net and www.ipv6.gatel.net should be ipv6 pingable. > > d. A fully maintained, and reliable, IPv6-accessible > system providing, at a mimimum, one or more web > pages, describing the Applicant's IPv6 services. This > server must be IPv6 pingable. > >the server www.ipv6.gatel.net is descibing the services on ipv6. >Also it will hold the tunnel broker implementation (from cselt) > > 2. The pTLA Applicant MUST have the ability and intent to provide > "production-quality" 6Bone backbone service. > Applicants must provide a statement and information in support of this > claim. > >Answer-> We are intending and able to provide ipv6 6bone backbone service. > >We are a european-based ISP offering dialup and leased line services > besides hosting. We are working in cooperation with other parties > to sponsor and broaden IPv6 around europe. My involvement in the IPv6 > working Group (ripe) and IPV6-FORUM is widely known. > > >This MUST include the following: > a. A support staff of two persons minimum, three >preferable, with person attributes registered for each in >the ipv6-site object for the pTLA applicant. > >Please see: JC9-6BONE, JK8-6BONE and UK1-6BONE and ipv6-site object GLOBAL > > > b. A common mailbox for support contact purposes that >all support staff have acess to, pointed to with a >notify attribute in the ipv6-site object for the pTLA Applicant. > >in object GLOBAL : > >remarks: Will configure tunnels to interested parties! Please contact >support@gatel.net >notify: czmok@gatel.net > >common email-adress is czmok@gatel.net or support@gatel.net for queries > >3. The pTLA Applicant MUST have a potential "user community" >that would be served by its becoming a pTLA, e.g., the Applicant >is a major provider of Internet service in a region, country, or >focus of interest. Applicant must provide a statement and >information in support this claim. > >Global Access is a business provider and has a substantial user community >which are interested in ipv6 services. > >please see a inverse query to the ipv4 tree of GAT-MNT. > > > 4. The pTLA Applicant MUST commit to abide by the current 6Bone > operational rules and policies as they exist at time of its > application, and agree to abide by future 6Bone backbone > operational rules and policies as they evolve by consensus > of the 6Bone backbone and user community. > >We commit to abide the rules and future rules. > > When an Applicant seeks to receive a pTLA allocation, it will apply > to the 6Bone Operations Group (see section 8 below) by providing to > the Group information in support of its claims that it meets the > criteria above. > >8. 6Bone Operations Group > The 6Bone Operations Group is the group in charge of monitoring and > policing adherence to the current rules. Membership in the 6Bone > Operations Group is mandatory for, and restricted to, sites connected > to the 6Bone. > The 6Bone Operations Group is currently defined by those members of > the existing 6Bone mailing list who represent sites participating in > the 6Bone. Therefore it is incumbent on relevant site contacts to > join the 6Bone mailing list. Instructions on how to join the list are > maintained on the 6Bone web site at < http://www.6bone.net>. > >Answer ->> We are subscribed to the list. > > >If anymore questions arise, please feel free to contact me. > >Jan > > >-- > Jan Ahrent Czmok - Senior Network Engineer - Access Networks >Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt >voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de From itojun@iijlab.net Sun Jan 20 23:55:32 2002 From: itojun@iijlab.net (itojun@iijlab.net) Date: Mon, 21 Jan 2002 08:55:32 +0900 Subject: bogus route: 2001::/16 In-Reply-To: pim's message of Fri, 18 Jan 2002 16:30:13 +0100. <20020118153013.GA5696@bfib.colo.bit.nl> Message-ID: <24477.1011570932@itojun.org> >| > It's 1103 and this is us, surfnet. I contacted Itojun offline because >| > we are not announcing the prefix to 3274. We also do not see 2001::/16 >| > in our routing table. We don't see the route, Itojun still does. Could >| > the other ASes in the path below have a check? I suspect it is a buggy >| > BGP implementation somewhere which is holding the route. >| We do not see 2001::/16 in our routing tables here at LavaNet, ASN 6435. >There's nothing on the Zebra 0.91a at AS8954 either (INTOUCH-NL). >Is this a wild goose chase or is the 2001::/16 route actually still out >there ? it seems that it has gone, finally (seen from AS2497 and AS2500). itojun From michel@arneill-py.sacramento.ca.us Mon Jan 21 05:47:07 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 20 Jan 2002 21:47:07 -0800 Subject: bogus route: 2001::/16 Message-ID: <2B81403386729140A3A899A8B39B046406C241@server2000.arneill-py.sacramento.ca.us> Gone here too, there are plenty of other wild geese in my routing table though. -----Original Message----- From: itojun@iijlab.net [mailto:itojun@iijlab.net] Sent: Sunday, January 20, 2002 3:56 PM To: Pim van Pelt Cc: Antonio Querubin; Ronald van der Pol; 6bone@ISI.EDU Subject: Re: bogus route: 2001::/16 >| > It's 1103 and this is us, surfnet. I contacted Itojun offline because >| > we are not announcing the prefix to 3274. We also do not see 2001::/16 >| > in our routing table. We don't see the route, Itojun still does. Could >| > the other ASes in the path below have a check? I suspect it is a buggy >| > BGP implementation somewhere which is holding the route. >| We do not see 2001::/16 in our routing tables here at LavaNet, ASN 6435. >There's nothing on the Zebra 0.91a at AS8954 either (INTOUCH-NL). >Is this a wild goose chase or is the 2001::/16 route actually still out >there ? it seems that it has gone, finally (seen from AS2497 and AS2500). itojun From michael@kjorling.com Mon Jan 21 20:33:26 2002 From: michael@kjorling.com (Michael Kjorling) Date: Mon, 21 Jan 2002 21:33:26 +0100 (CET) Subject: Mailing list recommendations? Linux IPv6 issues Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think my problem is on topic here (but if it is feel free to let me know and I'll post it), but I have been unable to find any really good place to ask in. Is there anyone here who can recommend any IPv6-related list with a Linux orientation? Thanks a lot in advance, Michael Kjörling - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e "There is something to be said about not trying to be glamorous and popular and cool. Just be real -- and life will be real." (Joyce Sequichie Hifler, September 13 2001, www.hifler.com) *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8THsZKqN7/Ypw4z4RAltKAJ9ZrNPWAcFDPMEvpgx+dpkpyPSQigCfUbKP RYmSSzErFotajg5K3Nj2Kio= =lB5w -----END PGP SIGNATURE----- From fink@es.net Thu Jan 24 00:57:57 2002 From: fink@es.net (Bob Fink) Date: Wed, 23 Jan 2002 16:57:57 -0800 Subject: 6bone pTLA 3FFE:8330::/28 allocated to CSTNET Message-ID: <5.1.0.14.0.20020123165652.02716a30@imap2.es.net> CSTNET has been allocated pTLA 3FFE:8330::/28 having finished its 2-week review period. Note that it will take a short while for their pTLA inet6num entry to appear in the 6bone registry as they have to create it themselves. However, their registration is listed on: [To create a reverse DNS registration for pTLAs, please send the prefix allocated above, and a list of at least two authoritative nameservers, to either bmanning@isi.edu or hostmaster@ep.net.] Thanks, Bob From rrockell@sprint.net Thu Jan 24 13:41:25 2002 From: rrockell@sprint.net (Robert J. Rockell) Date: Thu, 24 Jan 2002 08:41:25 -0500 (EST) Subject: Outage Notification Message-ID: Sprint will be taking spot outages today as we upgrade Software. Please do not adjust your sets. This effects ONLY the following sprint IPv6 routers (ipv4 tunnel endpoint given). sl-bb1v6-rly.sprintlink.net sl-bb1v6-nyc.sprintlink.net sl-bb1v6-bru.sprintlink.net sl-bb1v6-sj.sprintlink.net Sorry for spam. Again, this will affect only the 6bone routers listed above. Thanks Rob Rockell Principal Engineer SprintLink Europe/Asia (+1) 703-689-6322 Sprint IP Services : Thinking outside the 435 box ----------------------------------------------------------------------- From pim@ipng.nl Thu Jan 24 16:47:20 2002 From: pim@ipng.nl (Pim van Pelt) Date: Thu, 24 Jan 2002 17:47:20 +0100 Subject: [pim@ipng.nl: NL-BIT pTLA request] Message-ID: <20020124164719.GC18594@bfib.colo.bit.nl> Dear Bob, and 6BONE folk, Via these means, I would like to inform you all, that I am switching employers on the 1st of March 2002, when my current contract at WiseGuys Internet BV ends. My new employer, Business Internet Trends, is an ISP and colocation provider in The Netherlands. I will be joining their team as a network engineer per 1/3/2002. Yay! I plan to do many exciting things with and for BIT, one of which, you could've known, is starting a native IPv6 deployment from the AMS-v6-IX to the head quarters and colocation facilities in Ede (GLD). This is why I am requesting a pTLA allocation to be made for this company. We hope to have this space allocated per 01/03 so we can dive into the configuration and implementational details. Please let me know what you think of this. Kind regards, Pim van Pelt ----- pTLA request form ----- 1. The pTLA Applicant must have a minimum of three (3) months qualifying experience as a 6Bone end-site or pNLA transit. During the entire qualifying period the Applicant must be operationally providing the following: a. Fully maintained, up to date, 6Bone Registry entries for their ipv6-site inet6num, mntner, and person objects, including each tunnel that the Applicant has. Our current inet6num is BIT6-NL (2001:06E0:0209::/48), which is natively connected to the INTOUCH-NL networks at the AMS-v6-IX. It is maintained by BIT-MNT (RIPE) and has a role BITT1-RIPE for technical and administrative contact. We have inserted copies of the -RIPE objects into the 6BONE registry where appropriate: [ipv6-site] NL-BIT6 [person] HM6669-6BONE (Hans van der Made) [person] SAB666-6BONE (Sabri Berisha) [person] AB2298-6BONE (Alex Bik) [role] BITT1-6BONE (Business Internet Trends Technical Role Account) and [person] PBVP1-6BONE (Pim van Pelt) b. Fully maintained, and reliable, BGP4+ peering and connectivity between the Applicant's boundary router and the appropriate connection point into the 6Bone. This router must be IPv6 pingable. This criteria is judged by members of the 6Bone Operations Group at the time of the Applicant's pTLA request. We have a BGP session with AS8954 at the AMS-v6-IX, which connects our Cisco 2600 to the 6BONE. We would like to enforce our network by setting up additional peerings and announcing our own network via BGP. This way AS8954 will not have to take care of our own traffic. Our address is currently: ipv6.bit.nl. has AAAA address 2001:6e0:0:10a::2 ipv6.bit.nl. has AAAA address 2001:6e0:209:2:203:6bff:fe6e:52a0 Where the former is a VLAN where Intouch AMSIX is ::1/64 and we are ::2/64 in Ede. Both addresses are on the C2600 at our site and reply pings. c. Fully maintained DNS forward (AAAA) and reverse (ip6.int) entries for the Applicant's router(s) and at least one host system. Forward entries for bit.nl (IN AAAA, and in the future IN A6) can be found at: bit.nl. name server ns2.bit.nl. bit.nl. name server ns3.bit.nl. bit.nl. name server ns.bit.nl. The reversed zonefile from Intouch is handled by IPng at this point, and only on one server: 9.0.2.0.0.e.6.0.1.0.0.2.ip6.int name server ns1.ipng.nl. but will move to ns/ns2/ns3.bit.nl per 01-03-2002. d. A fully maintained, and reliable, IPv6-accessible system providing, at a mimimum, one or more web pages, describing the Applicant's IPv6 services. This server must be IPv6 pingable. We have a server ready at www.ipv6.bit.nl, and do not plan to do much with this at the moment. There are some pages on the server, though. It's address is: 2001:6e0:209:3:290:27ff:fe0c:5c5e, port 80. It pings. 2. The pTLA Applicant MUST have the ability and intent to provide "production-quality" 6Bone backbone service. Applicants must provide a statement and information in support of this claim. This MUST include the following: a. A support staff of two persons minimum, three preferable, with person attributes registered for each in the ipv6-site object for the pTLA applicant. Alex Bik, Sabri Berisha, Hans van der Made and Pim van Pelt, forming BITT1-6BONE, as describe in section 1. b. A common mailbox for support contact purposes that all support staff have acess to, pointed to with a notify attribute in the ipv6-site object for the pTLA Applicant. This mailbox is ipv6@bit.nl and we will be using @ipv6.bit.nl once we get settled. Another entry is noc@bit.nl, which is roughly the same persons but for a more generic communication (eg v4 and v6 related) 3. The pTLA Applicant MUST have a potential "user community" that would be served by its becoming a pTLA, e.g., the Applicant is a major provider of Internet service in a region, country, or focus of interest. Applicant must provide a statement and information in support this claim. We are a hosting and application service provider, with a valid userbase for IPv6. Two main aspects come to mind: Access and Colocation. The former consists of a nationwide dialup network, and several leased lines to customers and the latter is a set of colocation facilities with some 250 customers' boxes. We are about to build a third colocation facility on a seperate location with a gigabit uplink to the AMS-IX, providing additional services to an ever growing customer base, including the possibility of traffic exchange between ISPs at this location. 4. The pTLA Applicant MUST commit to abide by the current 6Bone operational rules and policies as they exist at time of its application, and agree to abide by future 6Bone backbone operational rules and policies as they evolve by consensus of the 6Bone backbone and user community. We have a commitment to our customers and the 6bone, and armed with technical clue, we agree to abide by these rules and policies laid down by the 6bone community. When an Applicant seeks to receive a pTLA allocation, it will apply to the 6Bone Operations Group (see section 8 below) by providing to the Group information in support of its claims that it meets the criteria above. 8. 6Bone Operations Group The 6Bone Operations Group is the group in charge of monitoring and policing adherence to the current rules. Membership in the 6Bone Operations Group is mandatory for, and restricted to, sites connected to the 6Bone. The 6Bone Operations Group is currently defined by those members of the existing 6Bone mailing list who represent sites participating in the 6Bone. Therefore it is incumbent on relevant site contacts to join the 6Bone mailing list. Instructions on how to join the list are maintained on the 6Bone web site at < http://www.6bone.net>. -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- ----- End forwarded message ----- -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From pim@ipng.nl Sun Jan 27 11:28:30 2002 From: pim@ipng.nl (Pim van Pelt) Date: Sun, 27 Jan 2002 12:28:30 +0100 Subject: asymmetric routing Message-ID: <20020127112830.GA28143@bfib.colo.bit.nl> Hallo, I had always suspected it to be the case, but recently I have been monitoring the traffic that goes through the TunnelBroker at IPng.nl, and see that several of my downstream users are pushing foreign traffic through my router in Amsterdam. I would like to bring this to your attention, because of the following. Many people seem to believe that IPv6 is the solution to all current IPv4 problems, such as spoofing, broadcast and others. The spoofing aspect, which is demonstrated by the IPng situation, will not be properly taken care of unless we (the IPv6 administrators of today) set a good example and refuse to route traffic on our borders that does not originate within our own networks. In the example of my tunnelbroker, I am now dropping all the traffic sourced from outside of the IPng space, typically 3ffe:8114:2000::/52 and 3ffe:8114:1000::/48, trying to traverse the tunnelbroker from downstream to upstream. Is this common practice with tunnelbrokers? Does anybody want to share their experience on this matter ? Installing these simple rulesets 'as default' should not seem that big a deal with today's routing hardware. What do the folk from Cisco think about these anti-spoof measures being set to enabled state per default (user overridable of course) ? I for one would like to see my fellow tunnelbroker admins enable these types of rulesets on their infrastructure. It will make collecting tunnels impossible, a thing that is common on tunnelbroker+irc land, but no longer possible at my site. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From michael@kjorling.com Sun Jan 27 14:53:29 2002 From: michael@kjorling.com (Michael Kjorling) Date: Sun, 27 Jan 2002 15:53:29 +0100 (CET) Subject: asymmetric routing In-Reply-To: <20020127112830.GA28143@bfib.colo.bit.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Pim, and everyone, Just a few thoughts on the matter from someone who has most experience with this from the other end of the issue. (As I am not allowed to make changes to our router.) I commonly get traffic coming in to my network that shouldn't belong on the global Internet in the first place. Packets hitting the exterior firewall from RFC 1918 IPv4 addresses is commonplace. Aside from the question whether such traffic should be routed at all or not, I would just like to say that IMNSHO, it does not belong on the Internet in any shape or form. Still lots of ISPs (including a very large ISP in the US - and yet it was indices, not proof, that led me to this conclusion) route the traffic out on the Net, it is allowed to clog up the links only to be blocked by my firewall. I have talked to our ISP but they say it is not possible for some reason to block the traffic at their border routers. And I am certain that there is some spoofed traffic being allowed through, too. The RFCs very clearly spell out that link and site local traffic should not be forwarded outside its scope (link or site, respectively), but I have not seen any references to routing traffic originating from within one's network but having an incorrect source address. I cannot imagine any legitimate reason to route such traffic, and a lot of reasons why it should not be routed. Sure, it won't solve every possible problem, but it makes it a lot easier to track down from where malicious traffic is originating, and if necessary block it. Just my two cents for the moment, and a cheer to you Pim for a good initiative! Michael Kjörling On Jan 27 2002 12:28 +0100, Pim van Pelt wrote: > Hallo, > > I had always suspected it to be the case, but recently I have been monitoring > the traffic that goes through the TunnelBroker at IPng.nl, and see that > several of my downstream users are pushing foreign traffic through my > router in Amsterdam. > > I would like to bring this to your attention, because of the following. > Many people seem to believe that IPv6 is the solution to all current IPv4 > problems, such as spoofing, broadcast and others. > > The spoofing aspect, which is demonstrated by the IPng situation, will not > be properly taken care of unless we (the IPv6 administrators of today) set > a good example and refuse to route traffic on our borders that does not > originate within our own networks. > > In the example of my tunnelbroker, I am now dropping all the traffic sourced > from outside of the IPng space, typically 3ffe:8114:2000::/52 and > 3ffe:8114:1000::/48, trying to traverse the tunnelbroker from downstream > to upstream. > > Is this common practice with tunnelbrokers? Does anybody want to share their > experience on this matter ? Installing these simple rulesets 'as default' > should not seem that big a deal with today's routing hardware. > > What do the folk from Cisco think about these anti-spoof measures being set > to enabled state per default (user overridable of course) ? > > I for one would like to see my fellow tunnelbroker admins enable these types > of rulesets on their infrastructure. It will make collecting tunnels > impossible, a thing that is common on tunnelbroker+irc land, but no longer > possible at my site. > > groet, > Pim - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8VBRtKqN7/Ypw4z4RAhB/AKDDddzB+VE/iFpk23D1d6mmS+o6KACg6ucq rvGwAc/2ixZu5BMtygzAKXg= =Bj1T -----END PGP SIGNATURE----- From Francis.Dupont@enst-bretagne.fr Sun Jan 27 17:06:18 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Sun, 27 Jan 2002 18:06:18 +0100 Subject: asymmetric routing In-Reply-To: Your message of Sun, 27 Jan 2002 15:53:29 +0100. Message-ID: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> Basically RFC 2827 / BCP 38 about Ingress Filtering should be used for IPv6 too. There are two ways to do ingress filtering: access lists and unicast RPF. Regards Francis.Dupont@enst-bretagne.fr From ipng@uni-muenster.de Mon Jan 28 07:50:38 2002 From: ipng@uni-muenster.de (JOIN Project Team) Date: Mon, 28 Jan 2002 08:50:38 +0100 Subject: asymmetric routing In-Reply-To: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> References: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> Message-ID: <20020128075017.6E6691139@postfix1.uni-muenster.de> Am Sonntag, 27. Januar 2002 18:06 schrieb Francis Dupont: > Basically RFC 2827 / BCP 38 about Ingress Filtering should be used > for IPv6 too. There are two ways to do ingress filtering: access lists > and unicast RPF. I don't think it's that easy. Please keep in mind, that a site/customer might be multihomed. In that case he might use a different prefix from that assigned by the upstream provider as source address. Yes, one could filter all but those prefixes a customer holds, but then the customer has to name all his providers/prefixes. You can't force a customer to do so, because that information might be confidential. Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster Project Team email: Zentrum fuer Informationsverarbeitung join@uni-muenster.de Roentgenstrasse 9-13 http://www.join.uni-muenster.de D-48149 Muenster / Germany email: schild@uni-muenster.de,phone: +49 251 83 31638, fax: +49 251 83 31653 From willss@mediaone.net Mon Jan 28 10:42:28 2002 From: willss@mediaone.net (Sandy Wills) Date: Mon, 28 Jan 2002 05:42:28 -0500 Subject: asymmetric routing References: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> <20020128075017.6E6691139@postfix1.uni-muenster.de> Message-ID: <3C552B14.94D7EC0A@mediaone.net> (Please forgive me if I'm missing something basic, here. I am familiar with IPv4 from the end user and LAN manager point of view. I subscribed to the 6bone mailing list for the education I'm getting.......) JOIN Project Team wrote, replying to Francis Dupont: > > Basically RFC 2827 / BCP 38 about Ingress Filtering should be used > > for IPv6 too. There are two ways to do ingress filtering: access lists > > and unicast RPF. > > I don't think it's that easy. Please keep in mind, that a site/customer > might be multihomed. In that case he might use a different prefix from that > assigned by the upstream provider as source address. > > Yes, one could filter all but those prefixes a customer holds, but then the > customer has to name all his providers/prefixes. You can't force a customer > to do so, because that information might be confidential. Isn't this reasoning flawed? Customer #1 has prefix A. You let that traffic through. Customer #2 has prefixes X, Y and Z - but he doesn't want you to know about Z because he's afraid that you won't like him. So, you let through traffic with prefixes X and Y. Stop Z. Traffic Z, if any, will go through some other provider, or it won't go through. You're not forcing anyone to do anything. What am I missing? You can limit the prefixes you allow to those your customers tell you about. Your customers can have more than one feed, and he doesn't have to tell you everything. You're not forcing anyone to do anything. He is forcing himself to pay for routers and network people which can direct his traffic out the proper cables, and HE is the one who suffers if HE screws it up. He does NOT have the right to force you to enable routing loops because his routers got confused. -- : Unable to locate coffee. Operator halted. From pim@ipng.nl Mon Jan 28 10:44:56 2002 From: pim@ipng.nl (Pim van Pelt) Date: Mon, 28 Jan 2002 11:44:56 +0100 Subject: asymmetric routing In-Reply-To: <20020128075017.6E6691139@postfix1.uni-muenster.de> References: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> <20020128075017.6E6691139@postfix1.uni-muenster.de> Message-ID: <20020128104456.GA10277@bfib.colo.bit.nl> | I don't think it's that easy. Please keep in mind, that a site/customer | might be multihomed. In that case he might use a different prefix from that | assigned by the upstream provider as source address. | | Yes, one could filter all but those prefixes a customer holds, but then the | customer has to name all his providers/prefixes. You can't force a customer | to do so, because that information might be confidential. Christian, I do not think it is wise for a provider to route traffic from downstream networks he is not fully aware of. And I do not believe I would want to push provider B's traffic on my link for IPv6 like I would do so in the case of IPv4 customers. I would break aggregation in this case. A lot of mischief on the Internet is caused by people spoofing addresses and I feel that every network should have the ingress filtering Francis mentioned in his post. If we all act like you suggest (and keep our downstreams unfiltered outbound) then we create yet another playground for kids who wish to connect a victims chargen or other port to a variety of spoofed (v6) addresses, especially because apparently people are enabling these services all over again while they discover the wonders of IPv6. Yes, truckloads of people have not trimmed /etc/inetd.conf (or equivalents) for their INET6 services. Oh, and I don't think many of my tunnel collecting downstream cablemodem users actually understand the full impact of their configurations either. I'm urging everybody in the tunnelbroker scene (things differ for admins offering connectivity on a b2b basis), to filter ingress. I for one don't want to see IPng address space routed by anyone else than me-myself-and-I ;-) just the same as I do not want to see anybody offering my routers address space it was not specifically told to route. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From pim@ipng.nl Mon Jan 28 15:55:58 2002 From: pim@ipng.nl (Pim van Pelt) Date: Mon, 28 Jan 2002 16:55:58 +0100 Subject: asymmetric routing In-Reply-To: <3C552B14.94D7EC0A@mediaone.net> References: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> <20020128075017.6E6691139@postfix1.uni-muenster.de> <3C552B14.94D7EC0A@mediaone.net> Message-ID: <20020128155558.GA7875@bfib.colo.bit.nl> Regarding my statements on asymmetric routing at IPng, Christian (JOIN) reasoned: | > Yes, one could filter all but those prefixes a customer holds, but then the | > customer has to name all his providers/prefixes. You can't force a customer | > to do so, because that information might be confidential. Sandy said: | Isn't this reasoning flawed? Customer #1 has prefix A. You let that | traffic through. Customer #2 has prefixes X, Y and Z - but he doesn't | want you to know about Z because he's afraid that you won't like him. | So, you let through traffic with prefixes X and Y. Stop Z. Traffic Z, | if any, will go through some other provider, or it won't go through. | You're not forcing anyone to do anything. | What am I missing? You can limit the prefixes you allow to those | your customers tell you about. Your customers can have more than one | feed, and he doesn't have to tell you everything. Well it's not really BGP we were talking about. In the BGP world we can filter updates from downstream customers, which means we will not route traffic to them. But what if the customer, with prefix B, sends traffic originating from B via my networks (and I am prefix aggregator A). Then I will inject traffic into the 6BONE that should not be coming from my routers. This can no longer be taken care of by BGP prefixlist filters, but the need for ACL based filtering arises. The customer with a desire to be multihomed, should respect aggregation policies and not send provider A traffic that comes from prefix B, when A does not advertise B's prefixes into the default free zone. In practice, unless you deliberately deop the traffic, customers will send you any and all traffic they please. Being passive makes you break rules. This is why I brought my first post to the list. But I think we made that point already ;-) | You're not forcing anyone to do anything. He is forcing himself to | pay for routers and network people which can direct his traffic out the | proper cables, and HE is the one who suffers if HE screws it up. He | does NOT have the right to force you to enable routing loops because his | routers got confused. This is a very harsh point of view. In real life, the customer pays you to handle his traffic, and I can very well understand him wanting more than one uplink to different providers, .. , in the ipv4 world this is very normal. However, with IPv6, you (the provider) cannot simply handle any traffic given to you by your customers. This breaks the multihomedness we know and use in IPv4 networking. About dual uplinks and load balancing. These are not layer3 decisions, and can be taken care of at a lower level, eliminating the need of disjunct sets of IPv6 addresses (eg, more than one prefix). Does anybody have info on situations where a customer would want more than one AS to uplink to ? And please look at the future when reasoning, not at the present IPv4 situation. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From mlehman@microsoft.com Mon Jan 28 17:03:40 2002 From: mlehman@microsoft.com (Matthew Lehman) Date: Mon, 28 Jan 2002 09:03:40 -0800 Subject: asymmetric routing Message-ID: Concerning multiple uplinks to different providers; when you use the word customer, I am assuming you mean an entity with provider dependent addressing (Some people will have customers with provider independent addressing). It is a common scenario to want provider diversity to guard against transit provider failure or to implement different policies by service (i.e. Content Delivery Networks, bulk vs. interactive traffic, etc.). This does not seem to be limited to IPv4. There's a draft on this at: http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-00. txt -Matthew > -----Original Message----- > From: Pim van Pelt [mailto:pim@ipng.nl] > Sent: Monday, January 28, 2002 7:56 AM > To: Sandy Wills > Cc: ipng@uni-muenster.de; 6bone > Subject: Re: asymmetric routing > > > Regarding my statements on asymmetric routing at IPng, Christian (JOIN) > reasoned: > | > Yes, one could filter all but those prefixes a customer holds, but > then the > | > customer has to name all his providers/prefixes. You can't force a > customer > | > to do so, because that information might be confidential. > > Sandy said: > | Isn't this reasoning flawed? Customer #1 has prefix A. You let that > | traffic through. Customer #2 has prefixes X, Y and Z - but he doesn't > | want you to know about Z because he's afraid that you won't like him. > | So, you let through traffic with prefixes X and Y. Stop Z. Traffic Z, > | if any, will go through some other provider, or it won't go through. > | You're not forcing anyone to do anything. > | What am I missing? You can limit the prefixes you allow to those > | your customers tell you about. Your customers can have more than one > | feed, and he doesn't have to tell you everything. > Well it's not really BGP we were talking about. In the BGP world we can > filter updates from downstream customers, which means we will not route > traffic to them. But what if the customer, with prefix B, sends traffic > originating from B via my networks (and I am prefix aggregator A). Then > I will inject traffic into the 6BONE that should not be coming from my > routers. > This can no longer be taken care of by BGP prefixlist filters, but the > need > for ACL based filtering arises. The customer with a desire to be > multihomed, > should respect aggregation policies and not send provider A traffic that > comes > from prefix B, when A does not advertise B's prefixes into the default > free > zone. > In practice, unless you deliberately deop the traffic, customers will send > you any and all traffic they please. Being passive makes you break rules. > This is why I brought my first post to the list. But I think we made that > point already ;-) > > | You're not forcing anyone to do anything. He is forcing himself to > | pay for routers and network people which can direct his traffic out the > | proper cables, and HE is the one who suffers if HE screws it up. He > | does NOT have the right to force you to enable routing loops because his > | routers got confused. > This is a very harsh point of view. In real life, the customer pays you to > handle his traffic, and I can very well understand him wanting more than > one > uplink to different providers, .. , in the ipv4 world this is very normal. > However, with IPv6, you (the provider) cannot simply handle any traffic > given > to you by your customers. This breaks the multihomedness we know and use > in > IPv4 networking. > > About dual uplinks and load balancing. These are not layer3 decisions, and > can be taken care of at a lower level, eliminating the need of disjunct > sets > of IPv6 addresses (eg, more than one prefix). Does anybody have info on > situations where a customer would want more than one AS to uplink to ? And > please look at the future when reasoning, not at the present IPv4 > situation. > > groet, > Pim > -- > ---------- - - - - -+- - - - - ---------- > Pim van Pelt Email: pim@ipng.nl > http://www.ipng.nl/ IPv6 Deployment > ----------------------------------------------- From lucifer@lightbearer.com Mon Jan 28 17:34:04 2002 From: lucifer@lightbearer.com (Joel Baker) Date: Mon, 28 Jan 2002 10:34:04 -0700 Subject: asymmetric routing In-Reply-To: <20020128075017.6E6691139@postfix1.uni-muenster.de>; from ipng@uni-muenster.de on Mon, Jan 28, 2002 at 08:50:38AM +0100 References: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> <20020128075017.6E6691139@postfix1.uni-muenster.de> Message-ID: <20020128103404.A27393@lightbearer.com> On Mon, Jan 28, 2002 at 08:50:38AM +0100, JOIN Project Team wrote: > Am Sonntag, 27. Januar 2002 18:06 schrieb Francis Dupont: > > Basically RFC 2827 / BCP 38 about Ingress Filtering should be used > > for IPv6 too. There are two ways to do ingress filtering: access lists > > and unicast RPF. > > I don't think it's that easy. Please keep in mind, that a site/customer > might be multihomed. In that case he might use a different prefix from that > assigned by the upstream provider as source address. > > Yes, one could filter all but those prefixes a customer holds, but then the > customer has to name all his providers/prefixes. You can't force a customer > to do so, because that information might be confidential. > > Christian Except that unlike IPv4, IPv6 doesn't even support the notion of a multi- homed network, except in drafts, really. That being the whole (misguided) point of aggregation - to reduce your routing tables and may traffic flows more tractable. Not that I think it's a good idea - but it *is* perfectly legitimate to deny any traffic that is not sourced from a network *you route* to that customer (this is the basis of unicast filtering) - and at least under IPv6 it is, as far as I can see, reasonable to only route what you have assigned to them. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer@lightbearer.com http://users.lightbearer.com/lucifer/ From bmanning@ISI.EDU Mon Jan 28 18:47:44 2002 From: bmanning@ISI.EDU (Bill Manning) Date: Mon, 28 Jan 2002 10:47:44 -0800 Subject: 6bone pTLA 3FFE:8330::/28 allocated to CSTNET In-Reply-To: <5.1.0.14.0.20020123165652.02716a30@imap2.es.net> References: <5.1.0.14.0.20020123165652.02716a30@imap2.es.net> Message-ID: <20020128184744.GE76554@zed.isi.edu> On Wed, Jan 23, 2002 at 04:57:57PM -0800, Bob Fink wrote: > CSTNET has been allocated pTLA 3FFE:8330::/28 having finished its 2-week > review period. > > > > > Note that it will take a short while for their pTLA inet6num entry to > appear in the 6bone registry as they have to create it themselves. However, > their registration is listed on: > > > > > [To create a reverse DNS registration for pTLAs, please send the prefix > allocated above, and a list of at least two authoritative nameservers, to > either bmanning@isi.edu or hostmaster@ep.net.] > > > Thanks, > > Bob Looking forward to the update. Until then, this entry has been placed in the DNS: % dig 3.3.8.e.f.f.3.ip6.int ns @::1 ; <<>> DiG 9.2.0 <<>> 3.3.8.e.f.f.3.ip6.int ns @::1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40784 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;3.3.8.e.f.f.3.ip6.int. IN NS ;; AUTHORITY SECTION: 3.3.8.e.f.f.3.ip6.int. 86400 IN NS noserver. ;; Query time: 9 msec ;; SERVER: ::1#53(::1) From michael@kjorling.com Mon Jan 28 19:42:08 2002 From: michael@kjorling.com (Michael Kjorling) Date: Mon, 28 Jan 2002 20:42:08 +0100 (CET) Subject: asymmetric routing In-Reply-To: <20020128155558.GA7875@bfib.colo.bit.nl> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Well, I am not 100% sure how the big guys solve this (that is, probably most of you), but what about redundancy in case of malfunctions? Say, someone digs through a cable (don't laugh! This has happened to me!). Or some other failure that you have no way to control. Such problems can be completely unrelated to whether you are using IPv4 or IPv6. In fact, I haven't ever heard of anyone cutting through a cable by accident first asking "OK, what transport protocol is being used on this one?" Michael Kjörling On Jan 28 2002 16:55 +0100, Pim van Pelt wrote: > About dual uplinks and load balancing. These are not layer3 decisions, and > can be taken care of at a lower level, eliminating the need of disjunct sets > of IPv6 addresses (eg, more than one prefix). Does anybody have info on > situations where a customer would want more than one AS to uplink to ? And > please look at the future when reasoning, not at the present IPv4 situation. > > groet, > Pim - -- Michael Kjörling -- Programmer/Network administrator ^..^ Internet: michael@kjorling.com -- FidoNet: 2:204/254.4 \/ PGP: 95f1 074d 336d f8f0 f297 6a5b 2aa3 7bfd 8a70 e33e ``And indeed people sometimes speak of man's "bestial" cruelty, but this is very unfair and insulting to the beasts: a beast can never be so cruel as a man, so ingeniously, so artistically cruel.'' (Ivan Karamazov, in Dostoyevsky's 'The Brothers Karamazov') *** Thinking about sending me spam? Take a close look at *** http://michael.kjorling.com/spam/ before doing so. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Public key is at http://michael.kjorling.com/contact/pgp.html iD8DBQE8VamVKqN7/Ypw4z4RAvtiAKDlUfqoWhw3qbIqgesZeJqtSoO+JQCg+NKJ aNmHHMTWwabLRX+f4T0ymiM= =T8ur -----END PGP SIGNATURE----- From rpearso1@tampabay.rr.com Mon Jan 28 19:54:07 2002 From: rpearso1@tampabay.rr.com (Richard & Kathleen Pearson) Date: Mon, 28 Jan 2002 14:54:07 -0500 Subject: asymmetric routing In-Reply-To: Message-ID: <004d01c1a835$8cb093c0$d7d82341@tampabay.rr.com> This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C1A80B.A3DA8BC0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Please remove me from the distribution list. This is the 3rd time I have asked. If not complied with, I will report these messages a spam mail. Thanks -----Original Message----- From: owner-6bone@ISI.EDU [mailto:owner-6bone@ISI.EDU]On Behalf Of Matthew Lehman Sent: Monday, January 28, 2002 12:04 PM To: Pim van Pelt; Sandy Wills Cc: ipng@uni-muenster.de; 6bone Subject: RE: asymmetric routing Concerning multiple uplinks to different providers; when you use the word customer, I am assuming you mean an entity with provider dependent addressing (Some people will have customers with provider independent addressing). It is a common scenario to want provider diversity to guard against transit provider failure or to implement different policies by service (i.e. Content Delivery Networks, bulk vs. interactive traffic, etc.). This does not seem to be limited to IPv4. There's a draft on this at: http://www.ietf.org/internet-drafts/draft-ietf-multi6-v4-multihoming-00. txt -Matthew > -----Original Message----- > From: Pim van Pelt [mailto:pim@ipng.nl] > Sent: Monday, January 28, 2002 7:56 AM > To: Sandy Wills > Cc: ipng@uni-muenster.de; 6bone > Subject: Re: asymmetric routing > > > Regarding my statements on asymmetric routing at IPng, Christian (JOIN) > reasoned: > | > Yes, one could filter all but those prefixes a customer holds, but > then the > | > customer has to name all his providers/prefixes. You can't force a > customer > | > to do so, because that information might be confidential. > > Sandy said: > | Isn't this reasoning flawed? Customer #1 has prefix A. You let that > | traffic through. Customer #2 has prefixes X, Y and Z - but he doesn't > | want you to know about Z because he's afraid that you won't like him. > | So, you let through traffic with prefixes X and Y. Stop Z. Traffic Z, > | if any, will go through some other provider, or it won't go through. > | You're not forcing anyone to do anything. > | What am I missing? You can limit the prefixes you allow to those > | your customers tell you about. Your customers can have more than one > | feed, and he doesn't have to tell you everything. > Well it's not really BGP we were talking about. In the BGP world we can > filter updates from downstream customers, which means we will not route > traffic to them. But what if the customer, with prefix B, sends traffic > originating from B via my networks (and I am prefix aggregator A). Then > I will inject traffic into the 6BONE that should not be coming from my > routers. > This can no longer be taken care of by BGP prefixlist filters, but the > need > for ACL based filtering arises. The customer with a desire to be > multihomed, > should respect aggregation policies and not send provider A traffic that > comes > from prefix B, when A does not advertise B's prefixes into the default > free > zone. > In practice, unless you deliberately deop the traffic, customers will send > you any and all traffic they please. Being passive makes you break rules. > This is why I brought my first post to the list. But I think we made that > point already ;-) > > | You're not forcing anyone to do anything. He is forcing himself to > | pay for routers and network people which can direct his traffic out the > | proper cables, and HE is the one who suffers if HE screws it up. He > | does NOT have the right to force you to enable routing loops because his > | routers got confused. > This is a very harsh point of view. In real life, the customer pays you to > handle his traffic, and I can very well understand him wanting more than > one > uplink to different providers, .. , in the ipv4 world this is very normal. > However, with IPv6, you (the provider) cannot simply handle any traffic > given > to you by your customers. This breaks the multihomedness we know and use > in > IPv4 networking. > > About dual uplinks and load balancing. These are not layer3 decisions, and > can be taken care of at a lower level, eliminating the need of disjunct > sets > of IPv6 addresses (eg, more than one prefix). Does anybody have info on > situations where a customer would want more than one AS to uplink to ? And > please look at the future when reasoning, not at the present IPv4 > situation. > > groet, > Pim > -- > ---------- - - - - -+- - - - - ---------- > Pim van Pelt Email: pim@ipng.nl > http://www.ipng.nl/ IPv6 Deployment > ----------------------------------------------- ------=_NextPart_000_004E_01C1A80B.A3DA8BC0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IggTAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAcAA4ANgAAAAEAOwEB A5AGACwPAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAATAAAAYXN5bW1ldHJpYyByb3V0aW5nAAACAXEAAQAAABYAAAABwag1i4uMpaKf E2gR1riUAICtRmktAAACAR0MAQAAAB4AAABTTVRQOlJQRUFSU08xQFRBTVBBQkFZLlJSLkNPTQAA AAsAAQ4AAAAAQAAGDgA8UIc1qMEBAgEKDgEAAAAYAAAAAAAAAMsvD0DCar8Rqe5irxiwMd3CgAAA AwAUDgEAAAALAB8OAQAAAAIBCRABAAAAJQsAACELAAACFQAATFpGdUKNHioDAAoAcmNwZzEyNeIy A0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBjaOEKwHNldDIGAAbDESX2 MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUDMLCQFkMzYWUAumIFBobGVhFBAgGCAEYHaLHUAH gCADUiB0aB1ACmQEAHQFEGJ1dGkJAiAgbB6hLiAgVNpoBAAgH/EeUjMLIB5AcQdxIEkgE+AdoR0g a4MJgB+hSWYgbm8FQH0FoG0LUAiQILAD8B5QLNshEQPwbAMgGCBwF8EeQiMdMQeBc2FnB5FhIN5z CrAeMADAAxAuCqIKhKcKgB/QAHBrcyYKLSfi+k8FEGcLgAdABdAkxCfjBSYERgNhOiBvd24ZBJAt NgbgKmBASVOASS5FRFUgWyWymHRvOipPK1BdTwOglEJlE+BsIiBPZiYE3E1hAkAeYAfgTC2AA4Ev JgQGYAIwKiBNAiBkYSp5I1BKAHB1CsB5IGwyOCNQAdAwFEAOIDr0MDQc4E0mZSvgHOAHcKQgdgOR UGUrwDsGAppkMOBXI6EnFUNjKiAhBSBuZ0B1AwAtbecKUACADrByLgEAM3AqozEvRXViagWQL9FS Rd8qIB0gBsAHgB7BYx1QCGDfHxA1ACYKNEUCIGMEkTixnR3AdSvABSAdACB1IrF7JvEeQG8egQEg BJAvsSBScANgdmkEgXMzcHf7HmADoHkIYDswHTEeUSYEdncFsCCwYz3QK9AHgHLHI1IlgR0gc3Vt OnI9kv8HgAORA5EvsSMgMOAjEjyHPx6AI/AJ8AEAAjAmBGFkzmQYIAQQOnIoUz8xPID8ZW87AiOT IUM+9gQgQazXC4BCj0OWKSX7SQVAH/H/JUAigQRgA6AE8AnwCsAfIP07sncAcDx4HoEdoBQAQWL9 O8FnMLEgsCTwC3EesCYE9x7AAHJLiWYlwQhwHUAFsf87wQdwOwEHgDxhO/kG8A3g2wiQBCBiMOAU EHI8wDow4SYEKGkuZR+gOgEOsL08YUQzQExCMOAHwHQ+oacnACNQHvBsazLgcx+g/wuANcEA0B8Q HaFOMQEgDeAzI1AUIGMuSMYf02Rv3weRIkIUEB1wO7JiHUAfYA9AIA6wILE70ElQdjT7H6M8MScl IkOQVnAFQB8xLx5QSdIv0CYEaAJAcDpoLy93XNAuCJAAMC6ZBbBnL1WTLCB0LVrzdHMvWvMtXRI1 YTrRNrYtWgBfRGgDcDixLTFQPyX1DNBHtSeFLmUmCj4gvyfvKP1jcCnkMrord3AHcMJANOIubmxd YxYvr+EwvDc6NTYQwDIFY3B/MnIzn2NwNK81v2hUNwdl/zevOLdjcHFeb/BNcAsgOnP/UgEBkA6w UHIEIB8xcD86kM8ucFnRbVAjUENoBRAesAMHMC81KEpPSU4pb2MWGCAdICrBZFv1Y3B8+iBjcFkH kCNQKsEicTrA/yCwVpArwBKBB0ADIB7xHkHObx0xPJABEGl4JRM+9vshMAbwZFTTR7VjcB5RW2L/ btd5InxYHSA7smQwHdF6wlsf4jyXL3umH6BZPaFj7QBwJwVAAhByOjAhgGMWfz72eKo7wjvQeEBU 4QWQYX891HWxC4CC8QDAHxNAIGf/XGBY8gWghqA80UFBB0Al9T9xuGvEJOA80HiZivFJc6+CsluD eBQ6cmYLYHcJgOY/EiB8ZiMxf8N7pBDA/x+hglIdAE3GhlF4qFZVHkF/OHGHcB+hjQgUQI3IB5FY 7SNQWUDxILBaY4B68z4mv1fygrF4qEtTPZI7wWsiQP8H4AGgOIGTkYXGHmBaogNQ/4ohhjQ9kj6g grIfYCGwXAX/B3CIp3kgRDAjUD2SjvGQ1q+QV0GlkqaTU1kfoVMr0J5wk5AfolZkJgRaLHio7waQ QPFpUSOTZ0sBm8V4QP8d0SJQWmE8h3mRRvEFQJkU96EomkmCUSdPkSJCgvJ1c3+gkHmyhSSggVuB Z8GKa1f/hlIlgSEgQCBDw4zggkZZJP8eQ3unPZJ6wZaRO8F7Q3io/z2RBcBFmA6wI7Grg5bSjoT/ rXqqEiFDBGBPkYZBLzVuuf95IDwgCYAjUJNiHmKUtCE026wirkZlVBKnbFeuQiMgH1qhIkJ4ESOw MOBCR1DfIwBE0TwxHkAHQGt1c67U/kl+M7dUBbB6IYywJgSCkf9jFnpVO0BpMA6wBCAeA1fw/ywQ HrEdEB4wRZegsR/gE9D/QKNGEUTVIkEmBDhybteQZ/ehMh1wH6BCexE9QIZiIiD/HlI++Jy5LWAj UBQQaSAnFb9WVWMWBbBkA3VjHgNCMuD/BzBzYl3xVJNEEJNiP5OOBd8k8AnBTXAr0AXAQVcoCfD/ YxYjdQuANyKQV1WRwSM2MNBCT05FhjRzYEB6Ev8iQoezQCMeA3Nwd5e/0hQA/4inH9OqEiJAH1AC ICUABcD/WQEBkCGwA6CCkE+SIiBR8f+3YnukH2J6RX0kfkosIAmA87rXyZJDTFHgHSF6NnVzf3Zh ghJaUXxIQaNa0QeQaf+w4ljiYxZf9rKhYxbNtUOh/0dQy8HJFh8iUWeTYlhEk3H9QfdBVkaPLyJy B5C61x4S/8OYPUPf4Ff3Q3BMUR8QHTH+Qlqhe6fMdwEBhfArwOHo+wngYxZ6KsGIp7kRPJBV4v86 MCNQbYAdAAQRPZIBAB9g/1kATkCuMTDgAQCeUR5SVlf/RZojsCYExDJjFquDoJCTU3t6wpBoZTDg OwEdIcGBZb86cgqwQ8EdotJhq2RieBH+a79lOsCCEdB7H/E9QDDg/yEg8hCREgVAc3FWkBQAUUL/ 1CHMlR9kwaIhIKdiVTC3of8AwAEA4H9RUVWRerF4ETPB/Dstd4eKa6U/pk+nVR+w/kgdQB/x/Baa ERQQLbBN1f5veKgKsPURBbHP9d50VHT/RHe+A6oSHpAYIMvBH+KQZv84gffmfnk8kUdQrXEMoOnB fbLESM1AICV5sj1AhWF1vzwSIAEiIAcRSpAYIHcgAR/kMDtA/eN4qFfzTk9U/7PFHmFj8YeBO8GC 9JYFSrH/BnF1JxewnlBR0YXUmbZsZ/+K4AEGoSAiYoagl4Eh0PMu/yVAVBMV8kHR+RPTATzAFwD/ uPO28h9RsoAjUMJqAHInFfeWBGMWJtFkOxEDybLEISD/qhJUE4ywI7FtgIFi0lCy8v8ywUtSOnOw 0ffnusduuTtE9zu/PMQjUC6ekCNQZCD2A/9tMF/AubVbg/PBVBJ21PvQe4bRiJhILAC04sMlWeE2 7ZsUKKq033QpgoJYQ1Ai/xLSF5OggcSPY1JkELCQusf/HeHx0zDgrUzYcvPB8hMHVP/bGF3w6eG3 oZZ07aYO12Nwv2QgypdZ8cdmp4pjFkGW0/5kTRAZ0TtVk2Kr4ENw1wH/jJA6IP2z2JHkwdLC+9KM kPp5XdAzQnHeMEPQdFBU0P9DFe2oqhLSL6iy0aG30Y7h/bCQbFbBWTLGJfYS1dLS8fuURalAam2A 3QDbx48AbGff0wEjwuRBQ5OdYShy4Glg/7DHeaN7pEjAU8AK0qCBbqD/ieFFQ4aSsVbbx06ATRCH An/0ArfifDkB8HoSS1M9zEHWU1miHXg/dtRB7ajwFP8OIlUwdbH2EhEgQbBPkeNT/4vnaWDkE6qX xDF1wl/AQR/3L9/dUArQdJ+nZhFjGGMb32OTk7GTwIrxT/MrT/xPZ/dNmWZIU55FZvJo4GdpFveb XHlntC9TmzyDRGUCcH5vdKBosU7vWj9bT2T4fQFdEAAAAB4AQhABAAAAUQAAADxDMkEyNTY2OTZE MTdFNDRDOUFEQzk1QTc3RkU5NTk5NzA1NUNDRkQwQHJlZC1tc2ctMDUucmVkbW9uZC5jb3JwLm1p Y3Jvc29mdC5jb20+AAAAAAMACVkBAAAACwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAAD AAKACCAGAAAAAADAAAAAAAAARgAAAAAQhQAAAAAAAAMABYAIIAYAAAAAAMAAAAAAAABGAAAAAFKF AAC2dAEAHgAlgAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAMAJoAIIAYAAAAA AMAAAAAAAABGAAAAAAGFAAAAAAAACwAvgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADADCA CCAGAAAAAADAAAAAAAAARgAAAAARhQAAAAAAAAMAMoAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAA AAAACwDVgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAACAfgPAQAAABAAAADLLw9Awmq/Eanu Yq8YsDHdAgH6DwEAAAAQAAAAyy8PQMJqvxGp7mKvGLAx3QIB+w8BAAAAUQAAAAAAAAA4obsQBeUQ GqG7CAArKlbCAABtc3BzdC5kbGwAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcTXkgRG9jdW1lbnRz XG91dGxvb2sucHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMENCMkYw RjQwQzI2QUJGMTFBOUVFNjJBRjE4QjAzMUREMDQxNzE1MDEAAAAAAwAGEBf0uU0DAAcQdA0AAAMA EBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABQTEVBU0VSRU1PVkVNRUZST01USEVESVNUUklCVVRJ T05MSVNUVEhJU0lTVEhFM1JEVElNRUlIQVZFQVNLRURJRk5PVENPTVBMSUVEV0lUSCxJV0lMTFJF UE9SVFRIRVNFTUVTAAAAAOsg ------=_NextPart_000_004E_01C1A80B.A3DA8BC0-- From michel@arneill-py.sacramento.ca.us Mon Jan 28 21:06:42 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 28 Jan 2002 13:06:42 -0800 Subject: asymmetric routing Message-ID: <2B81403386729140A3A899A8B39B046405DE79@server2000.arneill-py.sacramento.ca.us> I mostly agree with Pim's postings. > Does anybody have info on situations where a customer would want > more than one AS to uplink to. Practically speaking, it is not possible today. Unless you are a transit provider, there are no practical advantages today in peering with two different ASNs except experimenting. 1. In the current situation (meaning, no IPv6 multihoming), I don't see a reason NOT to filter customer's (ACL) by denying everything except the customer's PA prefixes. The only IPv6 addresses being assigned today are PA (provider assigned), not PI (provider independent). Assymetric routing (meaning, across different providers connected to one customer) should (eventually) occur only with PI addresses. If a provider sees traffic from a customer originating from PA address space that does not belong to that customer/provider pair, it means: a) spoofing b) the customer's is multihomed and the multihoming source address selection or policy routing (that currently does not exist) is broken. c) the customer is being used as a transit provider. This means a cluster f... in the routing and the customer should also filter to avoid this. 2. In the future, and as both the acting editor for the IPv6 multihoming requirements draft and the author of an IPv6 solution draft, http://search.ietf.org/internet-drafts/draft-py-multi6-mhtp-01.txt I think that IPv6 multihoming solutions to be developped will either: a) be host-based multi-address solution with a PA address selection mechanism combined with source-address based policy routing. b) implement a PI (provider independent) address space. In either case, filtering customer's PA traffic by restricting traffic from and to the address space that the provider assigned to the customer will NOT break the multihoming scheme. The difference between IPv4 and IPv6 is that IPv6 is strongly aggregated. As of today, no provider should accept routes from customers that they do not own. There is no reason to accept traffic from prefixes that they do not own eiher. ACL filtering should match BGP filtering. In short: it is too early to assume anything about IPv6 PI addresses as of today. For IPv6 PA addresses, DO filter. If you break something, that something should not have happened in the first place. Michel. From villearc@stealth.net Tue Jan 29 02:00:11 2002 From: villearc@stealth.net (Ville) Date: Mon, 28 Jan 2002 21:00:11 -0500 (EST) Subject: asymmetric routing In-Reply-To: <20020127112830.GA28143@bfib.colo.bit.nl> Message-ID: Pim, On Sun, 27 Jan 2002, Pim van Pelt wrote: > (snip) > What do the folk from Cisco think about these anti-spoof measures being set > to enabled state per default (user overridable of course) ? Well, not being from Cisco, strictly from an NSP point of view, I would wonder the feasibleness of forcing such political decisions with the means of hardware. ,) -- As I see it, it is not all about anti-spoof, a fair part of it constitutes simply from plain host-based routing with basic cheapest-path-wins. Uplinks and global BGP cannot know about any such decisions taken. Anyhow, FWIW- Sample configurations are one thing, defaults are another. Count the times people wanted all routing h/w to ignore ICMP echo-requests by default for the sheer cause of ``ping -f''. Sum that up with the amount of other similar suggestions during previous years and the way how time does wear them off? Sure, such defaults are ideal, but as they begin summing up, they do make initial and fault-time debugging a nightmare. Similarly, they may well result in unintended loss of CPU-time as seemingly similar header-data is scanned at multiple hops, all inside one organization or even at the same POP. Thing considered valid at the border may not be considered wise at the core - and vice versa. After the smurf-era, I believe Unicast RPF (Reverse Path Forwarding) was sufficiently discussed. For what I can see, the discussed functionality does exist in the degree necessary and and is easy to enable where desired. For any simple end-site, it probably really is the preferred course of action. interface/ # ip verify unicast reverse-path [ie. verify any packet received on the interface for source-validity by the means of checking availability of existing path back to the source via the same IF.] And yes, as an end-user, I probably do despise IP-spoofing in a rather similar degree. > Pim Cheers, -- Ville Network Security/IPv6 Solutions Stealth Communications, Inc. From villearc@stealth.net Tue Jan 29 02:43:43 2002 From: villearc@stealth.net (Ville) Date: Mon, 28 Jan 2002 21:43:43 -0500 (EST) Subject: asymmetric routing In-Reply-To: <2B81403386729140A3A899A8B39B046405DE79@server2000.arneill-py.sacramento.ca.us> Message-ID: Michel, On Mon, 28 Jan 2002, Michel Py wrote: > a reason NOT to filter customer's (ACL) by denying everything except the > customer's PA prefixes. [...] Assume the case of a content-provider (return-traffic business) - If one, as an end-user, receives transit from two different providers (flat-rate FLAT1, pay-per-bandwidth PPBW2) and sub- sequently receives two separate prefixes (2001:FLAT1:cust::, 2001:PPBW2:cust::), he would probably rather route back any and all non-local traffic via FLAT1 unless the circuit in question is already overloaded. Perhaps the specific IP-address used belongs to PPBW2 simply because they provide better service in cases of failure and offer stability (whereas FLAT1 could be changed into another flat-rate provider FLAT2 with no change visible to the end-user as their addresses are not used for anything). Any reason to tell a paying customer you are not willing to let his elsewhere-belonging packets travel back through your network just because s/he prefers static routing? Talking in the gigabit- range, yet about sites that do not qualify for (or desire) a direct PI-allocation. Carriers can hardly be expected to babysit players of size as they will only move elsewhere if mistreated. Another example: User wants to preserve his old pay-per-bandwidth IP-address 2001:PPBW2:cust::1 which is a bandwidth-exploder service (say, anonymous FTP). He downgrades this specific PPBW2-pipe from GigE into the 2 Mbit class while upgrades his connection to FLAT1 into 10GigE. Problem solved: He pushes everything back [in direct contradiction with the proposal and unicast-rpf] via FLAT1, which boasts lots of unoccupied b/w and does not charge by the byte. 2 Mbit is well enough for the incoming "PASS ftp@", "PASV" and "LIST" via PPBW2, while all true data is pushed back through the flat-rate 10GigE provided by FLAT1. Not really commenting on neither the current state of things nor the future I either envision or fear. I am rather trying to build a sample of what I would view as some of the schemes expectable. > Michel. Cheers, -- Ville Network Security/IPv6 Solutions Stealth Communications, Inc. From pim@ipng.nl Tue Jan 29 07:55:07 2002 From: pim@ipng.nl (Pim van Pelt) Date: Tue, 29 Jan 2002 08:55:07 +0100 Subject: Need for N-homedness (was Re: asymmetric routing) In-Reply-To: References: <20020128155558.GA7875@bfib.colo.bit.nl> Message-ID: <20020129075507.GA4703@bfib.colo.bit.nl> | Well, I am not 100% sure how the big guys solve this (that is, | probably most of you), but what about redundancy in case of | malfunctions? Say, someone digs through a cable (don't laugh! This has | happened to me!). Or some other failure that you have no way to | control. | | Such problems can be completely unrelated to whether you are using | IPv4 or IPv6. In fact, I haven't ever heard of anyone cutting through | a cable by accident first asking "OK, what transport protocol is being | used on this one?" | Michael, others, I believe it is a common misconception that having redundant uplinks have something to do with which protocol you speak and, having redundant uplinks (two fiber pairs to your ISP(s)) also has nothing to do with dualhomedness. Riverstone for example, has a 'smart trunk' functionality, which means combining two or more physical ports (ether, pos, atm, gige) into one layer3 endpoint, enabling packet-for-packet loadbalancing over two lines, or some crude (at that time) form of QoS routing, by sending realtime over link A and lower prio over link B. We used to have two E1 links between two locations, with the restriction that both links started and ended in the same physical box (note the SPoF here). You can easily have multiple fibers with layer2 also, think of fast spanning tree or other (faster) protocols like VRRP. Again, no need for more than one aggregating ISP. The ISP can buy transit from more than one carrier, can set up iBGP sessions with two of the customer (downstream) routers via two cables, for all I care: TRANSIT1-(R1)------fiber-to-customer-----(R3)---\ | | |------network at customer TRANSIT2-(R2)-----backup-E1-to-customer--(R4)---/ (fear my ascii art - best viewed in xterm, not in Outlook et al :) ISP has R1/R2, interconnected and each one having an uplink with a full view of the dfz via seperate transit providers. Customer has R3/R4, each linking to an ISP via a seperate physical circuit, and handling the customers network via VRRP (a protocol which switches 'the default gw' between R3 and R4 if either one fails). Most new hardware does this. I fail to see any need for more than one prefix per customer, and still say that IF a customer has more than one prefix, his R3/R4 should preform source based policy routing, sending traffic from prefixA through the circuits to ISPA and traffic from prefixB to ISPB. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment ----------------------------------------------- From David Terrell Tue Jan 29 09:56:47 2002 From: David Terrell (David Terrell) Date: Tue, 29 Jan 2002 01:56:47 -0800 Subject: asymmetric routing In-Reply-To: <20020128075017.6E6691139@postfix1.uni-muenster.de>; from ipng@uni-muenster.de on Mon, Jan 28, 2002 at 08:50:38AM +0100 References: <200201271706.g0RH6Ig26360@givry.rennes.enst-bretagne.fr> <20020128075017.6E6691139@postfix1.uni-muenster.de> Message-ID: <20020129015647.A3155@pianosa.catch22.org> On Mon, Jan 28, 2002 at 08:50:38AM +0100, JOIN Project Team wrote: > Am Sonntag, 27. Januar 2002 18:06 schrieb Francis Dupont: > > Basically RFC 2827 / BCP 38 about Ingress Filtering should be used > > for IPv6 too. There are two ways to do ingress filtering: access lists > > and unicast RPF. > > I don't think it's that easy. Please keep in mind, that a site/customer > might be multihomed. In that case he might use a different prefix from that > assigned by the upstream provider as source address. > > Yes, one could filter all but those prefixes a customer holds, but then the > customer has to name all his providers/prefixes. You can't force a customer > to do so, because that information might be confidential. If my customer doesn't want me to know what prefixes he owns, he shouldn't send traffic from them to me, or I'll know. -- David Terrell | "Anyone want to start a fund for students Nebcorp Prime Minister | that vow not to work at MS?" dbt@meat.net | - Libor Michalek http://wwn.nebcorp.com/ From Francis.Dupont@enst-bretagne.fr Tue Jan 29 13:08:50 2002 From: Francis.Dupont@enst-bretagne.fr (Francis Dupont) Date: Tue, 29 Jan 2002 14:08:50 +0100 Subject: asymmetric routing In-Reply-To: Your message of Mon, 28 Jan 2002 08:50:38 +0100. <20020128075017.6E6691139@postfix1.uni-muenster.de> Message-ID: <200201291308.g0TD8og32797@givry.rennes.enst-bretagne.fr> In your previous mail you wrote: > Basically RFC 2827 / BCP 38 about Ingress Filtering should be used > for IPv6 too. There are two ways to do ingress filtering: access lists > and unicast RPF. I don't think it's that easy. Please keep in mind, that a site/customer might be multihomed. In that case he might use a different prefix from that assigned by the upstream provider as source address. => there are some cases where uRPF can't work but there are some myths too about uRPF limitations, look at: http://www.cisco.com/public/cons/isp/documents/uRPF_Enhancement.pdf Yes, one could filter all but those prefixes a customer holds, but then the customer has to name all his providers/prefixes. You can't force a customer to do so, because that information might be confidential. => in fact we don't need ingress filtering everywhere, we just need enough ingress filtering in order to make random source address spoofing unattractive. The current issue with IPv6 ingress filtering is not (yet) multi-homing, this is simply the lack of tools... Regards Francis.Dupont@enst-bretagne.fr From michel@arneill-py.sacramento.ca.us Tue Jan 29 15:56:01 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 29 Jan 2002 07:56:01 -0800 Subject: asymmetric routing Message-ID: <2B81403386729140A3A899A8B39B046405DE7B@server2000.arneill-py.sacramento.ca.us> Ville, >> Michel Py wrote: >> a reason NOT to filter customer's (ACL) by denying everything >> except the customer's PA prefixes. [...] > Ville wrote: > Assume the case of a content-provider (return-traffic business) > If one, as an end-user, receives transit from two different > providers (flat-rate FLAT1, pay-per-bandwidth PPBW2) and sub- > sequently receives two separate prefixes (2001:FLAT1:cust::, > 2001:PPBW2:cust::), he would probably rather route back any and > all non-local traffic via FLAT1 unless the circuit in question > is already overloaded. > [SNIP] Technically, a valid scenario. Realistically, not much. I know lots of people that, placed in the shoes of FLAT1, will deny return traffic with a source address that belongs to PPBW2. The rationale is: PPBW2 is my direct competitor. If I have to carry their traffic I want money for that. In terms of fault tolerance, this is worse than a single link. If either link is broken, the content providing is gone. The chances of having one link broken out of two are twice those of a single link. It would be better to have the traffic originating to FLAT1 in the first place as the "PASS ftp@", "PASV" and "LIST" will not change much of the bandwidth situation. In this situation, the backup link still makes sense for a MX with higher priority to keep email flowing and still providing access to the net. However, there is no gain in policing the return traffic originated to PPBW2 to return over FLAT1. If FLAT1 is down, you are down anyway. Michel. From michel@arneill-py.sacramento.ca.us Tue Jan 29 16:24:50 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 29 Jan 2002 08:24:50 -0800 Subject: Need for N-homedness (was Re: asymmetric routing) Message-ID: <2B81403386729140A3A899A8B39B046406C29E@server2000.arneill-py.sacramento.ca.us> Pim, > Pim van Pelt wrote: > (fear my ascii art - best viewed in xterm, not in Outlook et al :) Actually, it displays OK in Outlook. > TRANSIT1-(R1)----fiber-to-customer-----(R3)---\ > | | |------network at customer > TRANSIT2-(R2)---backup-E1-to-customer--(R4)---/ This setup is good enough for most. Unfortunately, it is not available everywhere, and it does not provide redundancy if something happens to R1-R2 that are located in the same building. > I fail to see any need for more than one prefix per customer, I assume you mean more than one provider independant (PI) prefix. The main driving force behind that is the elimination of (PI) addresses, One of the animals that clog the IPv4 DFZ today. It is too early to know if there will be ANY IPv6 PI addresses at all. > and still say that IF a customer has more than one prefix, his R3/R4 > should preform source based policy routing, sending traffic from prefixA > through the circuits to ISPA and traffic from prefixB to ISPB. Definitely. However, this is not enough. There are two other problems with this scheme (that is likely to become part of the IPv6 multihoming solution): 1. Address selection by the source that has to choose between ISPA ans ISPB. 2. Make sure that the host (server) that has two addresses, uses the correct one to return the traffic (the one that the traffic was sent to). Michel. P.S. I think that this thread should be switched to the multi6 mailing list. From michel@arneill-py.sacramento.ca.us Tue Jan 29 17:30:55 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 29 Jan 2002 09:30:55 -0800 Subject: asymmetric routing Message-ID: <2B81403386729140A3A899A8B39B046405DE7C@server2000.arneill-py.sacramento.ca.us> 6bone folk, >> Basically RFC 2827 / BCP 38 about Ingress Filtering should be >> used for IPv6 too. There are two ways to do ingress filtering: >> access lists and unicast RPF. > I don't think it's that easy. Please keep in mind, that a > site/customer might be multihomed. In that case he might use a > different prefix from that assigned by the upstream provider as > source address. FYI: I just added the following text as a proposed requirement For IPv6 multihoming solutions. "IPv6 multihoming solutions MUST be compatible with sites that implement RPF checks or filtering that prevents traffic to be sent back from a different interface it came in." I welcome your comments on: 1. Is this posting on-topic for the 6bone list? In other words, is it appropriate to post here some multi6 topics that have implications for the 6bone folks for the benefit of those who do not subscribe to the multi6 mailing list? 2. if yes, the text itself. Michel. From dave.wilson@heanet.ie Wed Jan 30 15:58:57 2002 From: dave.wilson@heanet.ie (Dave Wilson) Date: Wed, 30 Jan 2002 15:58:57 +0000 Subject: asymmetric routing References: <2B81403386729140A3A899A8B39B046405DE7C@server2000.arneill-py.sacramento.ca.us> Message-ID: <3C581841.9030104@heanet.ie> I think the harm caused by sloppy aggregation of address space is clear. I think the harm caused by inadequate filtering of source addresses is also clear. These are separate considerations, however. Forwarding traffic with a source address that is not your own, for good or ill, doesn't harm the routing table in the same way that unaggregated advertisements do, and so it seems to me it's entirely compatible with (or agnostic of) the principle of strict aggregation. If the customer has legitimate reason for sending alien traffic (i.e. the space has been allocated to the customer by another ISP), I see no reason why the ISP can't choose to allow it. In fact, if an ISP has to advertise an address block just to be allowed source traffic from it, that is a big incentive to clutter the routing table. > FYI: I just added the following text as a proposed requirement > For IPv6 multihoming solutions. > > "IPv6 multihoming solutions MUST be compatible with sites that > implement RPF checks or filtering that prevents traffic to be sent > back from a different interface it came in." We get asymmetric traffic all the time in the default free zone, since we're all allowed to choose localprefs independently of each other. It's no big deal. Where a site chooses to allow a customer route traffic asymmetrically, and otherwise implements RFC2827, I don't understand the harm in allowing a multihoming solution based on this. My instinct says that we'd lose a whole swathe of potential solutions for arguably little benefit. Dave From michel@arneill-py.sacramento.ca.us Thu Jan 31 04:35:03 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Wed, 30 Jan 2002 20:35:03 -0800 Subject: (6bone) Ingress filtering (was: asymmetric routing) Message-ID: <2B81403386729140A3A899A8B39B046406C2AD@server2000.arneill-py.sacramento.ca.us> Dave, > Dave Wilson wrote: > I think the harm caused by sloppy aggregation of address space > is clear. > I think the harm caused by inadequate filtering of source > addresses is also clear. Concur. > These are separate considerations, however. Forwarding traffic > with a source address that is not your own, for good or ill, > doesn't harm the routing table in the same way that unaggregated > advertisements do, and so it seems to me it's entirely compatible > with (or agnostic of) the principle of strict aggregation. Concur also. > In fact, if an ISP has to advertise an address block just to > be allowed source traffic from it, that is a big incentive to > clutter the routing table. Concur again. > If the customer has legitimate reason for sending alien traffic > (i.e. the space has been allocated to the customer by another > ISP), I see no reason why the ISP can't choose to allow it. Can we enumerate the legitimate reasons for sending (accepting I think would be more appropriate) alien IPv6 PA traffic? In my mind, there are not any, and multihoming is NOT a legitimate reason. It's not like it is a bad idea, but requirering ISPs to transport the traffic of their competitors is not going to fly, no way. Imagine the following scenario: You are a multihomed content provider. You have two ISPs, X and Y. You have two PA prefixes, PX and PY. A dial-up customer queries your server using its PX address. The return traffic (src=PX, dest=cust) could, indeed, go out through ISP Y. What is wrong with that: ISP Y is going to scream that it transports ISP X' (its direct competitor) traffic for free. The return traffic, from the multihomed content provider to Joe customer, is the bulk of the bandwidth as of today. This is more about ingress filtering than about assymetric traffic. I am not saying that assymetric traffic is bad (I am sure that many of us could live without it, though). I think that a by-product of the strong aggregation of IPv6 prefixes will be a lot more symmetric traffic patterns. The point I am trying to make is: unless you can give me a legitimate reason why ISP Y should accept ISP X' PA prefix PX as the source, there is no reason NOT to have access-lists that deny customer's traffic that has a source address that not belong to the ISP's PA address space and is not a PI address. There are no IPv6 PI addresses as of today. Please prove me wrong. > We get asymmetric traffic all the time in the default free zone, > since we're all allowed to choose localprefs independently of > each other. It's no big deal. Assymetric for PI addresses, yes. Alien AP trafic coming from one of your own customers, another kind of animal. > Where a site chooses to allow a customer route traffic > asymmetrically, and otherwise implements RFC2827, I don't > understand the harm in allowing a multihoming solution based on > this. My instinct says that we'd lose a whole swathe of > potential solutions for arguably little benefit. The main harm is to the perceived revenue loss transporting other provider's traffic for free. A little bird has told me that most ISPs perceive it very strongly. Michel. From pekkas@netcore.fi Thu Jan 31 07:38:05 2002 From: pekkas@netcore.fi (Pekka Savola) Date: Thu, 31 Jan 2002 09:38:05 +0200 (EET) Subject: asymmetric routing In-Reply-To: <3C581841.9030104@heanet.ie> Message-ID: On Wed, 30 Jan 2002, Dave Wilson wrote: > These are separate considerations, however. Forwarding traffic with a > source address that is not your own, for good or ill, doesn't harm the > routing table in the same way that unaggregated advertisements do, and > so it seems to me it's entirely compatible with (or agnostic of) the > principle of strict aggregation. Yes, but forwarding when not advertising can lead to unexpected results; e.g. _any_ router discarding the packets due to failing ingress filtering checks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From dave.wilson@heanet.ie Thu Jan 31 10:05:36 2002 From: dave.wilson@heanet.ie (Dave Wilson) Date: Thu, 31 Jan 2002 10:05:36 +0000 Subject: (6bone) Ingress filtering (was: asymmetric routing) References: <2B81403386729140A3A899A8B39B046406C2AD@server2000.arneill-py.sacramento.ca.us> Message-ID: <3C5916F0.7010903@heanet.ie> > The point I am trying to make is: unless you can give me a > legitimate reason why ISP Y should accept ISP X' PA prefix PX as > the source, there is no reason NOT to have access-lists that deny > customer's traffic that has a source address that not belong to the > ISP's PA address space and is not a PI address. There are no IPv6 > PI addresses as of today. Please prove me wrong. I agree with the above, and most of your post. One question, is it necessary to enumerate these reasons now, or is it sufficient to say that: (1) There are some ISPs who do not care about asymmetric traffic (2) There are some ISPs who may negotiate with the customer to allow it, as a service? I do not propose that we require ISPs to carry asymmetric traffic. Is it still worthwhile to develop multihoming solutions that are available to those that do? Dave From Jan Oravec Thu Jan 31 10:09:31 2002 From: Jan Oravec (Jan Oravec) Date: Thu, 31 Jan 2002 11:09:31 +0100 Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <2B81403386729140A3A899A8B39B046406C2AD@server2000.arneill-py.sacramento.ca.us>; from michel@arneill-py.sacramento.ca.us on Wed, Jan 30, 2002 at 08:35:03PM -0800 References: <2B81403386729140A3A899A8B39B046406C2AD@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020131110931.A62999@ipv6.isternet.sk> Michel, > > If the customer has legitimate reason for sending alien traffic > > (i.e. the space has been allocated to the customer by another > > ISP), I see no reason why the ISP can't choose to allow it. > > Can we enumerate the legitimate reasons for sending (accepting I > think would be more appropriate) alien IPv6 PA traffic? In my mind, > there are not any, and multihoming is NOT a legitimate reason. It's > not like it is a bad idea, but requirering ISPs to transport the > traffic of their competitors is not going to fly, no way. The name 'traffic of their competitors' is confusing. Traffic was originated by customer of ISP, not by ISP's competitor. The customer pays for transit, so I don't see a reason for filtering. > > Where a site chooses to allow a customer route traffic > > asymmetrically, and otherwise implements RFC2827, I don't > > understand the harm in allowing a multihoming solution based on > > this. My instinct says that we'd lose a whole swathe of > > potential solutions for arguably little benefit. I agree.. > > The main harm is to the perceived revenue loss transporting other > provider's traffic for free. A little bird has told me that most > ISPs perceive it very strongly. Again, it's not 'other provider's traffic', it's 'customer's traffic'. The example: you have two post offices - A and B. I want to send letter to someone. The post office A has better prices for this destination, but I want to get response to my p.o.box at office B. So I write return-address to 'B' on letter. I pay some money to A for sending the letter. (and I pay some money to B for my p.o.box) Yes, they cannot check whether my 'B' address is regular or not. The question is: Shall they reject delivery ? Regards, -- Jan Oravec project coordinator XS26 - 'Access to IPv6' jan.oravec@xs26.net From villearc@stealth.net Thu Jan 31 11:17:08 2002 From: villearc@stealth.net (Ville) Date: Thu, 31 Jan 2002 06:17:08 -0500 (EST) Subject: (6bone) Ingress filtering (was: asymmetric routing) In-Reply-To: <2B81403386729140A3A899A8B39B046406C2AD@server2000.arneill-py.sacramento.ca.us> Message-ID: Michel, > > (quote/Dave Wilson) > > If the customer has legitimate reason for sending alien traffic > > (i.e. the space has been allocated to the customer by another > > ISP), I see no reason why the ISP can't choose to allow it. > (clip) (quote/Michel Py) > there are not any, and multihoming is NOT a legitimate reason. It's > not like it is a bad idea, but requirering ISPs to transport the > traffic of their competitors is not going to fly, no way. Mind you, this actually happens. Even at current many NSPs free-willingly carry alien-traffic. Yet one does not see people run aloof on the streets and scream in panic() with all their valuables on fire. Sure, clearly not a solution for the QoS-sighted, but still indeniably a rather high-ranking option for people interested in sheer high volumes of bulk-traffic. What are we to pick for people what they want. If neither discouraged nor eliminated by protocol-design, the provider itself is left with all choices as to what to and what not to offer for his/her own clients. > Michel. Cheers, -- Ville Network Security/IPv6 Solutions Stealth Communications, Inc. From alfonso.buono@napoli.consorzio-cini.it Thu Jan 31 16:15:16 2002 From: alfonso.buono@napoli.consorzio-cini.it (Alfonso Buono) Date: Thu, 31 Jan 2002 17:15:16 +0100 Subject: remove Message-ID: <09a401c1aa72$78a7c8a0$834009d9@napoli.consorziocini.it> Messaggio in formato MIME composto da piů parti. ------=_NextPart_000_09A1_01C1AA7A.DA2D79F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable remove ------=_NextPart_000_09A1_01C1AA7A.DA2D79F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
remove
------=_NextPart_000_09A1_01C1AA7A.DA2D79F0-- From gcampos@campus.cem.itesm.mx Thu Jan 31 18:09:25 2002 From: gcampos@campus.cem.itesm.mx (M. en C. Gabriela A. Campos G.) Date: Thu, 31 Jan 2002 12:09:25 -0600 Subject: remove Message-ID: <3C598855.4109BC5C@campus.cem.itesm.mx> This is a multi-part message in MIME format. --------------1F607E93B1591E8C4E2B0C95 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit remove --------------1F607E93B1591E8C4E2B0C95 Content-Type: text/x-vcard; charset=us-ascii; name="gcampos.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for M. en C. Gabriela A. Campos G. Content-Disposition: attachment; filename="gcampos.vcf" begin:vcard n:; x-mozilla-html:FALSE url:http://research.cem.itesm.mx/gcampos/index.htm org:ITESM-CEM;Sistemas de Información version:2.1 email;internet:gcampos@campus.cem.itesm.mx adr;quoted-printable:;;Carr. Lago de Guadalupe Km 3.5,=0D=0ACol. Margarita Maza de Ju=E1rez,=0D=0AAtizap=E1n de Zaragoza, Edo. de M=E9xico=0D=0A;;;CP. 52926; fn:M. en C. Gabriela A. Campos G. end:vcard --------------1F607E93B1591E8C4E2B0C95-- From Kevin R. Johnsrud" Message-ID: <002601c1aa90$39db2400$8500a8c0@Dastun> remove From george+6bone@m5p.com Thu Jan 31 21:04:47 2002 From: george+6bone@m5p.com (george+6bone@m5p.com) Date: Thu, 31 Jan 2002 13:04:47 -0800 (PST) Subject: How to remove yourself from the list Message-ID: <200201312104.g0VL4lcf062297@m5p.com> It's not clear why so many people are trying to leave the mailing list, but let me post this reminder, which you all got when you first subscribed to the list: If you ever want to remove yourself from this mailing list, send the following command in email to "6bone-request@zephyr.isi.edu": unsubscribe Or you can send mail to "majordomo@zephyr.isi.edu" with the following command in the body of your email message: unsubscribe 6bone -- George Mitchell From deana.grein@safeway.com Thu Jan 31 22:11:30 2002 From: deana.grein@safeway.com (Deana Grein) Date: Thu, 31 Jan 2002 14:11:30 -0800 Subject: remove References: <3C598855.4109BC5C@campus.cem.itesm.mx> <002601c1aa90$39db2400$8500a8c0@Dastun> Message-ID: <3C59C112.A9F1F000@safeway.com> > remove "WorldSecure Server " made the following annotations on 01/31/02 15:11:15 ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the Safeway corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain information proprietary to Safeway and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ============================================================================== From sudhirv@utdallas.edu Thu Jan 31 22:36:09 2002 From: sudhirv@utdallas.edu (Sudhir Vaka) Date: Thu, 31 Jan 2002 16:36:09 -0600 (CST) Subject: remove Message-ID: remove Sudhir K Vaka From marc@bleuler.net Thu Jan 31 22:42:43 2002 From: marc@bleuler.net (Marc Bleuler) Date: Thu, 31 Jan 2002 23:42:43 +0100 Subject: remove Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C1AAB0.FA2E2A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit remove ------=_NextPart_000_0006_01C1AAB0.FA2E2A20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IisWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAfABcAKgAAAAQAPgEB A5AGAKgDAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAABwAAAHJlbW92ZQAAAgFxAAEAAAAWAAAAAcGqqJd+wd56ea18QsGJ2VZoPGtx4AAAAgEdDAEA AAAWAAAAU01UUDpNQVJDQEJMRVVMRVIuTkVUAAAACwABDgAAAABAAAYOAGyzfqiqwQECAQoOAQAA ABgAAAAAAAAALAOUEWHV1BGhhQBQi46jNMKAAAALAB8OAQAAAAIBCRABAAAAbQAAAGkAAACaAAAA TFpGdef8SEUDAAoAcmNwZzEyNSYyAPgLYG5nAdA1NU8B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqB knYIkHdrC4BkNAxgbmMAUAsDC7UgCXAEYHZ+ZQqiCoQKhAsxFL0R4QABFpAAAAALAAGACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAMAEIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEAHgAS gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAFoAIIAYAAAAAAMAAAAAAAABG AAAAAIKFAAABAAAACwBDgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAEWACCAGAAAAAADA AAAAAAAARgAAAAAQhQAAAAAAAAMARoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwBHgAgg BgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAADAFuACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAA AAsAbIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAgH4DwEAAAAQAAAALAOUEWHV1BGhhQBQ i46jNAIB+g8BAAAAEAAAACwDlBFh1dQRoYUAUIuOozQCAfsPAQAAAFcAAAAAAAAAOKG7EAXlEBqh uwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABEOlxTeXN0ZW1cT3V0 bG9va1xvdXRsb29rLnBzdAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMAAAADxORUJCS0JJRkNN RkRCUEpQTUNPQkdFUEFDQ0FBLm1hcmNAYmxldWxlci5uZXQ+AAMABhAVe7opAwAHEAYAAAADABAQ AAAAAAMAERAAAAAAHgAIEAEAAAAHAAAAUkVNT1ZFAAAfnw== ------=_NextPart_000_0006_01C1AAB0.FA2E2A20-- From rain@bluecherry.net Thu Jan 31 23:05:57 2002 From: rain@bluecherry.net (Ben Winslow) Date: 31 Jan 2002 17:05:57 -0600 Subject: remove In-Reply-To: <002601c1aa90$39db2400$8500a8c0@Dastun> References: <3C598855.4109BC5C@campus.cem.itesm.mx> <002601c1aa90$39db2400$8500a8c0@Dastun> Message-ID: <1012518358.11439.7.camel@halcyon> --=-+aOeH0oedbccSogqrqSy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-01-31 at 13:48, Kevin R. Johnsrud wrote: > remove iguana (try sending 'unsubscribe 6bone' to majordomo@isi.edu) --=20 Ben Winslow (rain@bluecherry.net) : Andrea: Unhappy is the land that=20 System Administrator : has no heroes. Galileo: No; Bluecherry Internet Services : unhappy is the land that needs http://www.bluecherry.net/ : heroes. =20 (573) 592-0800 :=20 --=-+aOeH0oedbccSogqrqSy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Wc3U2/SfDQAyrVERAlMtAKC2KRGAFdbbj8Nd6rZNl+rU8ixD9wCZAWdi xdguZevOayFwBtz8NWHSS0Y= =5FLh -----END PGP SIGNATURE----- --=-+aOeH0oedbccSogqrqSy-- From michel@arneill-py.sacramento.ca.us Thu Jan 31 23:56:26 2002 From: michel@arneill-py.sacramento.ca.us (Michel Py) Date: Thu, 31 Jan 2002 15:56:26 -0800 Subject: (6bone) Ingress filtering (was: asymmetric routing) Message-ID: <2B81403386729140A3A899A8B39B046405DE83@server2000.arneill-py.sacramento.ca.us> folks, > Dave Wilson wrote: > (2) There are some ISPs who may negotiate with the customer to > allow it, as a service? > I do not propose that we require ISPs to carry asymmetric traffic. > Is it still worthwhile to develop multihoming solutions that are > available to those that do? This is a dangerous and slippery slope, because the next step would be to break aggregation to get routes to the DMZ. >> Dave Wilson wrote: >> These are separate considerations, however. Forwarding traffic >> with a source address that is not your own, for good or ill, >> doesn't harm the routing table in the same way that unaggregated >> advertisements do, and so it seems to me it's entirely compatible >> with (or agnostic of) the principle of strict aggregation. > Pekka Savola wrote: > Yes, but forwarding when not advertising can lead to unexpected > results; e.g. _any_ router discarding the packets due to failing > ingress filtering checks. Concur. > Jan Oravec wrote: > Again, it's not 'other provider's traffic', it's 'customer's traffic'. > The example: you have two post offices - A and B. > I want to send letter to someone. The post office A has better prices > for this destination, but I want to get response to my p.o.box at > office B. So I write return-address to 'B' on letter. I pay some money > to A for sending the letter. (and I pay some money to B for my p.o. > box) Yes, they cannot check whether my 'B' address is regular or not. > The question is: Shall they reject delivery ? No, and it works for two reasons: 1. A and B have agreements. 2. B is getting paid twice, once by you and once by the buddy that replies to you that buys a stamp. You are making the same point as Dave, above. You could, indeed, cut a deal with both ISPs requesting that they both allow each other traffic trough. Again, this is a slippery slope. Then the two ISPs are going to exchange routes, then they are going to advertise each other's routes and break aggregation, and then we are in the same mess. > Ville wrote: > what are we to pick for people what they want. If neither > discouraged nor eliminated by protocol-design, the provider > itself is left with all choices as to what to and what not to > offer for his/her own clients. I am a protocol designer. One of the reasons I read and post to the 6bone mailing list is to get a feeling of how features or requirements will be perceived by the 6bone community, so I can decide to incorporate or not these features/requirements in my protocol. Michel. From george+6bone@m5p.com Thu Jan 31 21:04:47 2002 From: george+6bone@m5p.com (george+6bone@m5p.com) Date: Thu, 31 Jan 2002 13:04:47 -0800 (PST) Subject: How to remove yourself from the list Message-ID: <200201312104.g0VL4lcf062297@m5p.com> It's not clear why so many people are trying to leave the mailing list, but let me post this reminder, which you all got when you first subscribed to the list: If you ever want to remove yourself from this mailing list, send the following command in email to "6bone-request@zephyr.isi.edu": unsubscribe Or you can send mail to "majordomo@zephyr.isi.edu" with the following command in the body of your email message: unsubscribe 6bone -- George Mitchell From Kevin R. Johnsrud" Message-ID: <002601c1aa90$39db2400$8500a8c0@Dastun> remove From sudhirv@utdallas.edu Thu Jan 31 22:36:09 2002 From: sudhirv@utdallas.edu (Sudhir Vaka) Date: Thu, 31 Jan 2002 16:36:09 -0600 (CST) Subject: remove Message-ID: remove Sudhir K Vaka From marc@bleuler.net Thu Jan 31 22:42:43 2002 From: marc@bleuler.net (Marc Bleuler) Date: Thu, 31 Jan 2002 23:42:43 +0100 Subject: remove Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C1AAB0.FA2E2A20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit remove ------=_NextPart_000_0006_01C1AAB0.FA2E2A20 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IisWAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAQAfABcAKgAAAAQAPgEB A5AGAKgDAAAiAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAABwAAAHJlbW92ZQAAAgFxAAEAAAAWAAAAAcGqqJd+wd56ea18QsGJ2VZoPGtx4AAAAgEdDAEA AAAWAAAAU01UUDpNQVJDQEJMRVVMRVIuTkVUAAAACwABDgAAAABAAAYOAGyzfqiqwQECAQoOAQAA ABgAAAAAAAAALAOUEWHV1BGhhQBQi46jNMKAAAALAB8OAQAAAAIBCRABAAAAbQAAAGkAAACaAAAA TFpGdef8SEUDAAoAcmNwZzEyNSYyAPgLYG5nAdA1NU8B9wKkA+MCAGNoCsBzsGV0MCAHEwKAfQqB knYIkHdrC4BkNAxgbmMAUAsDC7UgCXAEYHZ+ZQqiCoQKhAsxFL0R4QABFpAAAAALAAGACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAMAEIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEAHgAS gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsAFoAIIAYAAAAAAMAAAAAAAABG AAAAAIKFAAABAAAACwBDgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAEWACCAGAAAAAADA AAAAAAAARgAAAAAQhQAAAAAAAAMARoAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwBHgAgg BgAAAAAAwAAAAAAAAEYAAAAAGIUAAAAAAAADAFuACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAA AAsAbIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAgH4DwEAAAAQAAAALAOUEWHV1BGhhQBQ i46jNAIB+g8BAAAAEAAAACwDlBFh1dQRoYUAUIuOozQCAfsPAQAAAFcAAAAAAAAAOKG7EAXlEBqh uwgAKypWwgAAUFNUUFJYLkRMTAAAAAAAAAAATklUQfm/uAEAqgA32W4AAABEOlxTeXN0ZW1cT3V0 bG9va1xvdXRsb29rLnBzdAAAAwD+DwUAAAADAA00/TcAAAIBfwABAAAAMAAAADxORUJCS0JJRkNN RkRCUEpQTUNPQkdFUEFDQ0FBLm1hcmNAYmxldWxlci5uZXQ+AAMABhAVe7opAwAHEAYAAAADABAQ AAAAAAMAERAAAAAAHgAIEAEAAAAHAAAAUkVNT1ZFAAAfnw== ------=_NextPart_000_0006_01C1AAB0.FA2E2A20-- From rain@bluecherry.net Thu Jan 31 23:05:57 2002 From: rain@bluecherry.net (Ben Winslow) Date: 31 Jan 2002 17:05:57 -0600 Subject: remove In-Reply-To: <002601c1aa90$39db2400$8500a8c0@Dastun> References: <3C598855.4109BC5C@campus.cem.itesm.mx> <002601c1aa90$39db2400$8500a8c0@Dastun> Message-ID: <1012518358.11439.7.camel@halcyon> --=-+aOeH0oedbccSogqrqSy Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Thu, 2002-01-31 at 13:48, Kevin R. Johnsrud wrote: > remove iguana (try sending 'unsubscribe 6bone' to majordomo@isi.edu) --=20 Ben Winslow (rain@bluecherry.net) : Andrea: Unhappy is the land that=20 System Administrator : has no heroes. Galileo: No; Bluecherry Internet Services : unhappy is the land that needs http://www.bluecherry.net/ : heroes. =20 (573) 592-0800 :=20 --=-+aOeH0oedbccSogqrqSy Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8Wc3U2/SfDQAyrVERAlMtAKC2KRGAFdbbj8Nd6rZNl+rU8ixD9wCZAWdi xdguZevOayFwBtz8NWHSS0Y= =5FLh -----END PGP SIGNATURE----- --=-+aOeH0oedbccSogqrqSy-- From deana.grein@safeway.com Thu Jan 31 22:11:30 2002 From: deana.grein@safeway.com (Deana Grein) Date: Thu, 31 Jan 2002 14:11:30 -0800 Subject: remove References: <3C598855.4109BC5C@campus.cem.itesm.mx> <002601c1aa90$39db2400$8500a8c0@Dastun> Message-ID: <3C59C112.A9F1F000@safeway.com> > remove "WorldSecure Server " made the following annotations on 01/31/02 15:11:15 ------------------------------------------------------------------------------ Warning: All e-mail sent to this address will be received by the Safeway corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain information proprietary to Safeway and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. ============================================================================== From fmei@njnet.edu.cn Sat Jan 19 02:40:51 2002 From: fmei@njnet.edu.cn (=?ISO-8859-1?Q?=C3=B7=B7=C9?=) Date: Sat, 19 Jan 2002 10:40:51 +0800 Subject: about IPv6 multicasting Message-ID: <200202190244.KAA09567@njnet.edu.cn> 6boneŁ¬ÄúşĂŁˇ need get some infromation about the new development of IPv6 multicasting. Ö ŔńŁˇ Ă··É fmei@njnet.edu.cn