- ipv6-wg - mailman.ripe.net

[ipv6-wg@ripe.net] Fw: Help setting ipv6 address on my machine with two ethernet cards
by mario 26 May '03

26 May '03

> i've two ethernet card on two host and i'm not able to set ipv6 address on > both ethernet card. > how can i do? > > question : > the device name of ethernet card for ipv6 is sit0 sit1 sit2 etc etc??? > > if not, how can i set ipv6 address for every interface that i have? >

2 1

[ipv6-wg@ripe.net] Discussion about RIPE-261
by Gert Doering 23 May '03

23 May '03

Hi, those of you that have been to Barcelona have heard the presentation by Paul Wilson from APNIC concerning the RIPE-261 document. In short, it's a proposal how to reorganize distributing IPv6 allocations "from the root" to the LIRs, fixing the way it's done now (ICANN allocating /23 fragments to the RIRs, and the RIRs having to fill them quite thoroughly, not leaving space for an ISP to grow past a /29). Technically, this is a matter between the RIRs and ICANN, but as this proposal affects routing and filtering as well, it would be useful to have consensus among the members that it's a good thing. So: please read the document (ftp://ftp.ripe.net/ripe/docs/ripe-261.txt) and comment on it. Note: this e-mail goes to ipv6-wg and lir-wg, but please don't followup to ipv6-wg - keep all of the discussion in the lir-wg mailing list. Speaking as "me personally" (this is not the official WG chair speaking here, just a concerned IPv6 user!), I have the following comments: - The /23 allocations ICANN -> RIRs are bad, because they lead to address space fragmentation, and the blocks are too small to do useful allocation towards the LIRs. Something NEEDS to be changed here. - Nevertheless, I do NOT like the idea of a "common address pool". People want to be able to see the "region" that a prefix is coming from by looking at the address. This is working fine now in v4 (except for the swamp and part of ERX) and in the so-far IPv6 allocations (except that due to the /23s it's getting messy), but would be broken by the CAP. - As a technical reason: people want to be able to filter IPv6 prefixes by region, like "I only have one uplink that provides me with US connectivity, so there's no need to carry any US prefixes in my routing table, I just point a summary down that line". This is not yet done, but I am convinced that we shouldn't break routing hierarchy without good need. - If people *really* go into "multiple /48s per site" multihoming, source address selection works by doing a longest-match check, and this will work better if same-region addresses have something like a common prefix, instead of "everythins smeared everywhere". So my personal recommendation would be: - change the /23 allocation boundary ICANN -> RIR to something more useful, like a /12 or so (a /12 means "512 of them are available, so we're not yet burning bridges - but a /8 would work as well. A /16 is already somewhat tight). - every RIR still gets its own allocation from where RIR->LIR allocations are taken - inside that RIR allocation, use the binary chop algorithm described in RIPE-261 for the RIR->LIR distribution. So - let the discussion start now! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

1 0

Re: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Gert Doering 23 May '03

23 May '03

Hi, On Mon, May 12, 2003 at 09:27:04PM +0200, Jeroen Massar wrote: > > LACNIC has allocated to /32s, as far as I can see. One is already > > visible (2001:1200::/32). > > Grmbl, those don't show up in http://www.ripe.net/ipv6/ipv6allocs.html > :( No (database mirroring issue). RIPE people know about it and are working on it. > Okay going to fix up the bogon filter so I will at least catch them on > sight. :) > http://www.sixxs.net/tools/grh/tla/lacnic/ : > 2001:1200::/32 - 2002-12-19 - visible > 2001:1208::/32 - 2003-02-03 - not visible Yup :) > http://www.sixxs.net/tools/grh/tla/ now reads: > 8<----------------------------- > Prefix Length distribution > The following prefixlengths are delegated by the above RIR's. > > 58x /24 > 56x /28 > 336x /32 > 50x /35 > Totaling in 500 TLA prefixes. > ------------------------------>8 > > 500 TLA's over 54 countries! Oh, wow. Very impressive, this! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54495 (54267) SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299

8 18

RE: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 22 May '03

22 May '03

> Kimmo Suominen wrote: > I've used IPv4 space in the past to connect to extranet > providers using unique addresses, without connecting to the > Internet. Is such use not allowed in the IPv6 world? One > must promise to advertise the addresses to the Internet to > get an allocation? Although this is blurry (no explicit requirement) we can say that as of today, yes. But the space LIRs get is big enough to provide both Internet and extranet services. I don't see any extranet-only provider getting address space now though, and for multiple reasons. > Gert Doering wrote: > I wouldn't go so far as to say "it's not allowed". Me neither. Actually, I don't see why it should be forbidden, as long as one obtains the address space, which is the issue here. > When the policy was made, people were still suggesting the use > of site-local addresses for "non-global" usage. Site-locals > seem to be dead, so there is a hole in the policies right now. > Passing on the question from the registry point of view to the > IETF people (Michael & co): what are your recommendations how > this can be addressed (in the double sense)? [disclaimer: I do not represent the views of the IETF] This is a complex answer. First, let's not leave site-locals for dead yet. Technically, we do have site-locals using the "full usage" model, as defined by RFC 3513 that was just published. The current situation is that there is a "consensus" to deprecate them, which has pissed so many people that appeals are lined up for the next 2 years already (take-a-number if you want to appeal). There is no actual text to remove site-locals and it is expected that any text that would attempt to do that will be stalled and never go forward. In short: technically speaking we currently do have site-locals with an RFC in the standards track and I don't expect any change any time soon. That being said, the reason we got into this deadlock is that site-locals as currently defined do not please many people. If there is change in leadership within the IETF and work on site-locals is resumed (instead of trying to get "my way or no way") it is expected that site-locals will be restricted to a model that prohibits communication between sites. So, in any case I would not use site-locals for communication between sites. There are ideas floating around to make them globally unique, but this is for the purpose of avoiding renumbering when merging sites and not to provide site-to-site communication. Global addresses are required for that purpose, whether or not they are publicly routed or not. There are several proposals to provide PI-like addresses that are moving forward though. Michel.

3 2

RE: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 19 May '03

19 May '03

Folks, What is the word about an IPv6 bogon route server? The cymru one has only IPv4 for the time being. Jeroen or Gert, are you planning on something like this? Michel. > Jeroen Massar wrote: > *whisper in ear* not after tonight when the bogon reporting > gets active :)

3 2

RE: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 19 May '03

19 May '03

Christian, > Christian Kuhtz wrote: > Why not ask Rob Thomas do the same for IPv6? I did and I know he's working on it. > We don't need to reinvent the wheel and have multiple > sources for this stuff. I'm not sure about that. - I like redundancy. - The IPv6 situation is quite different than the IPv4. In IPv4, the bogon list is constructed by taking out what is not allocated. In IPv6, this would not be enough as there are so many huge holes in allocated space that hijacking applies both to allocated and unallocated. - Therefore, things such as what Jeroen does which is a live analysis of the actual routing table have value. One can argue that the name for this would be a real-time blackholing table and not a bogon list, but nevertheless a route-server for these would be welcomed. Jeroen please correct me if I'm wrong but what you call a bogon is a route that you have actually seen in the GRT and that has no business there? So, I don't see any re-inventing of the wheel here. It is clear that Rob's IPv6 bogon list would include 4000::/4 and FE80::/10 among other things, but a more dynamic blocking such as what Jeroen could do would be welcomed too. Michel.

1 0

[ipv6-wg@ripe.net] Help: Cannot assign requested address?
by Warodom Werapun 19 May '03

19 May '03

Why I got error message "Cannot assign requested address"? Tested on Linux Redhat 8.0, Kernel 2.4.20. [root@MN sysconfig]# ifconfig eth1 | grep inet6 inet6 addr: 3ffe:b80:1e99:2::2/64 Scope:Global inet6 addr: fe80::2e0:29ff:fe79:ff5/10 Scope:Link [root@MN sysconfig]# ping6 -I eth1 fe80::2e0:29ff:fe79:ff5 ping: bind icmp socket: Cannot assign requested address [root@MN sysconfig]# ping6 3ffe:b80:1e99:2::2 connect: Cannot assign requested address [root@MN sysconfig]# ping6 -I eth1 3ffe:b80:1e99:2::2 connect: Cannot assign requested address Thank you for reply - Warodom Werapun

1 0

RE: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 19 May '03

19 May '03

Carlos, > Carlos Morgado wrote: > Yes, that is indeed one scenario. But consider the extreme > case of an operator which only sells transits to multihomed > customers who already have their own address. Can you come with a real example? More, can you come up with a real example that has applied for space and has been denied the prefix? On paper, this is an issue but policies are not on planning on every possible hypothetical case. Michel.

2 1

RE: [ipv6-wg@ripe.net] Update on IPv6 filter recommendation
by Michel Py 19 May '03

19 May '03

Gert, > Gert Doering wrote: > I have just added an update to the "strict" filter list of > my IPv6 filter list recommendations on > http://www.space.net/~gert/RIPE/ipv6-filters.html Thanks for the heads-up. Some comments: > ipv6 prefix-list ipv6-ebgp-strict permit 3ffe::/18 ge 24 le 24 > ipv6 prefix-list ipv6-ebgp-strict permit 3ffe:4000::/18 ge 32 le 32 > ipv6 prefix-list ipv6-ebgp-strict permit 3ffe:8000::/22 ge 28 le 28 This part is fine. > ipv6 prefix-list ipv6-ebgp-strict permit 2001:500::/32 ge 48 le 48 It would be interesting to have more refinement here. What I mean is that I would be open to allow a /48 that contains a root server but not a /48 that serves an IXP. More details/specifics to what is inside 2001:500::/32 would be appreciated. > ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 35 le 35 I think this could be refined too. The range where /35s were originally allocated from is much smaller than 2001::/16. > ipv6 prefix-list ipv6-ebgp-strict permit 2001::/16 ge 24 le 32 This could also be refined. Not all 2001::/16 has been delegated to RIRs. ARIN got a block, RIPE got a block, APNIC got a block, but there still is some undelegated space. The drawback of refining to that level is that it will inevitably induce a situation similar to 69/8 and will require maintenance, but the other side of that coin is that it would prevent people from hijacking prefixes from undelegated space. As an example and please correct me if wrong in the address I picked because it's all from memory, if I hijack and announce 2001:FEED::/32 that would pass your filter but this prefix can't be assigned to anybody now as it is not part of a larger block that has been delegated to a RIR, so it must be a hijack. Michel.

4 4

RE: [6bone] RE: [ipv6-wg@ripe.net] Update on IPv6 filter recomme ndation
by João Carlos Neves Cabral 16 May '03

16 May '03

On Fri, 16 May 2003, leo vegoda wrote: > Hank Nussbacher <hank(a)att.net.il> writes: > > [...] > > >What are the RIRs doing to reclaim all those "red" lines of allocations > >that have never once appeared in a routing table? I would say all > >assignments from before Jan 2002 and that have "never"in the "last > >seen" column are ripe for revocation.Question is, why hasn't this > >been done before and has this been discussed so far? > > Is there a policy requirement that IPv6 prefixes allocated by RIRs must > be routed on The Internet? I've not found it in the current "IPv6 > Address Allocation and Assignment Policy". :Is there such a requirement for IPv4 prefixes? If yes (and I would hope :so, otherwise why would anyone want RFC1918 addresses when one can get :"real" IPs), then I think the same should apply for IPv6 prefixes. Allow me to give my two cents on this one: I should think not! I'm not thinking in terms of announcing /32s on the Internet; if announcing a /32 on the Internet is a requirement, I can easily cope with it. But what about in terms of private versus globally reachable IPv6 addresses ? In IPv4 we need to be careful and save IP addresses because there aren't that many and hence, we use RFC1918. In IPv6 we no longer have that problem ... so why should anyone need to use private addresses unless for a really small guarenteed closed network (i.e. site i.e. site-local within the site only) ? My question is, how do RIRs look at a company or institution using a slice of its /32 for their internal not reachable from the Internet networks ? Is this acceptable usage of IPv6 addresses or do we need to all start using the same site-local addresses as we do for RFC1918 in our internal networks and end up with endless problems with address conflicts ? Back on the subject, I wouldn't be shocked if IPv6 /32s were assigned by RIRs to LIRs that need these addresses for uniqueness and yet, don't need for them to be announced on the Internet. regards, Joao. ---

1 0