- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] DNS servers
by BEGIN, Thomas 05 Mar '03

05 Mar '03

HI, I'm wondering what's the way for specifying to a host DNS server's addresses. I mean are these addresses necessary (from DNS servers) stocked in each individual host (as it used to be for IPv4)? or is there a way to give this information to routers ? I came to this question after reading the cisco's documentation about IPv6 commands (http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/12…) which specifies about giving to routers DNS server's addresses. Thanks Thomas

1 0

[ipv6-wg@ripe.net] DNS servers
by BEGIN, Thomas 05 Mar '03

05 Mar '03

HI, I'm wondering what's the way for specifying to a host DNS server's addresses. I mean are these addresses necessary (from DNS servers) stocked in each individual host (as it used to be for IPv4)? or is there a way to give this information to routers ? I came to this question after reading the cisco's documentation about IPv6 commands (http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/12…) which specifies about giving to routers DNS server's addresses.

1 0

[ipv6-wg@ripe.net] Re: Reverse delegation for 6bone address space in ip6.arpa
by Axel Pawlik 20 Feb '03

20 Feb '03

Petr, all, over the last months, the RIRs have developed a reasonably pragmatic procedure to basically mirror the reverse delegation entries under ip6.int into ip6.arpa. Today, we have a working prototype implementing this approach. Unfortunately, our proposal has not been received favourably by the current administrator of the 6bone reverse delegations. To satisfy the needs of our members, however, we are now discussing another way to provide this functionality in a different way, building on the experiences we have made during the Early Registrations Transfer (ERX) Project. We will coordinate this closely with the other RIRs during next week's APNIC meeting; we are obviously also keeping an eye on the 6bone developements as regards the registry transfer and phaseout proposals. Expect a progress report after that. regards, Axel

3 3

[ipv6-wg@ripe.net] network's architecture under IPv6
by BEGIN, Thomas 20 Feb '03

20 Feb '03

Hello to all, I am wondering on IPv6 impacts over a company network's architecture. I mean, a big IPv4 network has to be divided in several VLANs in order to lighten the available bandwidth (sometimes for security reasons but it is not my interest in this case). And this because broadcast messages are received and examined by all network adapter. Thus comes my question: As there is no more broadcast messages but only multicast messages in IPv6, is there still a need to divide a big network in smaller networks (VLANs) ? Thanks Thomas BEGIN

2 1

[ipv6-wg@ripe.net] network's architecture under IPv6
by BEGIN, Thomas 20 Feb '03

20 Feb '03

Hello to all, I am wondering on IPv6 impacts over a company network's architecture. I mean, a big IPv4 network has to be divided in several VLANs in order to lighten the available bandwidth (sometimes for security reasons but it is not my interest in this case). And this because broadcast messages are received and examined by all network adapter. Thus comes my question: As there is no more broadcast messages but only multicast messages in IPv6, is there still a need to divide a big network in smaller networks (VLANs) ? Thanks Thomas BEGIN

1 0

[ipv6-wg@ripe.net] Second IPv6 deployment survey
by leo vegoda 20 Feb '03

20 Feb '03

Dear Colleagues, At the IPv6 WG session at RIPE 44 last month, the RIPE NCC was requested to conduct a second survey on IPv6 deployment. Information on the first IPv6 deployment survey conducted by the RIPE NCC is available at: <http://www.ripe.net/ipv6/ipv6-survey-summary.html> <http://www.ripe.net/ripe/meetings/archive/ripe-42/presentations/ripe 42-ipv6-survey/index.html> In the last survey we contacted LIRs that had received IPv6 allocations. To help develop the structure of the second survey, we would like community input on the following issues: 1. Should the survey be restricted to RIPE NCC members? 2. Should the survey be restricted to those holding IPv6 address space? 3. If the answer to 2 is "yes", should those networks have had the address space for any particular length of time? We would also appreciate comments on issues that are important to the IPv6 community with regards to IPv6 deployment. We look forward to your input. Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

[ipv6-wg@ripe.net] New IPv6 block allocated to RIPE NCC
by leo vegoda 17 Feb '03

17 Feb '03

Dear Colleagues, The RIPE NCC received the IPv6 address range 2001:1400::/23 from the IANA in February 2003. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: <http://www.ripe.net/ripe/docs/smallest-alloc-sizes.html> Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

[ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Andrius Kasparavicius 14 Feb '03

14 Feb '03

Hello, what I should think about when I allocate IPv6? :-) Just like IPv4 subnets for needed IP devices, the same but multipled(how much?) for future hierarchy, divide all I have for all who need(best hierarchy). Divide geographically, by organisations, people population for best hierarchy all v6? I look ahead, hierarchy.. a lot of IPv6. Hmm.. And at the end, would I be bad if I will use /127 for point-to-point(tunnels). respectfully, Andrius

7 29

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Gert, >> Michel Py wrote: >> available for that. What Gert wants is a large number of >> bits to make the subnet number look good, in the *subnet* >> bits, > Gert Doering wrote: > Call it "look good", but at least you understand the goal. > I appreciate that. Don't get me wrong: the goal (like any naming convention) is good (although operational experience suggests that in this very case it will be useless after a few years). This is not the point. The point is that you think that you can use the IID bits for routing purposes. This discussion has come five times on the table in the last 10 years and has always ended in the hole. In a nutshell, what you want is to declare that the IID bits could have a mixed use, either as IID bits or as subnet bits. Sharing the IID bits for routing purposes is not a good idea, and we just don't have enough bits to do what you want otherwise. > At least four people have voiced here that they are doing this, > and I'm pretty sure that many more networks are doing non-/64s > on point-to-point links for similar or other reasons) As Randy and I said before, the ipv6 WG would be the place to discuss addressing architecture issues. I will clue you though that what some call the "old guard" includes lots of very knowledgeable people with CONSIDERABLE operational experience, including a number of people that have tried what you suggest before with other protocols. Large address spaces such as IPv6 are nothing new to some of us. More than a decade ago, I was dealing with a lot of Novell/IPX networks. The IPX address is 80 bits, 48 IID bits and 32 subnet bits (Hex notation same as IPv6). We did see a lot of funny subnets numbers such as "BABE4B0B" and a few other more explicit ones that I can't really mention here. They were contests to name subnets in the good old IPX days. Anyway, at the time these 32 subnet bits were more than enough to do what you are suggesting for IPv6, some people including myself actually tried, and after reorganizing and merging networks it becomes meaningless. In short: Nice idea, bit a) it does not work in the long run, we tried it before and b) even if it did the benefits that it brings are not worth running the IID bits in mixed mode anyway. Michel.

2 1

RE: [ipv6-wg@ripe.net] IPv6, future internet, hierarchy
by Michel Py 14 Feb '03

14 Feb '03

Stephane, > Stephane Bortzmeyer wrote: > Clearly, it is not so simple. While you cannot encode > *everything* even in 128 bits (billing status), it is > better when you can encode at least a few things. Yes, it is better when you *can*. > Otherwise, "serious" operators would not name their > routers with sensible names like > P12-0.NYKCR2.New-york.opentransit.net This takes 296 bits, btw. It is done because it *can* be done because it's a name, and that's exactly what names have been designed for. Not IP addresses. This is not the issue anyway: We are not talking about configuring the MAC address with a structure that is meaningful; this can be done already and there are 62 bits available for that. What Gert wants is a large number of bits to make the subnet number look good, in the *subnet* bits, totally ignoring conservation. Where does this come from? Nobody does that except him, nobody does it in v4, it has never been part of v6. We can't allow end-sites to do that kind of thing, they would all need at least 48 subnet bits as well. Michel.

3 2