Ipv6 Subnet
We usually specify Ipv4 subnet like 255.255.255.0 or /8 so . But in Ipv6 while mentioning address we specify it /64 or /48 . Does both representation have same meaning ? More specifically i will like to know whether the Ipv6 subnetting is similar to ipv4 or differs ? Any RFC or document pertaining to this ?? Digambar Rasal ControlNet India Pvt Ltd India. +918322883601 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: Ipv6 Subnet
Hi Digambar, At 04:53 PM 12/11/2002 +0530, Digambar Rasal wrote: We usually specify Ipv4 subnet like 255.255.255.0 or /8 so . But in Ipv6 while mentioning address we specify it /64 or /48 . As you may already know, a subnet mask of 255.255.255.0 is actually a /24. This means that the first 24 bits of the address contain the routing information (the network and subnet identifiers) and the last 8 bits contains the host identifier. In IPv6, addresses are 128 bits long. Writing out a subnet mask in the long form would look something like this: ::::0:0:0:0 That would be awfully cumbersome, so we don't use that notation, only the /NN notation. So, if the first 64 bits of an address contain the routing information (called a routing prefix in IPv6), we would say that it is a /64 prefix. Does both representation have same meaning ? More specifically i will like to know whether the Ipv6 subnetting is similar to ipv4 or differs ? Any RFC or document pertaining to this ?? IPv6 subnetting is basically identical to IPv4 subnetting. The addressing architecture document describes this in more detail. The latest version can be found at: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-11.txt Regards, Margaret 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: Ipv6 Subnet
Digambar Rasal wrote: We usually specify Ipv4 subnet like 255.255.255.0 or /8 so . But in Ipv6 while mentioning address we specify it /64 or /48 . You might lookup the word 'CIDR' or Classless Inter Domain Routing. In the /x, the x represents the number of bits for the part of the address that describes the network. Does both representation have same meaning ? More specifically i will like to know whether the Ipv6 subnetting is similar to ipv4 or differs ? No they 'work' the same. Classful (A, B, C, D, E) have been dropped for some time already and are replaced with their CIDR counterparts. Thus for this part of IPv4 vs IPv6, it's just a much longer address. Any RFC or document pertaining to this ?? www.faqs.org - CIDR Don't know the thing by number or name though ;) Most current books and documents should be using it as CIDR has been here since 1991 or something (or even earlier?). Greets, Jeroen 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
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. 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]
Retail IPv6 Service in the US?
I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? I did a quick Google search and all the offerings seem to be for backbone service. jak 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?
Hi James, At 10:21 AM 12/11/2002 -0800, James Kempf wrote: I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Great! Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? Unfortunately, I don't think that this is available (I'd love to find out that I'm wrong, though). Most of us run a 6to4 gateway and tunnel over our provider's IPv4 network to one of the public 6to4 relays. There are 6to4 implementations available for most OSes including most or all of the free Unixes. Good luck! And, let us know when you can see the turtle dance. :-) Margaret 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?
James, James Kempf wrote: I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? I am not aware of any at a reasonable price. I'm sure that you could find someone that would provide a T1 with IPv6 for $1,000/mo though For mere mortals that have to stick with the $49/mo DSL, use 6to4 or get a tunnel from http://www.freenet6.net/ Michel. 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?
James, At 10:21 AM 12/11/2002, James Kempf wrote: I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? I did a quick Google search and all the offerings seem to be for backbone service. I am unfortunately, also working on this. I used to have DSL service from a local provider, but they discontinued it abruptly a week and a half ago. Until they shut it down, I had IPv6 service with a configured tunnel to nokia.net with a /48 assignment. I found a new local SF bay area provider, meer.net, and signed up with them. They expressed some interest in later offering IPv6 service. [Note, I don't have any personal financial interest in meer.net so I am only mentioning them on the list because of their interest in IPv6.] Once the new DSL line is up, I will setup the configured tunnel again. I was planning on working with meer.net to help them get IPv6 running so I could get rid of the tunnel. If you contact them, suggest you mention your interest in IPv6. If enough people ask for 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: unique enough [RE: globally unique site local addresses]
Margaret, Margaret Wasserman wrote: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. Little disgression about the meaning of PI: in many people minds, it means PI as we know it today for IPv4, which is exactly what we don't want for IPv6. It would be better to use another acronym such as GRUPI or GAPI. - We think that the use of NAT is one of the serious architectural problems facing the Internet today, and that NAT is blocking the advancement of the Internet in many ways. For an IPv6 Internet to be a success, we must avoid the wide-scale deployment of IPv6 NAT. - We don't currently have a fully developed plan for aggregable, scalable IPv6 PI addressing. Some folks are working on this problem, but no one has claimed to have a full answer yet. - We know that providing widely-used PI addresses in IPv6 will result in substantially larger routing tables than doing straight PA addressing. - We also know that routing table size is a real scaling factor in the IPv4 Internet, for which we have not determined an adequate solution. - Routing table growth is not (yet) a scaling problem for IPv6, because of limited deployment. However, wide deployment of IPv6 is also a criteria for success, so we need to build a scalable solution... - However, success must also include the avoidance of wide-scale IPv6 NAT deployment, which we can only achieve if we provide PI addresses... [Ad infinitim.] Good summary, IMHO. So, where do we go from here? Two-prong approach, see http://arneill-py.sacramento.ca.us/ipv6mh/roadmap.txt Michel. 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]
Ronald, Margaret Wasserman wrote: - We need to provide PI addressing in IPv6, or we will see wide deployment of IPv6 NAT in enterprises and homes. No one seems to be disagreeing with this. Ronald van der Pol wrote: I don't know yet if I agree or not :-) I agree that it is a good idea to explore the topic of PI addressing. But if you look at the requirements, it might be better to take a more fundamental approach and look into the separatiion of locator and identifier. Right. People don't care much about PI addresses if they have PI identifiers instead. Michel. 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]
But if you look at the requirements, it might be better to take a more fundamental approach and look into the separatiion of locator and identifier. Right. People don't care much about PI addresses if they have PI identifiers instead. 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. Keith 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
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. I'm still unsure about this insistence on /48 as a critical point of allocation. /64 as a critical makes sense, as it is configured as the changeover from subnet allocation to host allocation (for unicast addresses at least). But as for /48, consider these examples: My home (say 4 subnets) is given a /48 for my SOHO network. The local university (say 100 subnets) is given a /48 for the campus. Multinational X (say 5000 subnets) is given a /48 for their entire VPN. Only one of the above needs anything like a /48. Next example, let's consider inside multinational X. I want to allocate subnets to sites. /48 is our standard allocation, right? But I can't allocate /48s, because /48 is the allocation for the entire VPN, so I instead allocate something smaller (probably a /56). Now let's assume that said site wants to create a site-local network (not sure why, since they're 'permanently' connected, but let's run with it). Why is the number /48 somehow magical for this site, considering they have a /56 delegation? All they really want is a way of generating internal /64 subnets. /64 marks a well defined physical entity: the subnet, although even that can be redefined if the address allocator wishes it. /48 is a convenient mark for a logical entity: the 'end-user' network. In practice, these vary radically in size and may be further subdivided, so /48 is merely a useful convention. -- 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: Retail IPv6 Service in the US?
Bob Hinden write: SNIP If you contact them, suggest you mention your interest in IPv6. If enough people ask for it Which is exactly what people should to get their ISP's going. We had an AMS-IX IPv6 Awareness Day, at which many ISP's where present. Checking http://www.sixxs.net/tools/grh/tla/ this helped quite a lot as the ISPs who attended the session. Most of them requested an sTLA from RIPE 1 United States 64 2 Japan 61 3 Germany31 4 Netherlands, The 24 5 United Kingdom 18 Not bad for such a small country as .nl... anyways what my point is is the fact that there should be IPv6 Awareness days/weeks where ISP's *AND* developers are given an insight into what they need to do to get the ball rolling. Maybe a good point for one of the next IPv6-WG meetings? How to make ISP's and developers aware of IPv6 Greets, Jeroen 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?
This is same situation as asian has except JP. IPv6 is wholly experimental and used in each lab. I'm looking forward to nice solution from V6OPS WG. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of James Kempf Sent: Thursday, December 12, 2002 3:21 AM To: [EMAIL PROTECTED] Subject: Retail IPv6 Service in the US? I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? I did a quick Google search and all the offerings seem to be for backbone service. jak IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: Retail IPv6 Service in the US?
This is same situation as asian has except JP. IPv6 is wholly experimental and used in each lab. I'm looking forward to nice solution from V6OPS WG. Daniel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of James Kempf Sent: Thursday, December 12, 2002 3:21 AM To: [EMAIL PROTECTED] Subject: Retail IPv6 Service in the US? I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? I did a quick Google search and all the offerings seem to be for backbone service. jak IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-hinden-ipv6-global-site-local-00.txt
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. 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?
Most of us run a 6to4 gateway and tunnel over our provider's IPv4 network to one of the public 6to4 relays. It's unfortunate that there still seem to be very few 6to4 relay routers that are advertising a route to the 6to4 anycast address (2002:c058:6301::). For example, for me (in the San Francisco Bay Area) this address gives me a router that appears to be located somewhere in Europe! Consequently, I ended up hard-coding a topologically closer 6to4 relay router (e.g., 6to4.ipv6.microsoft.com: 2002:836b:213c:1:e0:8f08:f020:8) into my configuration file. Are people still serious about using anycast to locate 6to4 relay routers, or is this idea considered to be just a toy?? Ross. 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?
James, I would contact NTT in San Jose and what is called the PAIX. Both have IPv6 offerings but I am not sure what the deal is at all. Now that ISP have commerical grade IPv6 products from many vendors this will change. The providers needed second release IPv6 commerical product releases and now some are even shipping their 3rd commerical product release of IPv6. Bob is correct. I just about have my ISP in NH to give me IPv6. They have tested it pretty well. 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 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: James Kempf [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 1:21 PM To: [EMAIL PROTECTED] Subject: Retail IPv6 Service in the US? I'm in the process of upgrading my home computing infrastructure in order to be able to use IPv6. Does anybody know a retail ISP in the US that provides IPv6 service (specifically, in the SF Bay Area)? I did a quick Google search and all the offerings seem to be for backbone service. jak IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
Re: draft-ietf-ipv6-node-requirements-01.txt
I've read this a couple of times and I find the security section (sec 8) quite confusing. I am not a security expert but it appears to me that it is not consistent. In particular sec 8.2 says AH [RFC-2402] must be supported. It then goes on to say there is no real need for AH and in both section 8.1 and 8.3 there are items that MUST be supported if AH is implemented. It would seem the if is redundant or something is wrong. Equally, section 8.1 says that IPSec tunnel mode MUST be supported and then goes on to say case MUST be supported if IPSec tunnel mode is implemented. The first paragraph of section 8.3 finishes with the sentance Note that the IPSec WG also recommends not using this algorithm. It is not clear to me which of the three algorithms mentioned in that paragraph this sentance refers to. It seems from section 8.3 that there are four encryption algorithms that must be supported AES-128-CBC, HMAC-SHA-1-96, HMAC-MD5-96 and HMAC-SHA-256. I think this section could however be worded more clearly. It would also be good if the appropriate RFCs were referenced in the text. From the point of view of very small devices, whilst I understand that IPSec support is a requirement, it seems that requiring transport mode and tunnel mode, AH and ESP and four algorithms (plus null encryption) seems onerous. I wasn't part of any discussion on this, but I would appreciate it if someone would explain particularly why so many algorithms are required. Finally a small editorial nit. There are lots of is MUSTs and few is SHOULDs in the document that should be MUSTs and SHOULDs. Richard. 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]
