Re: TCP MD5
Thanks for your answer, I agree that IPsec should be prefered. Kind regards. Francis Dupont wrote: In your previous mail you wrote: Does anyone know if TCP MD5 signature option (RFC 2385) used for MP-BGP is applicable for IPv6 ? = it should because RFC 2385 uses the pseudo-header (defined for each TCP over foo) for the network layer part... IMHO IPsec is far better but RFC 2385 is applicable if you don't have IPsec. Regards [EMAIL PROTECTED] PS: of course you should have IPsec if you have IPv6 (:-)! 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: unique enough [RE: globally unique site local addresses]
Kurt Erik Lindqvist wrote: No. Scores won't buy it. Let's not forget that one of the reasons behind the considerable success of NAT, despite its huge annoyances, it because NAT does provide some of the PI perks. PA is good for dial-up users and home/soho setups. Bigger, you find NAT, because for many the no-sweat ISP switch is worth more than the NAT-induced problems. In my experience, the number one reason for going to RFC1918/NAT is an ISP change. The ISP pulls out of a market or tanks, the customer looks at my proposal for renumbering, chokes at the bottom line, and says make sure we don't have to go through this again next time the ISP bellies up. Welcome to NAT. I am not completely convinced about the above. It would be really interesting to understand why enterprises decided to do NATs instead of PI space. My guess is that many of the companies that use NAT do it simply because they can not justify the /24. These probably don't qualify as enterprises, but nevertheless there has to be a reason to why some enterprises go for NAT, others for PI space. From my years at a large carrier I can't say there is a pattern. I wonder if it isn't as simple as knowledge. Few know how to actually apply for PI space. Sure. Their ISP told them it was hard to get space, and/or someone told them lies about NAT being a security feature. No mystery. 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]
Re: unique enough [RE: globally unique site local addresses]
No. But I fail to see what we gain with creating a special block from where we assign PI addresses. The RIRs can equally well assign PI space from the current IPv6 unicast space. Sure, this will lead to growth in the size of the DFZ, but that is a routing problem. I think we're arguing the same side here... I'd like to see addresses available to enterprises (and home users, for that matter) with the following properties: 1) globally unique 2) provider independent (AKA portable) 3) globally routable 4) indistinguishable from provider-allocated addresses by routers, applications, etc. However, the concern that has been voiced by many in the IPv6 WG is that property (3) cannot be provided in a scalable manner. This has led to a belief that we can't have property (4), because ISPs will need to know which prefix advertisements to accept, and which to block... So let's give them PI space!!! We don't really need more abbreviations, we have the address space so far, we are still far from hitting the roof of the routing table in IPv6 I don't care what we call it... I read your draft on multi6 regarding longer prefix multihoming, and was surprised to see your assertion regarding how far we are from having a route scaling problem in IPv6... But, do you really think that we will continue to have fairly small routing tables if we allow every enterprise (and home?) to get its own portable address allocation? Or would we need to come up with some way to assign these addresses in an aggregable manner. Are you proposing a particular mechanism that would allow aggregation of PI address allocations? I know that there is a geography-based PI allocation proposal in mutli6, but I don't understand how they produce aggregation. There are multiple providers in every city, and those providers networks may not be topologically close to each other, even though they are geographically close. This would solve the uniqueness problem and take away the NAT worries. True, but it would cause IPv6 routing table growth... Do you have an answer for that? 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: Enforcing unreachability of site local addresses
GUPI would not be globally routable. It would be a way to make sites privately communicate, as neither the limited usage or the moderate usage of site-locals provides this. And compared to global addresses the advantage is? Besides not having to go to a RIR? not having to have a connection to the public v6 internet in order to get an address block, or if you are connected, having a prefix which is stable across changes in ISPs. 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 until the ghost of Dijkstra comes out with a solution, graph theory still tells us that (2) and (3) are contradictory. or until some other things change, e.g. - ISPs are willing to route suboptimally (artifically make the graph simpler) - we work out a way to compute routes on-the-fly (caching ones that have been recently used) rather than pre-computing the entire table (this probably implies that we push route computation to the edges and source-route through the core) - we require certain interconnection paths (e.g. requiring major population centers to have a central peering point) in order to make the graph simpler in other words, a substantial change to the routing architecture (heavy technical change) and/or enforced constraints on interconnection (heavy political change) even if we solve the route computation problem, it's hard for me to imagine with forwarding tables containing ~ 2**48 prefixes. 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: unique enough [RE: globally unique site local addresses]
1) globally unique 2) provider independent (AKA portable) 3) globally routable 4) indistinguishable from provider-allocated addresses by routers, applications, etc. Margaret, Routing solutions have to consider have to be considered with two angles, politics and graph theory. The points you are making may be great politics, but until the ghost of Dijkstra comes out with a solution, graph theory still tells us that (2) and (3) are contradictory. -- Christian Huitema 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
Kurt Erik Lindqvist wrote: So the remaining question besides the PI issue would be to define limit then? This is a little simplified. I would say the remaining question is how to manage the risk they end up being a mess in the global routing table, and scalability issues. These are the issues why we don't currently have PI. 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: Enforcing unreachability of site local addresses
To address the subject line: The only way to enforce unreachability is to make the prefix ambiguous, and thereby remove the value of trying to propagate it. Any definition of a globally unique space will have to discuss how it scales *when* (not if) it gets announced into the routing system. Tony 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: EUI-48 globally unique site-locals (GUSL)
I agree with Brian that there are issues with DNS configured databases, but the event frequency of this is generally low enough I would consider it worth the risk. The problem I do have with it is the lack of aggregation in the IGP that would result. While flat routing is not a problem for a small network, it wouldn't work when the network reached any significant size. From my perspective, there is room here to support an automated set as well as an aggregatable set. If we took one /16 from the fec/10, say feff, and used the next 48 bits from the router EUI to create the /64, there would be no management required, but the networks that wanted explicit control could filter that /16 in the IGP, and still have plenty of SL space to manage as aggregates. How that works after the EUI-48's run out is a different question... Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bob Hinden Sent: Sunday, December 01, 2002 9:47 AM To: Aidan Williams Cc: [EMAIL PROTECTED] Subject: Re: EUI-48 globally unique site-locals (GUSL) Aidan, For each link, a router may automatically assign a site-local address from an EUI-48 (ie a MAC address) using the following address format: | 12 bits | 48 bits | 4 bits | 64 bits| +-+--+--+--+ | fef | router device ID | sub ID | machine interface ID | +-+--+--+--+ Figure 1: Address Format: fef0::/12 BTW, two bits in an EUI-48 (i.e., the g and u bits) are not needed if using this as a global token, so it could be easily compressed to 46 bits leaving two more bits for the subnet. I am not sure this helps very much with the other problems raised. 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] 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: EUI-48 globally unique site-locals (GUSL)
Tony Hain wrote: The problem I do have with it is the lack of aggregation in the IGP that would result. While flat routing is not a problem for a small network, it wouldn't work when the network reached any significant size. Define 'significant'. According to Brian Carpenter (28/11/2002): The question is, at what scale does route aggregation begin to matter? The sort of VPN-based or merger-and- acquisition based networks we are talking about don't seem to be anywhere near that scale; we know that flat routing of thousands of prefixes is possible. So it may be philosophically unsettling, but I don't think it is operationally unsettling. I freely admit my experience with routing tables is insufficient to know where this cut-off is, but the gist I've been getting is 'hundreds - easy', 'thousands - doable'. Am I hearing wrong? -- 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
The only way to enforce unreachability is to make the prefix ambiguous, which in turn causes the set of problems that make us want to avoid site-locals. maybe we don't need to 'enforce' unreachability as a matter of protocol. for instance, there's no 'enforcement' of IP packets being routed to their destinations. sometimes they're routed elsewhere (as in interception proxies) but we've generally done okay without 'enforcement'. 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: EUI-48 globally unique site-locals (GUSL)
You are correct, but approaching 10,000 flat routes will cause the IGPs to show their limits. (In case you were thinking that was an outrageous number, there are IPv4 networks with that many subnets, and they can only exist through aggregation.) The point is that we need to allow for managed aggregation in the scheme, but that does not preclude automatomation for a subset of the SL space. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew White Sent: Wednesday, December 04, 2002 5:00 PM To: [EMAIL PROTECTED] Subject: Re: EUI-48 globally unique site-locals (GUSL) Tony Hain wrote: The problem I do have with it is the lack of aggregation in the IGP that would result. While flat routing is not a problem for a small network, it wouldn't work when the network reached any significant size. Define 'significant'. According to Brian Carpenter (28/11/2002): The question is, at what scale does route aggregation begin to matter? The sort of VPN-based or merger-and- acquisition based networks we are talking about don't seem to be anywhere near that scale; we know that flat routing of thousands of prefixes is possible. So it may be philosophically unsettling, but I don't think it is operationally unsettling. I freely admit my experience with routing tables is insufficient to know where this cut-off is, but the gist I've been getting is 'hundreds - easy', 'thousands - doable'. Am I hearing wrong? -- 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] 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
If we don't enforce unreachability through ambiguity, we need to provide an alternative that won't crush the routing system. BTW: I am updating my geo draft based on the comments from the last round, so hopefully it will have fewer places to throw technical rocks at. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 4:37 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Enforcing unreachability of site local addresses The only way to enforce unreachability is to make the prefix ambiguous, which in turn causes the set of problems that make us want to avoid site-locals. maybe we don't need to 'enforce' unreachability as a matter of protocol. for instance, there's no 'enforcement' of IP packets being routed to their destinations. sometimes they're routed elsewhere (as in interception proxies) but we've generally done okay without 'enforcement'. 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: Enforcing unreachability of site local addresses
If we don't enforce unreachability through ambiguity, we need to provide an alternative that won't crush the routing system. I suspect we all agree that crushing the routing system would be bad . It seems like the question is what mechanism (other than ambiguity) would be sufficient to prevent that happening. 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: Enforcing unreachability of site local addresses
Keith Moore wrote: If we don't enforce unreachability through ambiguity, we need to provide an alternative that won't crush the routing system. I suspect we all agree that crushing the routing system would be bad . It seems like the question is what mechanism (other than ambiguity) would be sufficient to prevent that happening. I still believe the fundamentals of: http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-03.txt are sound from an aggregation standpoint. Michele Iljitsch have an alternative that could be described as a derivative of the international dial-plan: http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt The problem is not defining approaches that have reasonable scaling properties. It is getting agreement that we don't need a perfect answer. Tony 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: EUI-48 globally unique site-locals (GUSL)
Tony Hain wrote: You are correct, but approaching 10,000 flat routes will cause the IGPs to show their limits. (In case you were thinking that was an outrageous number, there are IPv4 networks with that many subnets, and they can only exist through aggregation.) The point is that we need to allow for managed aggregation in the scheme, but that does not preclude automatomation for a subset of the SL space. Agreed. 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]
GUSL / GUPI summary
IPv6 folk, I tried to summarize below the GUSL / GUPI deal. We are pursuing two tracks here: 1. Uniqueness/limitation of site-locals: Two currents: 1.1 Limit site-locals to disconnected sites. Margaret is preparing a draft. 1.2 make site-locals unique (remove ambiguity). Also called GUSL. Two drafts to come: Bob and Michel+Charlie. Non-routability of site-locals could be guaranteed By the combination of default discards and of course by the local scope of such addresses. In *both* cases, SLs or GUSLs can *not* be routed outside the site, which means that for inter-site communications we need GUPIs. 2. Not-making-a-mess of GUPIs. GUPI = Globally unique, not globally routable. The first sad truth is that there is no consensual enforcement mechanism can guarantee that GUPIs will not end up being a global PI mess, IPv4-style. The second sad truth is that there is no consensus for un-aggregated PI today. The third sad truth is that there is no consensus either in giving away un-aggregated PI now and try to clean it later. The combination of the second and third sad truths is why we don't have IPv6 PI today. Therefore, GUPI candidates are indeed scalable (which very likely means aggregatable) global PI solutions. As a side note, this topic has been the quest for the Holy Grail of IPv6 multihomers since 1995 for what I have references of. 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: GUSL / GUPI summary
On Wed, 4 Dec 2002, Michel Py wrote: 1.1 Limit site-locals to disconnected sites. Margaret is preparing a draft. 1.2 make site-locals unique (remove ambiguity). Also called GUSL. Two drafts to come: Bob and Michel+Charlie. Non-routability of site-locals could be guaranteed By the combination of default discards and of course by the local scope of such addresses. In *both* cases, SLs or GUSLs can *not* be routed outside the site, which means that for inter-site communications we need GUPIs. There is no technical reason I can see why inter-site communications couldn't use GUSL's. I would see the necessarity of working around default discards if you want to interconnect two site-local domains as a feature, not a problem. -- 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 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: GUSL / GUPI summary
The first sad truth is that there is no consensual enforcement mechanism can guarantee that GUPIs will not end up being a global PI mess, IPv4-style. There's no consensus enforcement mechanism that can guarantee anything else about IP operation either, but somehow it often seems to work. The second sad truth is that there is no consensus for un-aggregated PI today. The third sad truth is that there is no consensus either in giving away un-aggregated PI now and try to clean it later. There's no consensus for what to do with SLs either. Getting consensus for what to do with SLs might require a consensus on GUPIs. You seem to be saying that because we don't have consensus today on GUPIs that no reasonable solution exists. I think we're still exploring the solution space. 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]
