[no subject]
Hi all, I have a doubt regarding ipv6 over ipv4 tunnel. 1. When a tunnel is configured, source and destination is configured. Is it sufficient to configure destination address only. My means to say why source address is required. 2. Is it necessary to establish path between source and destination before configuring tunnel and use this path in routing header of tunneled packet for forwarding the packet. 3. I have one more doubt, when there is concept of fast path and slow path, which functionality of the tunnelling should go to the fast path and which functionality of tunnelling should go to the slow path. thanks in advance regards ari. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Retail IPv6 Service in the US?
v6 anycast is distinctly different than v4 anycast, which is confusing to most operators I know of. wrt native IPv6 providers in the US, yes there are a few. todate, they are either small or are "vertical". Perhaps the largest in the US (BW, geographic spread) is the Abilene network. There are a number of ISPs that connect natively to exchange facilities over IPv6. In LA, I am using an ISP with native IPv6 to connect to LAIIX where there is native IPv6 to two other ISPs and a bunch of tunnels to other regional ISPs that connect to other exchanges. Most exchanges will be IPv6 aware/capable in the next 30 days. The backbone/transit networks that had plans (CW, Sprint, WCOM) for native IPv6 products have generally slipped those plans (for a variety of reasons) out for another year or so... based on demand. And quite frankly, these folks need -big- customer demand. So the near-term, pragmatic tactic seems to be for us small users to vote w/ our pocketbooks and support the regional/local ISPs that support IPv6 to local exchanges. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
I-D ACTION:draft-ietf-dnsext-ipv6-name-auto-reg-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Version 6 Working Group Working Group of the IETF. Title : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename: draft-ietf-dnsext-ipv6-name-auto-reg-00.txt Pages : 21 Date: 2002-12-11 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. Since IPv6 addresses are too long to remember and EUI64-based addresses are too complicated to remember, there are strong requirements to use logical names that are easy to remember instead of IPv6 addresses to specify IPv6 nodes and to register domain name information of plugged-in IPv6 nodes automatically. In order to meet the requirements, a mechanism is proposed as one of the IPv6 auto-configuration (plug and play) functions. After the Address Autoconfiguration [ADDR-AUTO] has been executed, it works as a succeeding plug and play mechanism. This document clarifies problems that we meet when we apply the Dynamic Updates in the DNS [DYN-DNS] to automatic domain name information registration mechanisms. This document describes the Domain Name Auto-Registration mechanism as a solution to these problems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-ipv6-name-auto-reg-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: "FILE /internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
Re: Retail IPv6 Service in the US?
% What we need is netgear and linksys to get on board and some of us in % deployment land are bugging folks like that now. Jim, what is the issue here? I have both linksys and netgear kit in the home network and both pass native IPv6. granted not all their kit works w/ IPv6. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Retail IPv6 Service in the US?
Bill, WOW. OK lets go offline. I got both here too and just "assumed" not and I looked for patches. Thanks. /jim [What light is to the eyes, what air is to the lungs, what love is to the heart, liberty is to the soul] > -Original Message- > From: Bill Manning [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 12, 2002 6:50 AM > To: Bound, Jim > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Retail IPv6 Service in the US? > > > % What we need is netgear and linksys to get on board and > some of us in % deployment land are bugging folks like that now. > > Jim, > what is the issue here? I have both linksys and netgear > kit in the home network and both pass native IPv6. granted > not all their kit works w/ IPv6. > > --bill > > Opinions expressed may not even be mine by the time you read > them, and certainly don't reflect those of any other entity > (legal or otherwise). > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Retail IPv6 Service in the US?
Bill, demand. So the near-term, pragmatic tactic seems to be for us small users to vote w/ our pocketbooks and support the regional/local ISPs that support IPv6 to local exchanges. I think the expression is "think globally, act locally". Don't wait for someone else to do it. Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-hinden-ipv6-global-site-local-00.txt
Mark, At 05:54 PM 12/9/2002, Mark Smith wrote: Hi Bob, A few thoughts / questions / comments on your draft : 3.0 Proposal & 3.1 Global Token * 8 bit areas I'm curious as to why you chose to allocate 8 bits for the area. Allocating 6 bits for area would allow aggregation to take place on the /16 bit boundary. I think this would make it a easier for network admins to manage their site-local area prefixes when bounded at /16. I was going to suggest putting back the u and g bits, which would make connecting to the origin router for this prefix easier (just telnet to fec0 + EUI-64 + EUI-64), but then realised that your site local global token is generated from an EUI-48 :-( I think there probably is some value in keeping the full EUI-48 as the global token for trouble shooting reasons, at the sacrifice of 2 area bits. I was trying to see how many bits I could have left over and still use the EUI-48 as the basis for the global token. I think I agree that it would be simpler just using the whole 48-bits and shrink the area. 3.2 Assignment * maybe be a bit more explicit about how manual configuration is achieved. I agree with and understand the motivation for manual assignment of these prefixes. However, the whole proposal has a strong "auto-configuration" theme - deriving site-local addresses from EUI-48s sounds a lot like something that would be done automatically by default. I agree. I think one of the good things about this approach is that could be made to auto-configure the subnets. I wasn't attempting to solve all of the issues to make that work in this draft. Would a typical implementation of this manual assignment be a toggle switch / [on / off] configuration option within a router ? If so, additional text suggesting that these prefixes will be automatically generated, but manually enabled / disabled (defaulted to disabled) might help overcome the "auto-configuration" theme of the generation of these prefixes. I agree adding some text to clarify how this could work would make it clearer. Semi-automatic might be a good way to describe it. The administrator could be give a choice of creating a prefix based in the interfaces EUI-48 address, enter a global token, or use a prefix it has heard advertised from another router. This would make the installation of the routers fairly simple and in most cases avoid typing in big strings of digits. * the term "area" might be a bit vague, in the sense that usually people talk about "areas", they are referring to OSPF areas. I found when I initially read this term, I immediately wondered whether this field has some use or value wrt OSPF. The use of area was not coincidental. I was thinking about OSPF areas as that is probably about the right size to flat route a number of subnets. A different name for this field might be a bit less confusing. - I don't feel that strongly on this, I think it is just that "area" is in such common usage in the OSPF context (and to my knowledge, no where is in IP routing / addressing), most people would immediately associate any usage of the term "area" in an RFC with OSPF. Another question is the area field that useful or would it be better to just have /64 prefixes and flat route them in a site. This might make the proposal simpler and better. On the other hand, it is nice to have a way of scaling the routing protocol inside the site. Thoughts? Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-hinden-ipv6-global-site-local-00.txt
Keith, Brian, At 02:06 AM 12/11/2002, Brian E Carpenter wrote: For the record, I am still completely against any proposal that takes over the normal 16 bit subnet field, i.e. generates a prefix longer than /48. It just isn't operationally convenient. At 04:12 PM 12/11/2002, Keith Moore wrote: > I'm still unsure about this insistence on /48 as a critical point of > allocation. renumbering is a lot more painful if you're trying to renumber between prefixes of different lengths. Ignoring the area field (that I am starting to think was a mistake) for a minute, the idea in the draft is that one could have site-local prefixes that are independent from the global prefixes and would not have to be renumbered. Because they are globally unique they would survive site joining and/or splitting, change of ISP, change of topology, etc. There were not intended to be used in the same manner as the global prefixes that have a 16-bit subnet field. The cost for this flexibility was that they had to be flat routed in the site. I think that is a good tradeoff, but opinions will vary. Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Internet draft on EUIs and site locals
At the same time as Bob was writing draft-hinden-ipv6-global-site-local-00.txt Aidan and I were also working on a draft to summarise our ideas. This is now available as draft-white-auto-subnet-00.txt Having seen both side by side, Bob's is probably the cleaner, although we offer a different perspective and commentary on some points. The main difference is moving some of the free bits from the 'area' field (high bits above the EUI) to a sub-id field below the EUI, to allow a router to use a single EUI-48 to service multiple interfaces or links. -- Andrew White[EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Enforcing unreachability of site local addresses
Margaret, In my opinion, the only way that we will stop people from using NAT (with or without IPv6 site-local addresses) will be to provider better (architecturally cleaner, more convenient, more functional) mechanisms for people to get the same benefits that they get from NATs today. Although NATs may have started as a response to address space shortage, today their use is driven by the needs for provider-independent addressing and convenient access control. So, we need to work on better ways to provide those things in IPv6. I am not sure that this is really true. When I was looking for a new DSL provider I found that in many cases I could get service at a specific bandwidth with a singe address for about $60 a month. If I wanted a /29 instead, it would cost about $30 more a month. 50% more for 6 usable addresses! I think this is fairly common. The lower cost DSL providers doen't even give the user to choice to get more addresses. People are still being forced to run NAT in response to address scarcity. We could only tell for sure if people would still run NAT for other reasons if addresses were readily available. I ended up finding a different ISP who charged more money, but gave me more bandwidth and the addresses I wanted. Most people would not be willing to do that and would be forced to run NAT. Bob IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: Enforcing unreachability of site local addresses
Margaret, Bob, > > >In my opinion, the only way that we will stop people from using NAT > >(with or without IPv6 site-local addresses) will be to provider better > >(architecturally cleaner, more convenient, more functional) mechanisms > >for people to get the same benefits that they get from NATs today. > >Although NATs may have started as a response to address space shortage, > >today their use is driven by the needs for provider-independent addressing > >and convenient access control. So, we need to work on better ways to > >provide those things in IPv6. > > I am not sure that this is really true. When I was looking for a new DSL > provider I found that in many cases I could get service at a specific > bandwidth with a singe address for about $60 a month. If I wanted a /29 > instead, it would cost about $30 more a month. 50% more for 6 usable > addresses! I think this is fairly common. The lower cost DSL providers > doen't even give the user to choice to get more addresses. People are > still being forced to run NAT in response to address scarcity. We could > only tell for sure if people would still run NAT for other reasons if > addresses were readily available. > > I ended up finding a different ISP who charged more money, but gave me more > bandwidth and the addresses I wanted. Most people would not be willing to > do that and would be forced to run NAT. > I believe that Bob has it right here. Enterprises may well use NAT for provider independence and easier multi-homing, but in the home and small business area NAT is driven by address scarcity. That address scarcity is artificial in many cases. ISPs can charge for address space so they do. No one is going to give up NAT unless they can get all the address space they want and only be charged for bandwidth. That will require some business model surgery on consumer ISPs. As I have said multiple times during this long debate, we need to work on solutions in both these spaces. To fix the "ISP can charge for address space so they do" part we need to have a renumbering solution that doesn't require home and small business users to break internal communication in order to renumber.We kind of had that with the router renumbering specification but that appears doomed at this point. Without that lever in the hands of consumers, ISPs will simply continue to charge for "extra" addresses and NAT will follow. Even with it NAT might follow but without it NAT is a near certainty. If these renumbering solutions scale to the enterprise, all the better but the enterprise also has to deal with multi- homing. Tim Hartrick Mentat Inc. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: "unique enough" [RE: globally unique site local addresses]
Keith, I think your points on both topics are well taken. I also have the notion that the current approach of combining the locator and identifier in IPv4 and IPv6 has a lot of value that we tend to take for granted. It provides a degree of authentication that requires lots of cryptographic technology to replicate if they are separated. Instead of a bug, I think it is a feature :-) Bob a true separation of locator and identifier is a more fundamental change to the Internet architecture than moving from IPv4 to IPv6. as soon as you separate locator and identifier, you have the burden of providing a mapping service between the two, which is efficient, reliable, secure, and precise enough to be used for all applications. DNS (which is typically proposed as the solution) doesn't even come close. OTOH, mobileIP is a fairly close approximation to separating locator and identifier if you get past the notion that "home agent" is specific to a single host (as opposed to a set of hosts with a common prefix), and that "home" has anything to do with the normal physical location of a host. being able to get rid of the home agent when the host has a home and is at home is a useful optimization that works in some cases, but not in all or most cases. IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-hinden-ipv6-global-site-local-00.txt
Keith Moore wrote: > > > I'm still unsure about this insistence on /48 as a critical point of > > allocation. > > renumbering is a lot more painful if you're trying to renumber > between prefixes of different lengths. Exactly. And we agreed a long time ago on /48 as the normal (but not architecturally required) prefix length for every site, except for degenerate /64 sites with no subnetting. Brian IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
