RE: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
> Additionally, let us postulate that all three entities have a small > population of hosts which must be accessible from the public networks, and > that those hosts must also be reachable from the local private network. The plan of record is that these publicly reachable hosts will have both a local address and a global address. The global address will be derived from a prefix announced by the ISP. > Unless I have missed some essential clause in your description above, we > appear to have a failure mode, with a root cause of user neglect or user > error, in which the non-propagation requirement for unique-local prefixes > to the global routing table is likely to be violated. Stuff happens. However, one ISP making a mistake does not have to endanger the whole Internet. Any good ISP is suppose to filter routes in the FC00::/7 prefix from its own BGP announcements, and to ignore prefix in the FC00::/7 range that peer ISP might mistakenly advertise. -- 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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
> However, we might be able to make the suggested restrictions a bit less > burdensome, provided that we can satisfy the never-route-private-addrs > zealots that the revised scheme can still be effective in limiting > unintended propagation of non-globally-routable prefixes. See below for > specifics. I'll welcome further comments from any source. The goal of the recommendation is both to provide some degree of isolation, and also to ensure that the local addresses are not abused in the future. One way to achieve that is to ensure that routers systematically junk any packet sent to FC00::/8 or FD00::/8, unless a more specific route has been installed. This will not require Dan to update his internal routers, since there will indeed be a more specific route for his own internal site. Backdoor connections between links will also work, if a /48 route is announced for the backdoor. -- 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: Comments on draft-ietf-ipv6-unique-local-addr-00.txt
Geoff's initial comment included the classic birthday paradox formula, which would indeed apply if we were to use the randomly generated addresses as global site identifiers valid across the Internet. The practical consequence is that we should be extremely clear about the usage limitation: randomly assigned addresses should in no way be used as site identifiers. This should not even be left for further study, it is just wrong. The usage that is actually envisaged is more limited: an identifier that provides disambiguation in a limited environment, normally a single site, possibly a small number of sites directly linked by VPN-like relations. In that scenario, the collisions that matter are those that occur within this "working set" of connected sites. The probability of such a collision is determined by the probability of collision "x" between two identifiers (x = 2^-40 in our example) and by the size "W" of the working set. The probability that single site does not collide with any member of a working set is: P(collision in a set of size W) = 1 - (1-x)^(W-1) There will be a large number of these working sets, probably as many as there are sites -- each site will participate in average to W sets. The probability that a given site observes a collision in one of its working sets will be: P(collision in one of W sets) = 1 - (1-x)^(W*(W-1)) If we have N sites, the probability of observing one collision on the Internet will be: P(collision in N sites with W sets) = 1 - (1-x)^(N*W*(W-1)) Given x=2^-40, the number N for which this probability equals .5 varies with W as: W N 50 311070769 100 76982160 200 19148829 500 3054603 1000762886 2000190626 500030491 1 7622 Bottom line: using the random allocation in large working sets is a bad idea. If people want to do that, they should register a unique allocation instead. One possible way to improve the situation is to have a provision for small sites, in which we use a 56 bits random number to identify a link, rather than a 40 bits random number identifying a site. -- 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: Weekly posting summary for ipng@sunroof.eng.sun.com
I had to take time off this list, and thus had the privilege of reading one week of back up mail. I suggest that most of the participants in this discussions should (1) relax, (2) read the last week of email, and (3) realize that this discussion is both not productive and not funny. -- Christian Huitema From: [EMAIL PROTECTED] on behalf of Rob Austein Sent: Sat 8/23/2003 9:00 PM To: [EMAIL PROTECTED] Subject: Weekly posting summary for [EMAIL PROTECTED] Messages | Bytes| Who +--++--+ 25.16% | 40 | 25.68% | 216885 | [EMAIL PROTECTED] 12.58% | 20 | 14.43% | 121847 | [EMAIL PROTECTED] 12.58% | 20 | 11.50% |97109 | [EMAIL PROTECTED] 4.40% |7 | 5.06% |42750 | [EMAIL PROTECTED] 4.40% |7 | 3.85% |32475 | [EMAIL PROTECTED] 4.40% |7 | 3.24% |27324 | [EMAIL PROTECTED] 3.14% |5 | 4.24% |35799 | [EMAIL PROTECTED] 3.77% |6 | 3.05% |25734 | [EMAIL PROTECTED] 1.89% |3 | 3.57% |30164 | [EMAIL PROTECTED] 2.52% |4 | 2.13% |17957 | [EMAIL PROTECTED] 1.89% |3 | 1.94% |16420 | [EMAIL PROTECTED] 1.89% |3 | 1.85% |15622 | [EMAIL PROTECTED] 1.89% |3 | 1.74% |14682 | [EMAIL PROTECTED] 1.89% |3 | 1.59% |13456 | [EMAIL PROTECTED] 1.89% |3 | 1.33% |11243 | [EMAIL PROTECTED] 1.26% |2 | 1.90% |16083 | [EMAIL PROTECTED] 1.26% |2 | 1.41% |11921 | [EMAIL PROTECTED] 1.26% |2 | 0.87% | 7388 | [EMAIL PROTECTED] 1.26% |2 | 0.87% | 7330 | [EMAIL PROTECTED] 0.63% |1 | 1.02% | 8575 | [EMAIL PROTECTED] 0.63% |1 | 0.83% | 7047 | [EMAIL PROTECTED] 0.63% |1 | 0.83% | 7014 | [EMAIL PROTECTED] 0.63% |1 | 0.60% | 5098 | [EMAIL PROTECTED] 0.63% |1 | 0.57% | 4792 | [EMAIL PROTECTED] 0.63% |1 | 0.56% | 4696 | [EMAIL PROTECTED] 0.63% |1 | 0.55% | 4644 | [EMAIL PROTECTED] 0.63% |1 | 0.54% | 4583 | [EMAIL PROTECTED] 0.63% |1 | 0.53% | 4497 | [EMAIL PROTECTED] 0.63% |1 | 0.53% | 4436 | [EMAIL PROTECTED] 0.63% |1 | 0.52% | 4377 | [EMAIL PROTECTED] 0.63% |1 | 0.51% | 4332 | [EMAIL PROTECTED] 0.63% |1 | 0.46% | 3911 | [EMAIL PROTECTED] 0.63% |1 | 0.46% | 3852 | [EMAIL PROTECTED] 0.63% |1 | 0.43% | 3629 | [EMAIL PROTECTED] 0.63% |1 | 0.42% | 3541 | [EMAIL PROTECTED] 0.63% |1 | 0.39% | 3330 | [EMAIL PROTECTED] +--++--+ 100.00% | 159 |100.00% | 844543 | Total Grunchweather Associates provides this automatic summary on an at-whim basis at the request of the IPv6 WG chairs. Your mileage may vary. We decline responsibilities, all shapes, all sizes, all colors. If this script produces broken output, you get to keep both pieces. 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: Fourth alternative [was Re: Moving forward ....]
> Eliot Lear wrote: > I guess my concern is that ISPs end up routing the address > space in Bob's proposal and that we'll have another PI problem. > So while there's nothing wrong with Bob's proposal in theory > (indeed I prefer it vastly to the other SL approaches), if > customers believe they have stable addresses we could end up > right back where we were in the early '90s. I don't see this > happening for DSL customers but it could happenfor medium to > large size businesses who have the power of the purse. It is possible to write sufficient restrictions and avoid both the drift towards announcing /48 in the DMZ and using the unique local addresses in a NATv6 configuration. The requirement is that the site local replacement be "special". We can for example request that backbone routers ignore announces that fall in the special prefix unless a /48 has been explicitly. As a result, even if someone convinces their local ISP, they will not be able to get connectivity to the whole Internet, and the addresses will not be usable as "globally routed PI." In fact, we should do that. -- 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: apps people?
> The few self-described apps people I've seen take > a stand have to my recollection been strongly > against dealing with locally scoped addresses . Let's be clear. Our group (Windows Networking) has received a lot of feedback from developers of applications on the Windows platform. The negative developers' feedback was mostly centered on the difficulty of identifying the scope of an address, specially when a node is connected to several sites (e.g. home network and VPN to the corporate network), or when a node moves from site to site. Since the scope is not indicated in the address itself, applications have to keep track of a "site identifier" of some kind. The bottom line is that ambiguity hurts. The local scope nature also hurts, but not quite as much; it is another case of limited connectivity, which is a common "feature" in many networks. -- 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: Moving forward on Site-Local and Local Addressing
> Actually, I believe we do not have a birthday paradox issue in this case. > The birthday paradox would exist only if ALL 1.2 million self-drawn prefixes would > see each other. > However, in our scenario, the merging of two enterprises, only the two local > prefixes may collide with each other. > They can not collide with the other 1.2 million or any other number of prefixes out > there. > Thus, the probability remains 2^-40. The individual probability of two domains colliding is x=2^-40, but the global result on the Internet is a somewhat larger. If we have N domains, and each peers with M other domains, then the probability of absence of collision for each domain is: p1 = (1-x)^M The probability that no collision will be observed in the whole Internet is p2 = (1-x)^MN I believe we can easily find a value of N (say 10 billion) and M (say 100) where p2 is close to 1, i.e. some poor guy somewhere is going to get stuck. Which means that we should build an escape hatch: easy renumbering & number registration come to mind. -- 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: inevitability of PI = 3
Hey, we can legislate whatever... -- 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: apps people?
>> Let's be clear. Our group (Windows Networking) has received a lot >> of feedback from developers of applications on the Windows >> platform. The negative developers' feedback was mostly centered on the >> difficulty of identifying the scope of an address, specially when a >> node is connected to several sites (e.g. home network and VPN to the >> corporate network), or when a node moves from site to site. > > Which is to say, topology information which it didn't > have to consider in the past and for which it has little > information at its disposal from which to make decisions. No, I specifically did not say "topology information". Topology is a very wide notion, and application developers are actually OK with some amount of topology handling, e.g. doing things differently with folks that are "near me". The feedback on local addresses was very specific. Applications would learn or remember that the address of some correspondent was "FEC0::1234:5678:9ABC", they would try to feed the address in a socket address structure and issue a connect, and the call will fail because they did not fill up the "site identifier" variable, as in "FEC0::1234:5678:9ABC&1". The problem is compounded by the fact that the site identifier varies with the host instantiation, e.g. sometimes &1 and sometimes &2, and thus that the host identifier cannot be remembered in memory, or learned from a name server. Having a non ambiguous address solves that problem, because the stack will know over which interface a connect request to "FC00:DEAD:BEEF::1234:5678:9ABC" shall be routed! . The application will not have to handle "site identifiers", and that is a very good thing. -- 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: Moving forward on Site-Local and Local Addressing
I think we should do alternative B, i.e. deprecate and at the same time propose a replacement. Barring that, C is also acceptable. Alternative A is likely to generate fisrt uncertainty, and then a free-for-all, and the risk of some "grass root RFC 1918". -- 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: DiffServ field
> >Does anyone know is use of DiffServ field supported in some equipment and > >networks? > > It is supported in some equipment. I wouldn't be able to tell you how > networks configure their equipment; they generally view this as NDA > information. We have found some issues when trying to use the diffserv field in practical deployments. There are a number of routers in the network that were built and deployed before diffserv was widely accepted as a standard. Understandably, these routers implement the previous standard, i.e. the RFC 791 definition of the TOS bit. Specifically, the old routers look at the three precedence bits and treat it as a priority level. In practice, this restricts the number of diffserv code points that can be safely used. You don't want for example to define a code point for "less than best effort" in which the three precedence bits happen to mean "high priority" in the old routers... -- 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: IPv6 -> MAC multicast address mapping
> I can't think of a way this is a security problem - can you point this out > please? With the exception that a DOS might be mounted by sending packets > to the wrong MAC address that are later discarded... But you'll have to > stop them at the source, not at the receivers, to prevent the DOS. There is a class of attacks based on mismatches between MAC and IP addressing. For example, if a node is a member of an IP group, it is possible to send it a packet where the MAC destination is the unicast MAC address of the node, while the IP destination is the group address. Or vice versa, send a packet where the MAC destination is a multicast address, but the IP destination is a unicast address. Hackers can use the first technique to disrupt the operation of multicast groups, and the second one to mount some forms of denial of service attacks. These attacks require that the attacker be connected on the same link as a target, but there are cases such as public access wireless where this isn't much of a mitigation. (University dorms are also a great place for such attacks.) -- 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: Status of
> Bob, > > > > >>Hence, I see no real reason at all to stray from FEC0::/10 - and lots > >>of reasons to remain in that space. > > > > I think you are suggesting that the draft be changed to reuse the > > FEC0::/10 space with a resulting 38-bit global ID. This would allow > > for 274,877,906,944 prefixes, or 30 per person in 2050. > > > > My preference would be for a larger global ID, but I would like to > > hear what other folks think. > > > > For what it is worth, I agree with kre as well. Isn't that cool? We had this discussion before. In the spring of 1997, as a matter of fact. And the suggestion then was: > Date: Tue, 13 May 1997 11:25:42 -0400 > From: [EMAIL PROTECTED] (Christian Huitema) > Subject: (IPng 3627) Re: W.G. Last Call on "Advanced Sockets API for IPv6" > > > Site-local addresses have the same problem as link-local when a > > host has interfaces in multiple sites, e.g. interface A belongs to > > site X and interface B belongs to site Y. > > In fact, site local addresses have all the problems related to non unique > addresses, which are well known and documented in e.g. RFC 1627. This may > be late in the game, but we should really consider a way to somehow avoid > or minimize the problems related to that non-uniqueness. > > Did we ever consider inserting some site identifier, e.g. a random value, > in the site local prefix ? I know that this would not make the problem > disappear entirely, I know that randomness leads to unhappy birthdays, > specially when the random number is not actually random (albeit the site > manager could actually trow dices, it is a one time operation). But we > could still go a long way... Did we not in fact go a long way those last 8 years? -- 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: My Thoughts on Site-Locals
> This should not be surprising. Given that the applications community > blindly assumes there is a single addressing scope, when they bump into > the reality of the deployed network there will be problems. Proclaiming > that scopes are bad for applications does not make the filtering that > causes scopes go away. Bad, bad application developers. We should really punish them! :-) Seriously, application developers face some very real problems. The issues are uniqueness in space and uniqueness in time. The space dimension is experienced when a host is connected to several sites, e.g. home network and VPN. If the application receives a site local address from a local name service or a local discovery service, it must associate that address with a site identifier. The first stumbling block is that most applications don't have this concept, they just copy the address. The second stumbling block is that there are no readily available site identifiers -- you would need to manage a unique name space, which is precisely what you don't get from FFC0::/10. In the absence of site identifier, the routing of connections to the proper site is haphazard. The application is supposed to remember that the site local address was learned through a specific site, i.e. only use in site X the site local addresses learned from site X's DNS service. This become quickly very hairy, as the DNS does not in fact have a concept of site. Restricting hosts to handle exactly one site removes some of the problem. But you then bump into the time dimension. Hosts may become members of different sites at different times, e.g. a laptop moving from the office to the airport or to the home. Addresses learned in one site should not be used in the next, but for that you must have an easy way to tell that you have changed sites. Without a site identifier, that can be real hard. Tony, these problems are not theoretical. They come very much on top of the issues encountered by developers porting applications to IPv6. Using unambiguous addresses solves a lot of the problems: a multi homed site can route connections to the proper site, source address selection can work, and moves to another site can be detected. There are remaining issues, notably dealing with intermittent connectivity, but these issues are inherent to any mobility scenario. By the way, link local addresses tend to suffer from much of the same issue. However, it is easier for applications to deal with LL addresses, as there is a clear linkage between addresses and discovery protocols operating in a single link. -- 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: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing)
> > You don't get the point. If enough hosts come programmed to enforce > > scope restrictions, then the non compliant product ends up with a > > deployment headache and has to be fixed. This is basically the root of > > Internet standards -- enforcement by peer pressure. > > The Globally addressed peer hosts when a communicating host is > behind NAT are talking to another Global peer address at the NAT > agent. That is correct. The enforcement will not be by the remote site, except maybe if the remote site uses IPSEC. > This only requires complicity on the NAT box and the host, > not the peer communicator. The proposed requirement provides > no further burden to implementors than NATv4 systems. Your point is the mirror image of my argument. If a sufficient fraction of the hosts refuses to play along with the NAT, then the NAT will not be able to work. The laws of network physics are such that, if solution A (NAT) is broken, then the easiest next solution will be chosen (advertise a global prefix). The problem is that vendors of host software can only deliberately brake the NAT scenario if they have some "air cover", i.e. if the standard clearly says that communication between addresses of different scopes is prohibited. Which is why it should say so... -- 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: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing)
> > This simple suggestion will in fact prevent using SL in the NAT > > scenario, > > It will prevent _Standards Compliant_ client implementations from > using NAT, but as we both know many vendors loosely interpret > standards in any case. You don't get the point. If enough hosts come programmed to enforce scope restrictions, then the non compliant product ends up with a deployment headache and has to be fixed. This is basically the root of Internet standards -- enforcement by peer pressure. -- 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: e2e & global view
> % Let me try an rephrase my question. I would like to know if there is > % consensus on the architectural view that IPv6 should have addresses with > % different scopes? No, there is definitely not consensus on that point. There are three big classes of arguments. The first class of argument is more against "ambiguous addresses" than scoped addresses: using ambiguity as a surrogate for unreachability is unnecessary (firewall can do that on any address) and inconvenient (ambiguity of addresses makes several error scenarios undecipherable). The second class of argument relates to routing and network management. Maintaining scoped addresses makes routing hard, especially if a node has to support multiple instantiations of a given scope. Margaret also developed an argument about the need to maintain a site convex, and the interaction of that requirement with shortest path routing. The third class of argument considers the use of addresses by applications. Using scoped addresses forces applications to understand scopes, which is much more complex and error prone than just considering that all addresses are equal. > % Again, I fail to see how deprecating site-local addresses (specifically > the > % FEC0::/10 prefix) solves the underlying problem (e2e communications > failing > % with some src/dst address pairs). Everybody should know that, and Bill is perfectly correct: just because an address is globally unique does not mean it is reachable. However, if it is unique, you eliminate a number of the error cases caused by ambiguity. -- 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: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing)
If we are serious about NAT != SL, then we should enforce it. Clearly, we cannot send the protocol police and whack every market driven designer of a NAT, but we can perform "collective enforcement", i.e. design our specification in such a way that misusing site local in a NAT configuration is guaranteed to break every application, and thus that any attempt to deploy an IPv6 NAT using site local will be a deployment nightmare. Suppose for example that we change our spec to forbid any communication between addresses of different scopes. This can be enforced by senders (refuse to send a packet if dest scope != source scope), routers or firewalls (drop packet if srce and dest scope don't match), and receivers (drop incoming packet if srce and dest scope don't match). You don't need to enforce it in every host and every router to be effective: just enforce in in a significant fraction of the hosts makes sure that any attempt to use the forbidden pattern will be very unreliable. This simple suggestion will in fact prevent using SL in the NAT scenario, as at some point the scenario relies on communication between an SL addressed source (e.g. a client) and a globally addressed destination (e.g. a web site). I think that we should enforce this requirement whether we maintain site local or find a replacement for disconnected sites. -- 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]
Globally unique link prefix alternative to site-locals
The "anti-SL" arguments are primarily arguments aainst using ambiguous addresses. Ambiguous addresses are a royal pain in hosts that connect to multiple sites, either simultaneously or over time -- the applications need extra logic, and that creates bugs. But we clearly have an issue in the case of disconnected sites, intermittently connected sites, and ad hoc networks. The "let's pick a prefix" argument is probably OK for large "managed" sites. In fact, most of the large sites have at least one IPv4 address and can pick a prefix; they could even obtain a provisional allocation from a friendly ISP. But this leaves out the small sites, the ad hoc networks, the unmanaged sites. However, if we just look at these small sites, we can easily get unambiguous *link* prefixes of the form: ::/64 In a small site, these prefixes can be autoconfigured by routers, and then published in the IGP. If there are several routers on the same link, they can either elect a master prefix or just advertise one prefix each. Having unique per-link prefixes has quite a few advantages: - We get actual zero-configuration, a site can be just switched on. - Local connectivity can be used for adding a global addressing plan when the site joins the Internet. - Hosts can be multihomed at will; there is enough information in the address to find the right exit. - The addresses remain valid if a site is split, or if two sites are merged. - Unreachability is enforced by firewalls, not by bits in the address. - Since the link prefix is a /64, there is zero chance of having a nasty ISP leak it to the Internet. - If the /16 is well known, it can be plugged as "least preferred" in the address selection rules. Is anyone interested in pursuing this design? -- 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: CONSENSUS CALL: Deprecating Site-Local Addressing
Yes but.
I understand why we want to remove ambiguity in addressing and make the
application writer's task simpler, but we need to have a solution for
zero-configuration of disconnected sites.
> -Original Message-
> From: Margaret Wasserman [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, April 01, 2003 11:38 AM
> To: [EMAIL PROTECTED]
>
>
> Hi All,
>
> At the IPv6 WG meetings in SF, we reached consensus on several
> points, all of which will be confirmed on the IPv6 mailing list.
> One point in particular seems to be the source of discussion
> on our list and elsewhere, so we will check this consensus on the
> mailing list now. Specifically, we would like to check the consensus
> of the IPv6 WG regarding the deprecation of site-local addresses.
>
> This email asks those that were NOT present at the Thursday IPv6
> meeting in SF to express their opinions on a question that was
> asked of the room. If you expressed an opinion on this issue in
> SF you can skip this message; in any case you MUST NOT respond to
> this query.
>
> By now, all of you have heard about the IPv6 meeting held on
> Thursday, March 20th, where we discussed what to do about
> IPv6 site-local addressing.
>
> At the meeting, the chairs (Bob Hinden and Margaret Wasserman)
> changed the agenda to include a joint presentation by the
> chairs on various options for site-local usage. There were
> no objections to the agenda change.
>
> The chairs' joint presentation can be found at:
>
> http://www.psg.com/~mrw/IPv6_Site_Local_Mar03.ppt
>
> After the chairs' joint presentation, there was over an hour of
> lively discussion that covered many aspects of site-local
> addressing. Draft minutes of the discussion can be found at:
>
> http://www.psg.com/~mrw/ipv6-wg-minutes-mar2003.txt
>
> These minutes are a summary of the discussion, and they did
> not capture every detail of the discussion.
>
> During the discussion, it became clear that the "exclusive" model
> proposed by the chairs had some fundamental flaws and was not
> a viable option. The WG was unwilling to choose between the three
> options presented for site-local usage ("limited", "exclusive" or
> "moderate"), believing that all three models represented a poor
> cost vs. benefit trade-off. And, as the discussion developed, it
> became clear that there was growing support for deprecating
> site-local addressing.
>
> After the usual discussion regarding the phrasing and meaning
> of the question (not all of which was captured in the minutes),
> the chairs asked a yes/no question: "Should we deprecate IPv6
> site-local unicast addressing?" There was clear consensus in the
> room to deprecate site-local addressing. So, now it is time to
> check that consensus on the mailing list.
>
> In order to get a good read for consensus on this point, PLEASE
> adhere to the following rules:
>
> NOTE: DO NOT reply if you already expressed an opinion during
> the IPv6 WG meeting in SF!
>
> - Make your response very clear (YES or NO).
> - Respond by Monday, April 7th, 2003 at 5pm EST.
> - Do NOT respond if you were physically present
> in SF and participated in the consensus
> call at that time (We are trusting you!).
> - Respond to this thread with the subject intact.
> - Respond only once.
> - Clearly identify yourself (in the From: line or
> inside your message).
> - Include the IPv6 WG mailing list in your response
> ([EMAIL PROTECTED]).
> - PLEASE do NOT start any discussion in this thread
> (Discussions are encouraged in other threads).
>
> Any responses that do not adhere to these rules may not be counted.
>
> The question is:
>
> Should we deprecate IPv6 site-local unicast addressing?
>
> Valid responses are:
>
> "YES -- Deprecate site-local unicast addressing".
> "NO -- Do not deprecate site-local unicast addressing".
>
> If you express an opinion not to deprecate site-local addressing, it
> would be helpful if you would provide a reason. Providing a reason
> is completely optional, but it may help us to determine how to move
> forward if the consensus to deprecate site-locals does not hold.
> Possible reasons include:
>
> - Site-locals should be retained for disconnected sites.
> - Site-locals should be retained for intermittently
> connected sites.
> - Site-locals should be retained for their access control
> benefits.
> - Site-locals should be retained as a means for internal
> connections to survive global prefix renumbering.
> - Other (please specify).
>
> Please, make your response _very_ clear (either YES or NO), or it will
> not be counted.
>
> Please Note: DO NOT respond if you already participated in the
> consensus call at the meeting in SF. At the meeting, there were
> 102 people who raised their hands for YES (deprecate sit
RE: 6to4 and 2002:PRIV:ATE [RE: A use for site local addresses?]
> > You're making an assumption that all nodes implementing 6to4 > > pseudo-intefarce take part in the IGP to get the more specific > > 2002:FOO routes, > > Well, yes but these nodes are only routers. Hosts MUST NOT have any 6to4 > pseudo-interfaces (or have it deactivated). Making rules as we speak, uh? At most, you are saying that a node that has a 6to4 interface should be called a router. Fine. What have you achieved? You only get control if you can convince a specific node to not activate a particular function, i.e. if you had control over the node in the first place. It is reasonable to expect nodes who receive an RA for 2002:F00::, or for that matter 2002:DEAD:BEEF::, to route packets bound to that specific prefix towards the interface over which they received the RA. But it is also not unreasonable to expect nodes to drop packets bound to illegal 2002:: addresses, and possibly ignore advertisements of illegal prefixes. -- 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: A use for site local addresses?
One of the advocated uses of site local addresses was for disconnected sites. However, Dino made the point in the meeting that, if a site is truly disconnected, it can just as well pick any random addresses it wants. The absence of a "reserved range" (a la RFC 1918) will pressure the disconnected site to renumber when it actually connects, rather than go on using private addresses and a NAT. In fact, most large sites have at least one IPv4 address, and they can get a unique 2002::/48 prefix out of that address, even if they don't have an actual IPv6 ISP yet. -- 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: M & O Bits was: draft-ietf-ipv6-node-requirements-01.txt
> It should be SHOULD. The M bit means "use" Tasteful. The "O" bit means > use Stateful. Two different contexts. I was here when they were put in > ND and recall why. One reason is that not everyone believed that just > stateless was acceptable and that was vision on those persons part. We had a conclusive discussion off this point during the interim WG meeting in Sunnyvale. The reasoning goes as follow: if we want to maximize interoperability, we want to have a single mandatory address configuration procedure, not two; everybody agrees that we must support stateless address configuration; thus we should make stateless mandatory, and other configuration methods optional. This is properly reflected in section 5.3 (nodes MAY support DHCPv6), in section 4.5.2 (MUST support stateless) and in the current text of section 4.5.5, which is just fine. -- 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
> What words would you like me to use for portable, globally-routable > addresses that are assigned to an entity (home, enterprise, etc.) and > that can be used by that entity regardless of the ISP from which > they purchase their service, cannot be changed by the ISP, and don't > need to change if the entity changes ISPs. Provider independent. Hey, that is the definition. > I don't mean to imply, however, that these addresses would be > randomly assigned, or that there wouldn't be some way (other than > provider-based aggregation) to aggregate them. In fact, we would > NEED to find a way to aggregate these addresses to make them > useful/scalable. Possibilities for how to allocate aggregable > provider-independent addresses could include (among other options) > the geographical addresses that Tony Hain has proposed. > > What term should I use for that? "Aggregatable PI addresses", which is however kind of a contradiction in terms. Addresses are as much aggregatable as their assignment reflects the underlying topology, which includes the split of the network among various providers. By definition, a structure that is independent of providers can only be a gross approximation of the topology, and as such can only have crude aggregation characteristics. Geographical addresses are one such crude approximation of the topology. -- 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: 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 Linksys and Netgear build different types of equipment. Their hub and bridge/switch products most probably pass IPv6 through without any problem. But IPv6 will not pass through a "home router" (e.g. a DSL router) unless that device has some adequate code. -- 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: "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
> and I don't know why an ISP would accept advertisements for GUPIs from > its peers unless it was paid (well) to do so. The key part of enforcement is indeed the community effect. If the community agreement is that GUPIs should not be routed over the Internet, we will get a situation were GUPIs are automatically rejected by 90% of the ISP, through a combination of black-hole routes and BGP filtering. If we get there, then no amount of pressure on individual ISP can compromise the global routing tables. What I perceived in the previous discussion was an unwillingness to do this, because is would ban Internet wide routing of the GUPI forever. There are some who seem to be willing to use GUPI to sneak PI routing in IPv6. I believe we should really not go there, and state clearly that PI addressing will be the result of the MULTI6 work (perhaps), not an evolution of the GUPI. -- 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: GUSL proposal (very crude)
There is a sense of deja vu in all this discussion -- similar proposals of making SL more unique by somehow sticking an identifier in the 38 available bits have popped out every 2 years on the list since 1994; I have to plead guilty, since I have indeed been one of the proponents. > There is a need for three types of allocation: > - Free, automated configuration, no registration, > no external connection, almost unique. > - Free, manual or semi-automatic configuration, > no registration, Internet connection necessary > for semi-automatic configuration, unique. > - Fee-based, manual registration, unique. > Additonal properties TBD. I don't understand the intermediate category, and specifically the implementation as: > 1.2.2 Unregistered, free, unique, sequentially allocated. Unique and sequential is contradictory with unregistered. I understand that we could implement a web site that distributes sequential numbers, although it is not clear that we can run a web site that runs a strictly sequential counter efficiently; you will probably need to loosen the sequential requirement to allow for a parallel implementation. But in the absence of registration there is a big risk that poorly written implementations will get a new number each time they boot. In fact, there is also a big risk that a denial of service attack brings the system down. I would personally go for a simpler scheme: 1 bit for random/registered, and a controlled registration process to remove doubts. By the way, I would also probably reserve a /16 prefix for a special class of 32 bits identifiers, the alreday allocated IPv4 addresses. -- 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: one question...
> - Some companies may pay their ISPs to globally route their > GUPI addresses. I know that some people don't > want this to be possible, but I'm not sure why. > I agree that we should only advise this if we can > come up with an aggregable method for allocating > GUPI addresses. Margaret, You should check the evolution of the size of the DFZ tables, for example at http://bgp.potaroo.net/. From my neck of the woods, I perceive a consensus on two points: that rapid growth of the number of globally routed prefixes is not a good thing; and that the major cause of growth is "site multi-homing", which translates exactly into "some companies may pay their ISPs to globally route their (global) addresses". (Attempts at traffic engineering through clever use of routing tables is probably the other cause of table growth.) The whole point of placing restrictions on the routability of the GUPI is precisely to thwart attempts to pay your way into the routing table: whatever the amount of money on the table, the ISP cannot say yes since it cannot guarantee that other ISPs will route the GUPI. -- 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: Taking two steps back (Was: Re: one question...)
> Let's take two steps back, stop discussing possible solutions for a > moment and discuss the problem statement. I'd like it to be possible for > an enterprise to: > > - Have resources (i.e nodes or services) that are accessible > only to sub-groups within the enterprise (i.e. > departments). Example: a printer that only marketing > is allowed to use. > - Have resources that are available to the whole enterprise, > but that are not accessible outside the enterprise. > Example: An HR benefits website. > - Have resources that are available on an extranet (between a > selected group of enterprises) that are not accessible > to all other enterprises. Example: A supplier/customer > network. > - Have resources that are globally available, and be able to > send global traffic. Example: Google. > > All of these things can be achieved without site-locals, using > provider-allocated global addresses and appropriate configurations of > firewalls, ACLs, route filtering and split DNS. In theory people would be smart and would never assign any security property to an address. They would base access control on actual authentication protocols, authorizing an activity if they have enough trust in the user initiating the activity and the remote computer through which the activity is performed. I wish everybody understood that. In practice, many system administrators do assign some properties to addresses. In a large network, assigning properties to addresses translates in a large number of access control lists in which the "only marketing" or "HR benefits" restriction is translated into a set of address prefixes. Experience proves that updating these prefixes during network renumbering is a major pain. Having a stable set of prefixes that you can use internally is thus very helpful. -- 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: one question...
> > So I've been watching this debate about globally > > ~unique site locals and I don't understand how the > > end node knows whether a particular destination > > address is in scope (reachable) or not. The old > > way, it just matched it to its own scoped prefix > > and was done with it. What I've been hearing is > > some desire to be able to patch together other > > sites (extranets)... how would a node know which > > scope address to use in that case? > > in general the only way for node A to determine whether node B > is reachable is for A to send a packet to B. if A gets a reply > from B, B is reachable. if A gets an ICMP message back, B > is not reachable (for temporary or permanent reasons). if A > gets nothing back, either B is (temporarily) unreachable or > B doesn't want to answer A. > > but you'll never be able to determine this by looking at prefixes. Actually, the "Default Address Selection for IPv6" draft includes language of that nature. It would have to be amended to take into account the GUPI proposal. Something about assuming reachability of GUPI if on the same site, but not if on a remote site. And then, we would have to add policy hooks to mention "connected sites." -- 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: even one reason why provably unique SL is needed?
Pekka, You keep ignoring one of the requirements: that we be able to find out who is leaking information when "local" addresses leak through applications, or through management protocols. Random numbers don't give you that. Also, you should never underestimate how bad people and computers are at picking random numbers. And you should also never underestimate the malicious users who will deliberately pick the "wrong" value and cause trouble. There are several ways to provide global uniqueness: registration is one; reuse of an already registered number is another. Among the candidates that we could consider: * IPv4 addresses, for those who already have them: 32 bits. * Telephone numbers: we can encode 11 digits in 37 bits. * Various unique enterprise numbers. Such numbers can easily be configured offline. -- 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: "unique enough" [RE: globally unique site local addresses]
> It is actually my (weak) understanding that taking more inputs > does not actually result in more "uniqueness", at least for > random number generation. > Does anyone know how that works for hashing? This is well explained in RFC 1750, Randomness Recommendations for Security, D. Eastlake, S. Crocker, J. Schiller, December 1994. In short, you need to make sure that the various strings you are hashing provide you the desired level of entropy -- would be 38 bits in this example. -- 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]
Enforcing unreachability of site local addresses
One of the point in the discussion of the "globally unique" site local addresses has been the discussion of their usage. In particular, if the new addresses are globally unique, how do we prevent them from being globally routed and creating a mess in the global routing tables; and, on a related note, how do we make sure that they are actually local? The issue is clearly complex. There are legitimate scenarios in which two sites might want to create some kind of backdoor connection independent of any ISP connection, in a way similar to the various "extranet" scenarios that are common today; it could also be used in a merger situation. There are also illegitimate scenarios in which a powerful customer would pressure an ISP to simply advertize their globally unique /48. I believe that Bob Hinden provided the beginning of the answer when he proposed that all routers would have a default black-hole for the site local prefix. The implementation would be the following: 1) In a local site, advertise the subnet routes in the IGP, possibly a default route for the site, and a black-hole for the site local prefix. This guarantees internal connectivity to the valid subnets, and unreachability for all other sites. 2) In an extranet scenario, import in the IGP an explicit route for the "friendly" sites, and point it to the specific backdoor connecctions to these sites. This will override the blackhole. 3) At a border router, discard all BGP route that point to the site local prefix or subsets of it. 4) At a site border router or firewall, perform ingress filtering and discard all externally sourced packets in which the source address pretends to belong to the internal site. The combination of 1 and 3 presents a powerful disencentive against the "leakage of routes" risk: a powerful customer might pressure a local ISP, but that would be to no avail since the packets would be dropped by the next hop. I believe that the combination of the four rules will provide the desired locality benefits without having to resort to ambiguity as an enforcement mechanism. -- 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: "unique enough" generation
> I'm assuming that for the intents and purposes of replacing > "local" site-locals, "nearly unique" site-locals would be enough. Not quite. You should get the slides of Rob Austein presentation to the working group. We must really separate two issues, reachability and ambiguity. It is very easy to ensure that a block of address is not reachable -- any firewall can do that. But just because an address is unreachable does not mean that they could just as well be ambiguous, because these ambiguous addresses end up leaking in various places: DNS records, source of ICMP packets, next hop in BGP messages, "received" headers in mail or "via" headers in SIP, etc. In short, buggy addresses appear at places where they should not. Ambiguity causes problem, because you can never debug these problems. I realize that we have a tension between two requirements, uniqueness which imposes some form of registration, and "free use" which imply making up the addresses locally and virtually guaranteeing possible collisions. Maybe we have to embrace the dilemma, and allow for several types of identifiers, some guaranteed unique and some quasi random. But you must definitely provide unique numbers to those who are ready to wait for registration. -- 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]
globally unique site local addresses
During the WG meeting, we agreed to work on the definition of a globally unqiue site local addressing architecture, so that we can eventually deprecate site local addresses. I am listing here so far a couple of points that were made by different speakers, as an introduction to the debate: * we want to remove ambiguity, which is the root cause of many problems occuring when scoped addresses leak. * we may or may not want to prevent routing of these addresses between sites. I guess we should certainly prevent routing between non-consenting sites. * we definitely want the addresses to be provider independent, so they can survive renumbering or intermittent connectivity. * indeed, it would be desirable that the addresses be usable in sites that are not connected. * and we would definitely want the addresses to be free. One of the main point of contention regarded routing. I guess that the consensus is, "just like site local addresses." We don't want to prevent usage in connected sites, but we expect that in these sites the hosts will also have provider based addresses, and that traffic routed out of the site will use the provider addresses. Now, I guess we have to work from there. -- 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: Proposal for site-local clean-up
> Perhaps more importantly, I don't buy the argument that *any* set of > addresses should be considered trustworthy, by default or otherwise. > Addresses are simply not sufficient as an authentication mechanism. > This is not a practice that IETF standards should endorse or encourage. I certainly agree with your first point: considering a block of addresses trustworthy is silly. What site locals give you is a component of "defense in depth": if an application listen only to a local scope addresses, it will not receive any packet that come directly from the Internet. Like it or not, that is a sizeable risk reduction, even if it is indeed possible to receive packets from a compromised local host, or from a clandestine attachment to the local network. But clearly, that is not sufficient: applications shall indeed check the credentials of their remote users, not just the addresses. -- 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: Proposal for site-local clean-up
>> Ok, but it isn't clear that these two factors are of even remotely similar >> weight. Leakage is a problem that can be addressed, but there are a lot of >> things that simply will not work without stable addresses (at least not >> without a complete overhaul of many higher-level protocols). > > Agreed that stable addresses are necessary, but experience suggests that > it is very difficult to 'address' leakage of addresses. Every application > is another path by which addresses can be leaked. For that matter, so > is every mobile host. During the transition phase, a number of hosts will be using IPv6 addresses that are derived from IPv4 addresses, and will thus be just as stable as IPv4 addresses. Even if we close our eyes very hard and wish for stable addresses very strongly, global IPv6 addresses will not be all that stable, at least not during the transition phase. We need some form of provider independent addresses for the local applications, and site local are what we have. Clearly, site local are not perfect. As Keith points out, we can minimize address leakage, but we can certainly not guarantee a leakproof use of site local addresses. We can all observe that RFC 1918 do leak. I would argue that we are in a better position with IPv6 site local than with RFC 1918 IPv4 addresses. There is a standard API to determine the scope of an address, which makes the application's writer job somewhat simpler; indeed, these application writers has already to be concerned with not leaking link local addresses, so site local don't make their task much more complex. Also, IPv6 site local address include a mostly unique 64 bit node ID, which means that the consequences of leakage are not quite as bad as for IPv4: you will mostly get a failed conection, not a connection to some other random host on the remote site. The right solution could be to have provider independent non routable addresses. They would effectively be global, which would make programming simpler and would make leaks mostly harmless. However, we don't have such addresses today, so this is mostly a rhetorical argument. Also, such global addresses would require much more management. I guess we are stuck with site local for now. -- 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]
Security & draft-deering-ipv6-encap-addr-deletion-00.txt
Steve, In the WG discussion, we alluded to a security risk related to IPSEC tunnels. The risk is the following. Compare a typical VPN set-up that uses ESP: <-- outer IPv6 header -><-- inner IPv6 packet, encrypted -> ++++++++ + |||||||| | |oNAF| oSRC | oDEST | ESP header |iNAF| iSRC | iDEST | | iPAYLOAD |||||||| | ++++++++ + Now, with the compression, we would in many cases be able to "compress" the source address, resulting in: <-- outer IPv6 header -><-- inner IPv6 packet, encrypted -> +++++++ + ||||||| | |oNAF| oSRC | oDEST | ESP header |iNAF| iDEST | | iPAYLOAD ||||||| | +++++++ + The big difference between the two is the iSRC is not protected by the encryption, but recomposed after decryption by copying oSRC -- which is not protected. This would open an attack avenue for a hacker or, heavens forbids, a NAT... -- 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: draft-hinden-ipv6-host-load-sharing-00.txt
> > > An implementation MUST cycle through the router list in a round- > > > robin fashion while making sure it always returns a reachable or > > > a probably reachable router when one is available. > > > > I can see encouraging implementations to do some sort of > load sharing, > > but why does it have to be round-robin, and why MUST and not SHOULD? > > The idea probably is that if it is MUST, you can rely (up to a certain > point) on clients on actually doing load-balancing. Even if we wanted to somehow mandate load sharing, there are generally issues with mandating a round robin approach, or in fact any specific algorithm. Round robin has two drawbacks: it hypothesizes that all routers are equal, which is very often not the case, and it implies some explicit ordering of the requests, which can lead to synchronizations. The all routers equal hypothesis is fine for dumb hosts, but smart hosts can acquire a knowledge that this or that router usually performs better, which is enough to justify a "SHOULD" instead of "MUST". The way to avoid synchronization is normally randomization, i.e. pick routers in a random order rather than doing round robin. -- 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: /127 for P-t-P Considered Harmful
/127 for a P-t-P link? This must be a bug! We need a /64! Have people considered the privacy implications? The computer at the end of the link may well want to use privacy addresses. Also, there is a credible possibility that a computer is composed of multiple subsystems, each with their own IPv6 address. In the aggregatable architecture, it makes a lot of sense if "n" is in fact 64 for most links. -- 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: W.G. Last Call on "IP Version 6 Addressing Architecture"
Brian, Yes, we have in some cases to test whether the address is "global in scope" or not; such tests are mandated for example in the behavior of Shipworm routers. This points us to section 2.4 of the addressing spec, which reads: The type of an IPv6 address is identified by the high-order bits of the address, as follows: Address type Binary prefixIPv6 notation Section -- --- Unspecified 00...0 (128 bits) ::/128 2.5.2 Loopback 00...1 (128 bits) ::1/128 2.5.3 Multicast FF00::/82.7 Link-local unicast 111010 FE80::/10 2.5.6 Site-local unicast 111011 FEC0::/10 2.5.6 Global unicast (everything else) So, when I implement the test, I am going to check whether the address matches ::/127, FF00::/8, or FF80/9, and if yes recognize a non local scope. What I should specifically not do is check whether the address matches 2000::/3, and if not recognize a non local scope! In short, looking for an inexistent format prefix would drive a programming error. -- Christian Huitema > -Original Message- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] > Sent: Friday, September 07, 2001 11:49 AM > To: Erik Nordmark > Cc: Bob Hinden; [EMAIL PROTECTED] > Subject: Re: W.G. Last Call on "IP Version 6 Addressing Architecture" > > Well, I miswrote slightly - the fact is that an implementation has to > first check if the address is any of the non-global-unicast cases, and > that > involves doing a sequence of matches which involve the bits > Formerly Known as the Format Prefix (not just 3 of them of course). > I think the new text makes this harder to understand. It doesn't > change > what implementors should do. > > Feel free to ignore my comment if nobody else has the same reaction. > >Brian > > Erik Nordmark wrote: > > > > > I also think that abolishing the term "format prefix" is > obfuscation. The > > > fact is that the leading bits of an address *are* a format prefix > and > > > implementors *will* look at those bits before processing an > address. Why > > > obscure that fact? > > > > Brian, > > It is exactly this that we want to avoid - implementors thinking > that they > > need to inspect the first 3 bits of the addresses. > > There is no need to do this and we need to reduce the probability > that > > implementors hard-code any knowledge of any leading 3 bit > combinations > > since it will make it harder to use the other 15/16th of the address > space > > in the future. > > > > Erik > > 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: Any ideas about IPv6 in wireless network such as UMTS?
> -Original Message- > From: Xingang Liang [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 25, 2001 1:47 AM > To: [EMAIL PROTECTED] > Subject: Any ideas about IPv6 in wireless network such as UMTS? > > > Hi,My friends,how are you! > > I am doing some research about the benefits/challenges of > IPv6 deployment in wireless network such as UMTS and > encountered some problems: > > 1.I don't know why the IPv6 should be deployed in the > wireless network. > > 2.I don't know what is the benefits of IPv6 when implementing > in the wireless network. Check RFC 3002, "Overview of 2000 IAB Wireless Internetworking Workshop", for an answer to your 1st and 2nd questions. > 3.I don't know what challenges we can face when implementing > IPv6 in the wireless network? In a nutshell, agreeing on address allocation and mobile IPv6. > 4.What is the reason of convergence between wireless network > and Internet? Check the deployment of 802.11 networks, or the success of NTT Docomo. -- 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]
PPPoE & IPv6: packet too long?
According to RFC 2516, PPPoE, the Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a larger size than 1492. If PPPoE implementations actually negotiated an MRU size of 1492 bytes, we would not have an issue. However, many implementations of PPPoE servers only support an MTU of about 1100 bytes, i.e. less than the minimal MTU allowed by IPv6. What should we do? -- 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: W.G. Last Call on "IP Version 6 Addressing Architecture"
> >> Unassigned: > >> > >> 6/8 + 57/512 (2.5521177519070384759753095557382e+38 > >> + > 3.788299787987010237775850121799e+37 > >> of addresses) > >>This is the remaining of the address space, which > has not > >> been assigned. > > for implementers, it needs to be known that the unassigned > region is > unicast addresses, not just "unassigned". > otherwise, implemnters cannot implement the code to handle these > "future allocation" addresses. in my understanding this is the > main reason for the wording change between RFC and i-d. Second that. We have to be able to decide thinks like "address scope" and "address type", in order to implement requirements such as "addresses used in this context must be global scope unicast addresses." If we want compatibility with future assignments, that should not be done by testing for 200::/3... -- 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: refocusing: what about the flow label?
> With the current flow label semantics the routers can avoid doing > intserv > state lookup if the flow label is null. If the flow label is used for > path > distribution, the router will be searching for the intserv state for > all the > packets (assuming the router does intserv at all). So from this > point-of-view it might be better to designate a separate label type > for > intserv? That should be a question for the Intserv WG. Either they can live with the default mechanism, or they expand the effort of specifying their own solution. I have no personal preference on this subject. > What I'm aiming at is to see if a classifying router (intserv, > diffserv, or other) could be ignorant of the different flow label > types when doing the lookup based on the 3-tuple of the source > address, destination address and the 20 bit flow label. That is indeed debatable. My proposal is to treat any non-understood label as if it had been null; an alternate proposal could be to treat any non-understood label as a basic label. Again, I don't have a strong preference, we just need to pick one specification. -- 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: refocusing: what about the flow label?
> > Doing that the "normal way" (value modulo some prime) seems like it > would be > > a much too expensive operation to contemplate. Doing it by > calculating some > > kind of CRC of the 272 bits, then using however many bits of that > would be > > better, but still not blindingly cheap. > >Associative memory is your friend :-) In fact, one of the points that were made clear in the debate is that the router manufacturers will never "just trust the host", i.e. just trust that the "flow label" is sufficiently random and sufficiently unique that they could use it without looking at the addresses. Then, even if the flow was unique, we should note that even 20 bits would be two small to be practical: the birthday paradox would kick in as soon as the router processes 1,024 flows, which is not a very large number; you would need some kind of tie-breaking logic, which means that you would have at a minimum to process the source address. So, it is much safer to assume that the primary classification will be based on the address pair, and that the label is just a differentiator for packets that carry the same address pair and require specific treatment; Mike points out one possible solution; there are certainly others; hashing 256 bits of source-destination should not require an inordinate number of gates in a VLSI. -- 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]
refocusing: what about the flow label?
I hope that after three weeks of exchanges, everybody is convinced that we will not get any consensus on whether the best handling of QoS is diffserv, intserv, or maybe no QoS at all. Let's try to be practical. We have a simple problem to solve, the definition of the flow label in the IPv6 specification. I propose the following compromise: The flow label is comprised of 20 bits, divided between a four bit label type and a 16 bit label value. IPv6 sources may set the flow label type and the flow label value to label sequences of packets for which they request special handling by the IPv6 routers, such as non-default quality of service or "real-time" service; the label type defines how the label value shall be used in the production of these services. Label types may be defined in IETF standards and registered with the IANA. This specification (i.e. IPv6) defines only one label type, the basic label, whose value in binary is . Sources that do not require any specific service should set the label type to the basic label and the label value to a null value. When the label type is the basic label and the label value to a non null value, IPv6 routers are expected to treat identically all packets that carry the same source address, destination address and flow label. For example, when traffic is load balanced along several alternate paths, these packets should all sent on a single path; when classification is performed for the purpose of quality of service, these packets should all be classified in the same class. If the label type is set to the basic type, IPv6 routers SHOULD NOT rewrite or alter the flow label value. Processing of the flow label, and possibly rewriting of the label value, is specified in the IETF standard defining the label type. When a router encounters a packet with an unknown flow label type, it should treat the packet as if the label type was the basic value and the label value was the null value. Routers SHOULD NOT rewrite or alter the flow label value if the flow label type is unknown. I believe it captures most of our discussions: we get a basic label that is roughly equivalent to the label currently assumed by RSVP/Intserv; we get reserved bits for the future generations; and we get an extension mechanism that can possibly used by Diffserv, charge to them to describe exactly how they intend to use it. -- 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: a), b), c), d), or e)
I believe you are wrong. On obvious counter-example comes if the sender has no privilege with the sender's ISP, but the receiver has these privileges. In that case, the packet is marked as "priority high, traffic type X" by the sender; the sender ISP's rewrites that to "priority standard, traffic type X"; the receiver's ISP rewrites to "priority high, traffic type X." By the way, many people seem to believe that diffserv necessarily ties with monetary exchanges. That is not necessary, if for example you implement "alternative best effort" and get 2 best effort classes, one for "high throughput, low loss", and one for "low delay, possible losses." -- Christian Huitema > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 29, 2001 2:21 PM > To: Christian Huitema; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: a), b), c), d), or e) > > Christian, > > I might be wrong, but it seems that a downstream (operator) router > CANNOT > use end-to-end immutable information. If the policer in the 1st > operators > domain concludes that the customer is not paying enough for the > treatment > he's asking, the "treatment indicator" needs to be downgraded. If that > is > not allowed, the only other option would be to drop the packet > altogether. > > Jarno > > Christian Huitema wrote: > > > > There are no stupid questions. Some of the pushback is > > > > simply based on the fact that the diffserv model of QoS > > > > is inherently broken because there is no end-to-end > > > > immutable set of bits for local decisions to be based on. > > > > > > This is a very unfair comment. Diffserv is just fine in the > > > case of unencrypted traffic. It has a problem (and so does > > > intserv I suspect) with tunnel or transport mode ESP. > > > > ESP is just one of the cases in which "looking at the port > > numbers" does > > not provide sufficient information to make an informed decision. > There > > are many examples that do not involve ESP, e.g. an audio stream can > > carry different levels of hierarchical encoding on successive > > ports, an > > HTTP transaction can carry a medical transaction just as well as > > recreational content, a file transfer may be a virus update or a > virus > > propagation. At some point, the classification decision has to rely > on > > information provided by the source. > > > > In fact, there is no contradiction between the "immutable" > requirement > > that Tony is advocating and Brian's "diffserv handle" requirement. > In > > the diffserv model, the actual classification is based on the 6 > > classifier bits; there is no context that this can be mutable, since > > ISPs must be authorized to reclassify traffic. The reclassification > is > > based on information carried in the packet, part of which is the > label > > affixed by the source; making that label immutable is a good thing, > > since it prevents intermediaries from removing the > > information that can > > be used by a downstream router. > > > > -- 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: a), b), c), d), or e)
> > There are no stupid questions. Some of the pushback is > > simply based on the fact that the diffserv model of QoS > > is inherently broken because there is no end-to-end > > immutable set of bits for local decisions to be based on. > > This is a very unfair comment. Diffserv is just fine in the > case of unencrypted traffic. It has a problem (and so does > intserv I suspect) with tunnel or transport mode ESP. ESP is just one of the cases in which "looking at the port numbers" does not provide sufficient information to make an informed decision. There are many examples that do not involve ESP, e.g. an audio stream can carry different levels of hierarchical encoding on successive ports, an HTTP transaction can carry a medical transaction just as well as recreational content, a file transfer may be a virus update or a virus propagation. At some point, the classification decision has to rely on information provided by the source. In fact, there is no contradiction between the "immutable" requirement that Tony is advocating and Brian's "diffserv handle" requirement. In the diffserv model, the actual classification is based on the 6 classifier bits; there is no context that this can be mutable, since ISPs must be authorized to reclassify traffic. The reclassification is based on information carried in the packet, part of which is the label affixed by the source; making that label immutable is a good thing, since it prevents intermediaries from removing the information that can be used by a downstream router. -- 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: a), b), c), d), or e)
> > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| Pseudo-Random Value | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |1| Diffserv IPv6 Flow Label| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Could we be a bit parcimonious and reserve a couple of header bits "for further use"? We don't seem to have a level of consensus in the group that people can guarantee that either a bunch of random bits, or a diffserv flow label, are absolutely the best thing since sliced bread. Not at the same level as the payload type or payload length, in any case. It would be nice to be able to invent something like ECN in 2010... Maybe we could make it something like 4 bits of "label type" and 16 bits of label value, defining then the possibilities for "0-0", "0-random" and "1-diffserv" -- whatever that means. -- 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: (ngtrans) Joint DNSEXT & NGTRANS summary
In retrospect, I believe I made at least one mistake when writing the A6 RFC, which is going for a "full recursion" model. This triggers all kinds of "interesting" possibilities. Going for a site model would have been more appropriate: basically, one could request that the "prefix domain name" points to a set of records, allowing for exactly one level of indirection. -- 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: Higher level question about flow label
> On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote: > > I think the WG needs to decide once and for all whether the flow label > is > >a) a CATNIP or MPLS-like routing handle > > or b) a QOS hint for intserv only > > or c) a QOS hint for intserv and diffserv > > or d) a waste of bits I think that the most useful use is probably (c). Option (a) is not terribly interesting: if you want to do MPLS, just insert an MPLS header; MP in MPLS stands for multi-protocol, which means that MPLS is always going to have a "layer of indirection" for v4, v6, and whatever else the ISP wants to run on it. Option (b) really means "a set of random bits" and is not terribly useful either: it would require that the routers trusts the random generation in the hosts, which is not going to happen (the trust, I mean.) Option (c) really means "tell me something useful about the content of the packet so I can use it for classification." Suppose I place here the port number that identifies the service, e.g. 25 for mail, 80 for web, etc., plus an indication of whether this is UDP or TCP. This plus the addresses would enable some easy filtering into intserv or diffserv classifications, without requiring that the router go deep into the header chain. It would enable easy traffic statistics. It would be easy to implement for the host (pick the lowest of dest or source port.) It would work even if the packet is encrypted. We could reserve values for specific traffics, e.g. RTP-audio, RTP-video. It would work even if we use ESP. From an information theory point of view, this looks much more useful than either random bits or null values. Indeed, the bits will have to be set by the host. But then, so are the port numbers. Nothing prevent cooperating hosts from running NFS over port 80... In fact, if the router is willing to inspect the full header chain, it could rewrite the bits to a "trusted" value. Also, some hosts may not be willing to provide the information, e.g. when they actually want to hide the nature of the encrypted traffic; these hosts could use a null field, which would be classified to some default rule by the diffserv filters (you cannot have it both ways.) Count my vote for (c). -- 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: I-D ACTION:draft-hain-ipv6-pi-addr-00.txt
Tony, You allocate prefixes by combining latitude and longitude. The scheme you propose is reasonably efficient, using 44 bits to pave the earth with "squares" (in fact, trapezes) whose sides are at most 10 meter wide. This is about OK, except for the fact that an awful lot of the space is dedicated to deserts and oceans. But what happens in the rather common case of office buildings in which different organizations share different floors? -- 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]
test
- 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: RFC 2553 bind semantics harms the way to AF independence
Francis, I believe that your comments are based on a host model that does not entirely cover reality. An IP address, v4 or v6, designates an interface, not a host. A host can have many IP addresses; it can be multi-homes to several interfaces, and it can be "artificially divided" into several "sub-host", e.g. when the host is the platform for several "sites", each with its own servers for HTTP, FTP, telnet and SMTP. In a multi-homed host, processes must obviously be able to bind to a specific address. For example, if a host supports www.example1.com and www.example2.com, you definitely expect that two different mail server processes will bind to www.example1.com:25 and www.example2.com:25. Another reason to do so may be to insist that a specific service is only reachable through a specific interface. You expect to achieve the address or interface selection by binding the socket to a specific address+port combination, not just a port number. Indeed, you want to be able to support this function for IPv4 and IPv6 addresses. In a multi-homed host that uses IPv4 and IPv6, you get quite a number of combinations. I may want a socket to all interfaces and all protocols, to a specific interface and a specific protocol. I could also imagine to "all protocols on a specific interface, but there is a slippery slope here. As we start taking advantage of the large IPv6 address space, we introduce new concepts such as privacy addresses, so we loose the restriction of "one address per interface", and the correspondence between "the IPv4 address of the interface" and "the IPv6 address of the interface" becomes fuzzy. Then, there are interfaces such as 6to4 that are IPv6 only. Pretty soon, you realize that the easiest way to select an interface is to bind to a port on a fully specified address, and that such sockets will by definition be single protocol. -- Christian Huitema > -Original Message- > From: Francis Dupont [mailto:[EMAIL PROTECTED]] > Sent: Sunday, July 01, 2001 9:34 AM > To: Mauro Tortonesi > Cc: Jim Bound; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: Re: RFC 2553 bind semantics harms the way to AF independence > > In your previous mail you wrote: > >> With V6ONLY you should be able to bind 0.0.0.0, 23 and bind ::,23 one >> using AF_INET and the other AF_INET6. > >RFC2553 does not state this behaviour. > > => I disagree. > >in fact many implementations do not allow to do this. > > => fix them! > >can you explain better? let's take two sockets, an AF_INET and an >AF_INET6+V6ONLY one. can i bind them on the same port only if i >bind first to 0.0.0.0 and then to ::? or is it also correct to bind >first to :: and then to 0.0.0.0? > > => both, V6ONLY removes possible interferences between IPv6 and IPv4 > spaces. > >RFC2553 is silent about this. > > => 2553 bis is not, reread the V6ONLY spec. > > [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: RFC 2553 bind semantics harms the way to AF independence
>then why bothering to write RFC2553? if any ISV can do what he wants it >has been only a useless effort. There is a strong case to be made that the IETF should limit itself to the definition of protocols, i.e. the bits that flow on the wire, and should not be concerned with APIs. APIs are typically determined by two factors, the function that you want to provide and the environment in which you provide it. The IETF knows a lot about what function to provide, but it generally does not know all that much about the environment. Would you still use the socket API in a firmware implementation? Would it be the same in a massively parallel machine? What about a quantum computer? API definition in the IETF is always an exception, not a norm. In fact, we may observe that RFC 2553 is an informational document, not a standard track document. It was produced by the WG in a burst of enthusiasm, but it is a strange beast when in comes to process. How does one apply the "implementation that interoperate" test? How do we progress a document and drop features that were not in fact implemented? How does it apply to hardware implementations of TCP/IP? If there are not enough compliant implementations, does one obsolete the document and forget about it? On the other hand, the subject makes for volume of exchanges on the WG list, which gives us a comforting sense of liveness... -- 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: IPv6 over UDP/IPv4
> From: Robert Elz [mailto:[EMAIL PROTECTED]] > From: "Christian Huitema" <[EMAIL PROTECTED]> > > | I think we must meet the following requirements: > > If all that is to be done, then it would probably be easier to > just use TCP. That doesn't, of itself, satisfy all the requirements, > but it makes it a lot easier to handle them (eg: it pretty much handles > the two way data problem, and it allows some kind of authentication that > doesn't have to be repeated for every packet). In fact, if you really want to maximize the chances of going through "hostile territory", you probably want to use IPv6 > HTTP > TLS > TCP. And yes, I do mean "https"; using a different port would allow the network police to see you and catch you. This would get you through firewalls as well as NAT. OTOH, shipping this kind of solution will also get you "interesting" comments from network managers. Also, you may have a small problem with the packets' latencies. Seriously, I believe that most of the requirements can be met pretty easily. You need to design a protocol that starts with a formal handshake, probably similar in nature to the PPP control protocol: provide credentials in a format that is compatible with a Radius back-end. You want the handshake to be at least a three ways handshake, so has to ensure that the connection actually works. You may want to negotiate something like ESP or TLS. As Franci points out, once the connection is set and the identities have been validated, then we probably are home free -- use autoconfig if needed, use NUD, etc. -- 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: IPv6 over UDP/IPv4
The UDP tunneling scenario aims at solving the NAT crossing problem. This is fine, but we need more than just a pot number and a payload format to make this work. Since the origin of the tunnel is located behind a NAT, and possibly many, you cannot predict the port number and the IP address that it will use. Also, it is fair to assume that the tunnel will probably not be offered by the local ISP -- if this ISP wished to provide IPv6 service, it could just enable native IPv6, or possibly native tunneling. I think we must meet the following requirements: 1) There is no way to "pre-configure" the connection. The association between a given "user prefix" and a pair of natted address and port must be discovered in real-time. 2) There must be a way to verify the identity of the party requesting the tunnel, to mitigate the risk of traffic highjacking, and possibly to ensure that only authorized parties are using the service. 3) There must be some way to verify the origin of the traffic, in order to avoid denial of service attacks. 4) There must be a way to "qualify" the tunnel, and check that traffic is indeed flowing in both directions -- NAT configurations are prone to bizarre cases of failure. We should also note that IPv6 over UDP should be designed to work with all NATs, including those that use "destination specific" port mappings. The design, and the port discovery, should be focused on bilateral tunnels. -- Christian Huitema > -Original Message- > From: Francis Dupont [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 15, 2001 7:44 AM > To: [EMAIL PROTECTED] > Subject: IPv6 over UDP/IPv4 > > We know that IPv6 over UDP/IPv4 is very useful for some users. > This is very easy to do too (see the PS) but an advantage to > have a document which specifies it is we can get a standard port... > Do you believe we should write an Internet Draft about it? > > [EMAIL PROTECTED] > > PS: on FreeBSD 4.3 with Netgraph a little variation of > the /usr/share/examples/netgraph/udp.tunnel script does the job. > With if_tun (for systems without a netgraph-like facility) this takes > one page of trivial code... or nothing if the user mode PPP has both > UDP and IPv6 supports. > > 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 Minutes for IPng Interim Meeting
> > I for one believe that we should assume rapid renumbering as a feature > > of IPv6. > > great! how does it work? not broad desires, but the devilish details > please. This is a perfectly reasonable request. I believe that the correct answer is "draft the scenarios, plan the technology, demonstrate and drill." So, lets first agree on a set of scenarios. I propose the following five: Scenario 1, first connection: A site is currently isolated. The internal subnets have been numbered using "site local" addresses. The site joins the IPv6 Internet. The site managers use "Router Renumbering for IPv6" (RFC 2894) to automatically inform the internal routers that they should start advertising the new prefix. The hosts receive a router advertisement and automatically create a global address as specified in "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 2, disconnection: A site is currently connected to the Internet. The site managers plan to disconnect. This occurs in two phases, first deprecating the old prefix, then removing it. Both phases are implemented using "Router Renumbering for IPv6" (RFC 2894) and "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 3, multi-homing: A site is connected to the Internet through a single provider. The site managers set a contract with another provider, and obtain a new prefix. The site managers use "Router Renumbering for IPv6" (RFC 2894) to automatically inform the internal routers that they should start advertising the new prefix. The hosts receive a router advertisement and automatically create a second global address as specified in "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 4, removing a provider: A site is connected to the Internet through two providers. The site managers want to terminate the contract with one of these providers. This occurs in two phases, first deprecating the old prefix, then removing it. Both phases are implemented using "Router Renumbering for IPv6" (RFC 2894) and "IPv6 Stateless Address Autoconfiguration" (RFC 2462). Scenario 5, time-of-day preference: A site is connected to the Internet through two providers. These providers use different tariffs. The site managers desire that one of the providers be preferred during working hours, say from 9:00 am to 5:00 pm, and another be preferred during the rest of the day. They use "Router Renumbering for IPv6" (RFC 2894) at critical times (9:00 am, 6:00 pm) to deprecate one of the global prefixes and promote the other. The hosts receive router advertisements and heed them as specified in "IPv6 Stateless Address Autoconfiguration" (RFC 2462). You will indeed notice that these scenarios are broadly sketched. The purpose of the scenarios is indeed to discover whatever is missing in our toolbox. For example, we say nothing of "static address filters" used for QoS and security purposes; we may guess that these could be updated as a side effect of router renumbering, but we would be better offwith a real specification. More to the point, we say nothing about DNS interaction. We know the requirement, as Itojun pointed it: addresses should remain valid for as long as the TTL of the DNS record; this is addressed in the scenarios 2 and 4 through a two phase approach, first deprecate a prefix, then at the end of the TTL remove it. When it comes to creating new addresses, or deprecating them, we really have two choices. One possibility is to let the hosts use dynamic DNS updates to create or update or A6 records on the fly; another possibility is to have the site managers update the or A6 records in a reference file. We have to analyse the benefit/cost of /A6 in this context. But first, let's agree on the scenarios. Do we believe that they are realistic? Can we qualify them with a "frequency indicator," e.g. once in a life-time, once a year, once a month, once a day? Is there a big scenario that we are missing, such as maybe provider mandated renumbering, or the merging of independent sites? -- 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: Draft Minutes for IPng Interim Meeting
I for one believe that we should assume rapid renumbering as a feature of IPv6. The argument for that is the classic "fire escape" analogy. If you don't practice frequent exercises, you find one the day of the actual fire that a clutter of boxes blocks the escape. If we want to be able to renumber when needed, then we should assume that we will renumber frequently. Note however that the window of opportunity is closing fast. In the absence of a strong endorsement of A6, we will start deploying stacks that only do . Once millions of these have shipped, the issue will be moot. -- Christian Huitema > -Original Message- > From: Rob Austein [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 10, 2001 1:00 PM > To: [EMAIL PROTECTED] > Subject: Re: Draft Minutes for IPng Interim Meeting > > The basic problem is that neither the IPv6 community nor the DNS > community has reached a clear consensus on whether the extra features > of A6 over are worth the extra cost. That's not a euphemism for > "have decided that they're not", I really mean that we have people > advocating each side in each group and have not answered the question. > > So we attempted to approach the question from the angle of "what does > IPv6 need the DNS to do?" Since that question also appears to be a > potential rathole, we tried to focus on the specific areas in which A6 > would allow us to do things that can't be done with just and some > preprocessing during zone file generation. > > All the cases we thought of that would justify A6 appeared to boil > down to situations where the DNS data would have to change so fast > that it isn't practical to update the DNS that quickly (eg, rapid > renumbering, or GSE-like routing). > > So the question to the IPv6 WGs is: is IPv6 going to be doing these > things? If so, probably is not sufficient, and A6 may be the > answer. If not, may or may not be sufficient, but the new > features that A6 provides don't appear to be justified by IPv6's > requirements. > > > 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: DNS query over anycast
Part of the problem is the definition of the IPv6 anycast service. We would really want to have a service that works well for UDP as well as TCP; using an anycast address as a TCP source is problematic; in fact, even using an anycast address as an UDP source generates interesting failure cases if the query packet happens to be replicated and the response happen to come from two servers. In the short term, we could indeed just use the current IPv4 solution. In fact, you can probably weasel that into the current IPv6 framework, explaining that the address is in fact a unicast address to a "distributed interface" to a "distributed server." In the mid term, we would want to study a "real" solution. This should probably be based on some kind of "redirect" scenario: try to reach the "logical address X:X:X:X", and receive a redirect to a physical implementation; that could work with TCP as well as UDP, and be robust. -- Christian Huitema winmail.dat
RE: W.G. Last Call on "Default Address Selection for IPv6"
In fact, there is only one debatable MUST that remains -- at the end of section 4, the reference to "Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability." Rule 2 essentially states that one should pick the lowest scope that it still higher or equal than the destination. There are plenty of reasons to override that, e.g. different performance of different interfaces, etc. A SHOULD would be in order. -- Christian Huitema > -Original Message- > From: Erik Nordmark [mailto:[EMAIL PROTECTED]] > Sent: Friday, June 01, 2001 10:35 AM > To: Christian Huitema > Cc: Francis Dupont; Bob Hinden; [EMAIL PROTECTED] > Subject: RE: W.G. Last Call on "Default Address Selection for IPv6" > > Christian, > > Which MUST in the spec do you feel is inappropriate? > > There are only 6 MUST/MUST NOT and as far as I can tell > they specify constraints that effect interoperability or the protocols > actually working (e.g. not letting a link local addresses for > link A be used on as a source address for packets sent on link B). > > Erik 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: W.G. Last Call on "Default Address Selection for IPv6"
I believe that Francis has a point when it comes to must vs. should or
may. The current document is based on theoretical analysis rather than
field experience, and there is no telling what we will learn in the next
two years. As a rule, I believe that this document should never use the
clause "must", and restrict itself to the milder should. In short, if
there is any use for such a document, it should be some kind of a safe
harbor approach, as in, "if you do this, we believe you won't cause much
problems to the network, but if you know better feel free to innovate."
Note that the fledging nature of IPv6 is actually an argument for
standard track, since it will automatically trigger a revision mechanism
in 6 month to 2 years, when we have to progress the status of this
document. If we have a choice, it is not between proposed standard and
informational, but rather between proposed standard and experimental.
The latter would suit me just fine.
-- Christian Huitema
> -Original Message-
> From: Francis Dupont [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 31, 2001 5:33 PM
> To: Bob Hinden
> Cc: [EMAIL PROTECTED]
> Subject: Re: W.G. Last Call on "Default Address Selection for IPv6"
>
> I strongly object against the standard track status for this document
> because this will close the door:
> - research won't be done in order to find alternate/better solution
> - implementors will have to implement exactly the mechasnims
described
>in the document or they won't be conformant.
> The first point is a known drawback for standards. My concern is more
> the second point, I understand we have to restraint freedom for
getting
> more interoperability but in this case we are going too far!
> Some choices are still arguable, in particular in defaults, and these
> will become standards so even we believe they are not good we will be
> stuck with them.
> These concerns have already slowed down the document and can become
> critical when it will go further in the standard track. Common sense
> rules ("MUSTs") should be in a different document than some detailed
> mechanisms ("SHOULD/MAYs").
>
> Regards
>
> [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: Interim Meeting -- phone line
One more change to the meeting place call for tomorrow & Friday. Phone
number is still the same: +1 (425) 703-7600 locally and 800-421-6738.
Meeting ID has changed: 1962 NOT 1926
-Original Message-
From: Christian Huitema on behalf of Christian Huitema
Sent: Wed 5/30/2001 11:07 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc:
Subject: Interim Meeting -- phone line
We have a phone hook up to the conference room today, tomorrow &
Friday, allowing for up to 25 callers between 9am and 5pm local time.
The call number is:
1-800-421-6738 or +1 (425) 703-7600
The meeting ID is
1926
-- Christian Huitema
winmail.dat
Interim Meeting -- phone line
We have a phone hook up to the conference room today, tomorrow & Friday, allowing for up to 25 callers between 9am and 5pm local time. The call number is: 1-800-421-6738 or +1 (425) 703-7600 The meeting ID is 1926 -- Christian Huitema winmail.dat
RE: Consequences of 6to4
> |As for the other consequences of 6to4, the main one will be to raise > |expectations. 6to4 enables a user to derive an IPv6 prefix from a single > |global IPv4 address. Many solutions will be using this capability, e.g. > |providing global addresses to multiple devices, or using multiple > |addresses for different functions within a single computer. This imply > |that the "native v6" ISP will be expected to provide users with a > |prefix, not a single host address -- otherwise, the native v6 solution > |will be perceived as inferior to the existing 6to4 solution. > > Yes, and that's going to annoy the ISP no end. Uh, I don't perceive IPv6 as a tool to annoy the ISPs. ISPs are selling a product that users use to run applications and get services. ISP services compare in terms of how many applications you can run (transparency), how fast (bandwidth), how reliably, how easily and at what price. The price and the offer are mostly determined by cost and competition; the cost depends largely on the underlying technology, how easy it is to manage, how many support calls do we expect from users, etc. If we provide technology that let ISP provide better services at a reasonable cost, there will be more demand, the market will expand, etc. Everybody will be happier. -- 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]
Consequences of 6to4
> It's relevant unless you eliminate 6to4 and any other scheme that > generates portable v6 address space from v4 space. 6to4 is actually > rather interesting in that it has the potential to overtake "native" v6 > addressing (especially considering Microsoft's treatment of 6to4 as a > first-class citizen). The main advantage of 6to4 is that we can jumpstart IPv6 quickly, without requiring any tunnel configuration. We get a solution that is as easy to deploy as a NAT, but which does enable global addressing and is thus markedly superior in several important communication scenarios, e.g. peer-to-peer applications, voice and video communication, multi-player games. Note however that these scenarios do not require "portable" addresses. Most of the interesting applications come with their own rendezvous mechanism, such as dynamic registration of peers in Napster or Gnutella, SIP proxies for voice or video, lobbies for game players. Dynamic addresses are fine, as long as they are global. By the way, this means that we will get two kinds of ISPs: if an ISP can provide a home with at least one global address, then we can start enable IPv6 in the home with 6to4, and thus enable the applications. On the other hand, if an ISP only provides the home with a non-global address, e.g. a net 10 address, then a number of interesting applications will not work. I suspect that this will create some form of market pressure. > Once 6to4 has served its purpose of jump-starting IPv6 deployment and the > time comes to kill it off in favor of native aggregated addressing, the > task may be more difficult than was anticipated. If the bulk of users are > on the 6to4 side, simply severing ties to the native backbone won't do the > trick since that would hurt the native users more than the 6to4 users. It > would instead require action on the v4 backbone to block the encapsulated > 6to4 traffic, and that might raise some eyebrows. There are two answers to this question. A first one is to make the interoperation between 6to4 and "native v6" as seamless as possible; this is precisely why NGTRANS adopted the "6to4 anycast" draft, so that we could deploy 6to4 boxes that automatically find a default route to ::/0; this draft is in the RFC editor's queue, pending IANA processing. A second one is to enable the "6to4 boxes" to automatically receive an IPv6 address prefix from an ISP, and then be able to propagate that prefix to a local network, e.g. a home network. If we had that capacity, then the "box" could be programmed to not start the 6to4 operation if it can find a better, native, alternative. We can more or less do this today in a clunky way, through a mix of PPPv6 and router advertisements; we are lacking a properly engineered standard. Indeed, this standard would be particularly helpful for the ISPs who, for some reason, cannot provide global IPv4 addresses to their users. As for the other consequences of 6to4, the main one will be to raise expectations. 6to4 enables a user to derive an IPv6 prefix from a single global IPv4 address. Many solutions will be using this capability, e.g. providing global addresses to multiple devices, or using multiple addresses for different functions within a single computer. This imply that the "native v6" ISP will be expected to provide users with a prefix, not a single host address -- otherwise, the native v6 solution will be perceived as inferior to the existing 6to4 solution. -- 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: AAAA/A6 thing
> this part i don't really understand. if we advocate "A6 0 <128bit>" > there will be resolver implementation that does not chase A6 chains > at all (like for cellphones or whatever). if there's no need, > there'll be no code. then, there will be no possibility for "A6 > ". so I don't really see > benefit > of "A6 0 <128bit>" than "". I think we have to delineate the various motivation and arguments: we want A6 to facilitate site renumbering and site multi-homing, while reducing the rate of DNS update; we also want to avoid harmful effects on the DNS resolution. The motivation for A6 is still valid; no new argument there, I believe it will be a great tool for network managers. There have been two questions on its use, the linkage with the address allocation and the depth of the hierarchy. The short answer to address allocation is router advertisement; the short answer to the depth of the hierarchy is that a depth of 1 is probably adequate to show significant benefits. The motivation for using "A6 0 <128bit>" is the use of A6 during the name resolution process, especially at the top level. We don't want root servers spending their time chasing A6 chains, and we also don't want the extra-load on root servers that could be caused by clients chasing A6 chains. This means that the address records of name servers will have to be explicitly updated when a site is renumbered. I believe that this is a reasonable compromise; without A6 one would have to update all the records; with the initial design we aimed at updating exactly one record per site; with the compromise one would update a few records only. We definitely need to gather operational experience. For example, an assumption in the design of A6 is that the higher level of the hierarchy will be very likely to be cached; whether this is true or false is easy to measure after a modicum of deployment. Another assumption is that the nodes can automatically update their addresses, and that the update process can be synchronized with the DNS updates; this can indeed also be tested. And, once we are done testing, we should document the results. Note that RFC 2874 packs together the use of A6 for name to IPv6 address resolution, and the use of binary labels and DNAME for the IPv6 address to name translation. When we conduct the evaluation, it may be useful to separate the three points: A6, discussed above, DNAME, which has its own set of benefits and issues, and binary labels, which is clearly an extension to the core DNS name resolution mechanism. -- 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]
Addresses and BGP (was RE: was a6/aaaa - RA/ND & exchanges)
> BGP is bound between two IP addresses. When the IP addresses change > the BGP peering is lost. This is a valid point, which has already been discussed many times on the list, but is not discussed or even alluded to in RFC 2283. The solution in IGPs is to use link-local addresses for exchanging IGP packets; this means that the "peering" in RIP, OSPF or IS-IS will survive renumbering. This solution is not entirely applicable to BGP. However, we can probably use a combination of the following: 1) Use of link local addresses when BGP peers are directly connected. 2) Use of site-local addresses when BGP peers belong to the same site. 3) Use of mobile-IP solutions so that TCP survives renumbering. 4) Use of IPv4 addresses in multi-protocol environments. Each of these solutions is partial, and requires work, e.g. discovery that peers are on the same link, or in the same site. I would argue that this type of work is typical of the implementation phase that we are entering, and should be conducted by pragmatists (the IDR working group) rather than explorers (IPNG). -- 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: Source addresses, DDoS prevention and ingress filtering
I am well aware of the threat model. I still believe that we have to find a solution that does not "cut our nose to cure the cold." I have specifically discussed how the attack can be fought by other means, and how the attacker can in fact move from "spray" to other disguises and still continue causing the problem. We have to find a solution that does not prohibit mobile IP or multihoming. -- Christian Huitema > -Original Message- > From: Edward Vielmetti [mailto:[EMAIL PROTECTED]] > > Christian, > > The specific threat model is a compromised host being directed under > remote control to send a spray of packets with randomly forged source > addresses to a victim host far away. Intelligently throwing your local > equivalent of "ip verify unicast reverse-path" as a check in at logical > choke points on the network will *in actual practice* drop a whole lot of > traffic that should be dropped. This has important implications for > network operators. > > This is not a security or confidentiality problem, and thus IPSEC is > irrelevant. It is a network integrity problem. > > Ed > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > I am not sure it is such a good idea. > > > > From a security stand point, it is very weak. You are trusting that some > > third party, at the other end of the network, will do the right thing. > > What happens if the "first hop" is compromised? And, by the way, what > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > backbone in the same home? If you want any form of security, you really > > have to build it yourself, e.g. by using IPSEC. The only form of source > > address control that has a prayer of working is local, i.e. refuse to > > accept inbound packets in your domain that pretend to already come from > > an inside address. > > > > It is also very weak from a routing stand point. Internet routing is > > anything but symmetric. The exit path from a domain depends only on the > > destination address, not the source address; insisting on strict control > > of the source address basically breaks multi-homing. It also breaks > > several forms of mobility... > > > > > > > -Original Message- > > > From: Edward Vielmetti [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > To: Glenn Morrow > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]'; 'ietf- > > > [EMAIL PROTECTED]' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > And you're going to mandate source filtering on the first hop across > > the > > > entire internet, how? It's a great idea and a best common practice > > but > > > not something that can be set by fiat. > > > > > > Ed > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > Then again if source filtering is mandated on the first hop this > > might > > > > eliminate the need to do filtering on other hops and this would > > > eliminate > > > > the need to do subnet translation or tunneling by either the MN or > > the > > > MR. > > > > > > > > -Original Message- > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > To: 'Michael Thomas' > > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]'; > > > > '[EMAIL PROTECTED]' > > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > > > > Oh, I see what you were concerned about. It seems to me that an MR > > will > > > have > > > > to tunnel or subnet translate unless it is on it's home subnet. > > > > > > > > -Original Message- > > > > From: Michael Thomas [mailto:[EMAIL PROTECTED]] > > > > Sent: Wednesday, April 18, 2001 9:49 AM > > > > To: Morrow, Glenn [RICH2:C330:EXCH] > > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]'; > > > > '[EMAIL PROTECTED]' > > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > > > > > > > Glenn Morrow writes: > > > > > If the node behind the MR obtained its home address from the the > > > mobile > > > > > router's subnet, then the MN will use this as t
RE: Source addresses, DDoS prevention and ingress filtering
I believe that the source address should be defined as "the address at which the source would like to receive replies to this message." In the case of a mobile host, there is value in getting replies either at your transient address or at the permanent address -- it basically depends on the circumstance, just like multi-homing, and things would be simpler if both were allowed. Mobile networks could also be thought off as multi-homed networks. The mobile router could in theory advertise two prefixes, one based on a "permanent" connection maintain via some tunneling mechanism and one based on the "transient" connection. Indeed, this can also be thought off as an exercise in fast network renumbering. Say a car is traveling at 180 km/h on a freeway, and a cell is 1 km wide -- it stays in any given cell for 20 seconds; you may have to renumber the network every 20 seconds. That seems a more interesting problem to solve than source address filtering, and I would in fact rather not make it even more complex by throwing in mandatory source address filtering... -- Christian Huitema > -Original Message- > From: Michael Thomas [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 20, 2001 8:53 AM > To: Christian Huitema > Cc: Edward Vielmetti; [EMAIL PROTECTED]; ietf- > [EMAIL PROTECTED] > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > Christian, > > So what is your opinion of using the topologically > "incorrect" IP address as the source when, say, a > mobile node is away from home? It is still, after > all, return routable via its home address, so it's > not completely bogus on its face. In fact, it's no > different than the multihomed case. However, right > now as currently constituted in mobileipv6 two > things will be extremely problematic: > > 1) The stationary host behind a mobile router I brought >up before (no way to know what is "correct") > > 2) RSVP reservations upon change of CoA will need >to create a completely new reservation since >the filterspec must change. If the classifier >used the home address, the reservation could >converge locally which would be beneficial. > > There may well be other things which break because > of the expectation of a fixed source address. > > Mike > > Christian Huitema writes: > > Ed, > > > > I have seen over the past years many knee-jerk reactions to attacks > that > > essentially followed the model you are describing. An example is to cut > > ICMP because it is used in some attacks; the proposal to "verify > unicast > > reverse-path" is another. The problem is that a number of these > defenses > > amount to cutting your nose in order to cure the common cold. For > > example, cutting ICMP also suppresses efficient path MTU discovery; > > random reverse path verification kills multi-homing and makes mobility > > much harder. This is compelled by the evolutionary nature of the > > attacks: many of the ICMP attacks can be replicated over UDP, and thus > > you find sites cutting UDP as well -- and here goes voice over IP; in > > fact, I could also mount attacks by sending TCP packets outside the > > context of connections -- think of the consequences of various router > > protections for that... > > > > The "verify unicast" defense looks good on paper, but if you analyze > it, > > it requires quasi universal deployment to make a difference. This is > not > > simpler than deploying protection against forged addresses in the > > potential targets, mostly large web servers. In fact, the number of > > targets is probably lower than the number of "ingress routers" that > > would have to be upgraded. But then, there are three important > > differences. > > > > First, modern servers actually include protection against the forged > > address attacks that you mention -- proper handling of TCP context > > creation and verification of the plausibility of sequence numbers > > provide a first line of defense; SSL or IPSEC provide further > protection > > for critical systems. Routers don't include such protections today; > they > > would require modification to routing protocols to describe the > > authorized source address in parallel to the allowed destinations, > > possibly additional fast-path hardware, and certainly an increased > > management load. > > > > Second, the protection only works if it is implemented everywhere, and > > is in any case partial. As long as I cannot be sure that all Internet > > routers perform the filter
RE: Source addresses, DDoS prevention and ingress filtering
Ed, I have seen over the past years many knee-jerk reactions to attacks that essentially followed the model you are describing. An example is to cut ICMP because it is used in some attacks; the proposal to "verify unicast reverse-path" is another. The problem is that a number of these defenses amount to cutting your nose in order to cure the common cold. For example, cutting ICMP also suppresses efficient path MTU discovery; random reverse path verification kills multi-homing and makes mobility much harder. This is compelled by the evolutionary nature of the attacks: many of the ICMP attacks can be replicated over UDP, and thus you find sites cutting UDP as well -- and here goes voice over IP; in fact, I could also mount attacks by sending TCP packets outside the context of connections -- think of the consequences of various router protections for that... The "verify unicast" defense looks good on paper, but if you analyze it, it requires quasi universal deployment to make a difference. This is not simpler than deploying protection against forged addresses in the potential targets, mostly large web servers. In fact, the number of targets is probably lower than the number of "ingress routers" that would have to be upgraded. But then, there are three important differences. First, modern servers actually include protection against the forged address attacks that you mention -- proper handling of TCP context creation and verification of the plausibility of sequence numbers provide a first line of defense; SSL or IPSEC provide further protection for critical systems. Routers don't include such protections today; they would require modification to routing protocols to describe the authorized source address in parallel to the allowed destinations, possibly additional fast-path hardware, and certainly an increased management load. Second, the protection only works if it is implemented everywhere, and is in any case partial. As long as I cannot be sure that all Internet routers perform the filtering, I still have to implement adequate server side protections. If the router can be hacked, the protection is obviously ineffective. If the egress filtering operates on broad ranges, say a university network, the hacker can stop using random addresses, and instead pretend that all packets come from a single machine, e.g. the university's web site. Third, and most important, the network based defense places the defense burden at the wrong side of the problem. The local network is not really suffering from the attack; its administrators have only minor incentives to fix it. The one who is suffering is a remote server; there, you have a lot of incentives to fix the problem, fix the TCP stack, deploy IPSEC. All in all, I wish we would not cut the node of our face. As servers get hardened, the mode of attack will change. We don't want to maim the network today to protect against an attack that will not be in much use tomorrow. -- Christian Huitema > -Original Message- > From: Edward Vielmetti [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 19, 2001 9:24 PM > To: Christian Huitema > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Christian, > > The specific threat model is a compromised host being directed under > remote control to send a spray of packets with randomly forged source > addresses to a victim host far away. Intelligently throwing your local > equivalent of "ip verify unicast reverse-path" as a check in at logical > choke points on the network will *in actual practice* drop a whole lot of > traffic that should be dropped. This has important implications for > network operators. > > This is not a security or confidentiality problem, and thus IPSEC is > irrelevant. It is a network integrity problem. > > Ed > > On Thu, 19 Apr 2001, Christian Huitema wrote: > > > I am not sure it is such a good idea. > > > > >From a security stand point, it is very weak. You are trusting that > some > > third party, at the other end of the network, will do the right thing. > > What happens if the "first hop" is compromised? And, by the way, what > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > backbone in the same home? If you want any form of security, you really > > have to build it yourself, e.g. by using IPSEC. The only form of source > > address control that has a prayer of working is local, i.e. refuse to > > accept inbound packets in your domain that pretend to already come from > > an inside address. > > > > It is also very weak from a routing stand point. Internet routing is > > anything but symmetric. The exit path from a domain
RE: Source addresses, DDoS prevention and ingress filtering
No, I am not referring to AAA solutions. I am referring to server side defenses. These defenses are effective against most DoS attacks. They may not be effective against a complete saturation attack that floods the server's access link, but I doubt that source address verification would be the solution to that one; after all, activists can swamp a phone bank today without hiding their calling numbers. Replicated server at a number of diverse location is probably more effective than source address verification. By the way, most "server flooding" today is caused by "flash-crowd" phenomena with plain bona-fide clients. -- Christian Huitema > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner- > [EMAIL PROTECTED]] On Behalf Of Thomas Eklund > Sent: Friday, April 20, 2001 4:26 AM > To: Christian Huitema; 'Edward Vielmetti'; 'Glenn Morrow' > Cc: 'Michael Thomas'; '[EMAIL PROTECTED]'; 'ietf- > [EMAIL PROTECTED]' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > Hi Christian, > I hope you not referring to the AAAv6 ideas? Because that is just a way > to do access control and possibly combine it with the packet filters that > in most cases already sit in the router. It tells nothing about mandating > it everywhere - this is of course up to the service provider/enterprise to > use, but in the mobile systems there is a demand for AAA and this AAA > draft could be a good start. And it does not break multihoming, mobility! > > Of course you can still use end-to end IPsec if you want that and at the > same time enforce authentication and authorazation towards the AAA server > and if the authentication suceeds, and then the router could update the > packet filter with the "authenticated" host's IP address (which could be > the CoA). > > -- thomas > > > -Original Message- > > From: Christian Huitema [mailto:[EMAIL PROTECTED]] > > Sent: den 20 april 2001 01:11 > > To: Edward Vielmetti; Glenn Morrow > > Cc: Michael Thomas; Thomas Eklund; [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > I am not sure it is such a good idea. > > > > From a security stand point, it is very weak. You are > > trusting that some > > third party, at the other end of the network, will do the right thing. > > What happens if the "first hop" is compromised? And, by the way, what > > exactly is the first hop? The wireless LAN in my home? The Ethernet > > backbone in the same home? If you want any form of security, > > you really > > have to build it yourself, e.g. by using IPSEC. The only form > > of source > > address control that has a prayer of working is local, i.e. refuse to > > accept inbound packets in your domain that pretend to already > > come from > > an inside address. > > > > It is also very weak from a routing stand point. Internet routing is > > anything but symmetric. The exit path from a domain depends > > only on the > > destination address, not the source address; insisting on > > strict control > > of the source address basically breaks multi-homing. It also breaks > > several forms of mobility... > > > > > > > -Original Message- > > > From: Edward Vielmetti [mailto:[EMAIL PROTECTED]] > > > Sent: Wednesday, April 18, 2001 10:41 AM > > > To: Glenn Morrow > > > Cc: Michael Thomas; Thomas Eklund; > > '[EMAIL PROTECTED]'; 'ietf- > > > [EMAIL PROTECTED]' > > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > And you're going to mandate source filtering on the first hop across > > the > > > entire internet, how? It's a great idea and a best common practice > > but > > > not something that can be set by fiat. > > > > > > Ed > > > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > > > > > Then again if source filtering is mandated on the first hop this > > might > > > > eliminate the need to do filtering on other hops and this would > > > eliminate > > > > the need to do subnet translation or tunneling by either the MN or > > the > > > MR. > > > > > > > > -Original Message- > > > > From: Morrow, Glenn [RICH2:C330:EXCH] > > > > Sent: Wednesday, April 18, 2001 11:56 AM > > > > To: 'Michael Thomas' > > > > Cc: Michael Thomas; Thomas Eklund; &
RE: Source addresses, DDoS prevention and ingress filtering
I am not sure it is such a good idea. >From a security stand point, it is very weak. You are trusting that some third party, at the other end of the network, will do the right thing. What happens if the "first hop" is compromised? And, by the way, what exactly is the first hop? The wireless LAN in my home? The Ethernet backbone in the same home? If you want any form of security, you really have to build it yourself, e.g. by using IPSEC. The only form of source address control that has a prayer of working is local, i.e. refuse to accept inbound packets in your domain that pretend to already come from an inside address. It is also very weak from a routing stand point. Internet routing is anything but symmetric. The exit path from a domain depends only on the destination address, not the source address; insisting on strict control of the source address basically breaks multi-homing. It also breaks several forms of mobility... > -Original Message- > From: Edward Vielmetti [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, April 18, 2001 10:41 AM > To: Glenn Morrow > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]'; 'ietf- > [EMAIL PROTECTED]' > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > And you're going to mandate source filtering on the first hop across the > entire internet, how? It's a great idea and a best common practice but > not something that can be set by fiat. > > Ed > > On Wed, 18 Apr 2001, Glenn Morrow wrote: > > > Then again if source filtering is mandated on the first hop this might > > eliminate the need to do filtering on other hops and this would > eliminate > > the need to do subnet translation or tunneling by either the MN or the > MR. > > > > -Original Message- > > From: Morrow, Glenn [RICH2:C330:EXCH] > > Sent: Wednesday, April 18, 2001 11:56 AM > > To: 'Michael Thomas' > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]'; > > '[EMAIL PROTECTED]' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Oh, I see what you were concerned about. It seems to me that an MR will > have > > to tunnel or subnet translate unless it is on it's home subnet. > > > > -Original Message- > > From: Michael Thomas [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 18, 2001 9:49 AM > > To: Morrow, Glenn [RICH2:C330:EXCH] > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]'; > > '[EMAIL PROTECTED]' > > Subject: RE: Source addresses, DDoS prevention and ingress filtering > > > > > > Glenn Morrow writes: > > > If the node behind the MR obtained its home address from the the > mobile > > > router's subnet, then the MN will use this as the source i.e. the > MN's > > home > > > subnet is the MR's subnet. > > > >Right, but when the MR's upstream router does an > >RPF check... it will drop the SN's packets. > > > > > Either way (tunneling or subnet translation), the topological > correctness > > is > > > still maintained. > > > >Well, that's sort of the problem. The SN doesn't > >know that it's putting topologically incorrect > >source address in the IP header. > > > > Mike > > > > > > 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: I-D ACTION:draft-francis-ipngwg-site-def-00.txt
> Tell me a good reason why we couldn't run the whole of IBM world-wide > as a single site-local scope, if we wanted to? Well, one good reason: you probably need more than 16 bits for numbering your subnets. 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: an unplanned benefit of IPv6
> From: Niall Richard Murphy [mailto:[EMAIL PROTECTED]] > On Fri, Mar 30, 2001 at 08:55:15PM +1000, Robert Elz wrote: > > > | An unplanned deficit of IPv6: operating without DNS will be much, > much > > | harder. (Particularly if you can't type ":" quickly) > > > That wasn't unplanned, and isn't a defecit - ridding the world of the > > use of literal IP addresses is one of the things needed to make > > renumbering conceivable (if not by itself make it easy). > > Perhaps I was exaggerating for the sake of effect :-) > > I feel there will still be a need to type IPv6 addresses in some > circumstance no matter what, unfortunately... We should not equate "operating without the DNS" and "typing addresses by hand." NAPSTER or Gnutella operate without the DNS; SIP only requires DNS entries for the proxies. These systems just exchange addresses as part of their normal operation. -- 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: what is a site???
Steve, May I observe that the definition of a site in the "Scoped Address Architecture" draft contains a loophole? The draft says that "A personal residence may be treated as ... a part of a site (for example, when the residence obtains Internet access via an employer's or school's site)." This is in fact the classic definition of a "corporate" network, i.e. all the systems that are hidden behind the corporate firewall(s). From a networking point of view, there is not much difference between an employee's home, a remote office, or even the laptop of a traveling employee: once there are brought "behind the firewall" through some kind of VPN tunnel, they effectively become part of the "site." So far, I have found two important attributes of "IPv6 sites." The first one is the address stability: site addresses are stable, even if the site's external prefixes change; indeed, they are only subject to renumbering if two sites are merging. The second one is the "border police": site local packets are not supposed to leave the site, nor to originate outside the site; this provides a very rough form of access control, which may be adequate for some inexpensive devices or services. (Yes, I know perfectly well that this is weak -- at least as weak as firewalls.) I believe that most practical network manager will equate a site with a corporate network, with the practical exception of large corporations that will probably have to split their network into multiple sites, e.g. one site per campus. Or, to put it differently, the site will be a subset of the corporate network that enjoys its own independent connections to the Internet. By the way, it is a bad idea to swallow an employee's home network into a corporate site, as indicated in the addressing example. You definitely don't want the employee's teen-age children to roam your network... -- 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]
Sites with multiple border routers (not just 6to4)
This conversation originated in Sigtran, but this is really about the IPv6 routing architecture, so I bring it to IPNGWG. The initial context was the handling of a site with multiple "6to4" routers. > From: Vladislav Yasevich [mailto:[EMAIL PROTECTED]] >... > However, I still don't see a need for a special address for > 6to4 routers. The DSTM mechanism can provide the TEP and > it might as well provide the 6to4 address of the router (not > any speciall address). If there is a need, this need is independent of 6to4. It relates to "egress control" and v6 multi-homing. Suppose that a site is multi-homed. Each station gets several IPv6 addresses. For a given TCP connection, it picks one of them as source addresses. As packets are sent, the egress router is chosen as a function of the destination address, independent of the source address. This means that we can see packets flowing through ISP-A, using a source address allocated by ISP-B. The only problem with that is, what happens if ISP-A, in the name of protection against source-address spoofing, rejects these packets? -- Christian Huitema > May be DSTM might be extended to privide multiple TEPs and > let the implementation choose one (or cycle through them)? > Just a thought. This way we don't have to reserve a speciall > address. > > -vlad > > George Tsirtsis wrote: > > > > -Original Message- > > From: Christian Huitema [mailto:[EMAIL PROTECTED]] > > Sent: Friday, March 23, 2001 10:50 AM > > To: [EMAIL PROTECTED] > > Cc: Vladislav Yasevich; George Tsirtsis; NGTRANS List > > Subject: RE: (ngtrans) Sites with multiple 6to4 border routers > > > > > >> I believe that's what Brian Carpenter, Tony Hain, and Dave Thaler > > were > > > >> saying the meeting. You have to use a globaly IPv4 address to > > > >> create a 6to4 prefix. I don't beleave you can assign the same IPv4 > > > >> address to 2 independent devices... > > > >Uh? There is nothing impossible there. Suppose that we have a > > > >multi-homed site that connects to the Internet through multiple > > routers, > > > >both of which advertise the same IPv4 prefix, say 123.123.1/23. > > > > > > i guess you are talking about different thing from Vladislav > > said: > > > > > > >/---\ /-- > > > >| | +-+ | > > > >| +-+A+---+ > > > >| | +-+ | > > > >| Site | | Internet > > > >| | +-+ | > > > >| +-+B+---+ > > > >| | +-+ | > > > >\---/ \- > > > > No. When I say that "It is quite natural to reserve a single IPv4 > > address for the 6to4 routing service", I mean that A and B both use > > 2002::::/48; both A and B use x.x.x.x. They advertise different > > addresses in the IPv6 cloud; they advertise the same IPv4 prefix (say > > x.x.x/24) to the Internet; the routing of outward bound packets is > > determined by IPv6 routing inside the site, e.g. RIPng; the routing of > > packets from the Internet is determined by Internet routing protocols > > (e.g. BGP). > > > > GT> Indeed! The requirement for 2 or more 6to4 gates to be able to use > the > > same 6to4 prefix is that they advertise the same ipv4 prefix in the IPv4 > > Internet. Up to now it has been assumed that they only advertise a > single > > IPv4 address but this is clearly not necessary. > > > > GT> In this case, mechanisms that require outgoing and incoming paths to > be > > using the same 6to4 gate could make use of Alain's 6to4 designated > address. > > > > George 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: DDoS Work
> From: Steven M. Bellovin [mailto:[EMAIL PROTECTED]] > In message <[EMAIL PROTECTED]>, Jari Arkko writes: > > > >* In the Internet Area, there is the itrace WG which is > > specifically chartered for looking into DoS, but is > > looking only at a particular solution. Is this > > solution sufficient for all DoS issues? We're not sure > > but at least some of the individual DoS concerns such > > as attacking address autoconfiguration don't really > > fall on the area that i-trace can deal with. > > Without addressing your general question, IESG policy is that working > groups should be very carefully focused. A hypothetical "Fix DDoS Working > Group" would probably not meet that test -- there are no concrete > deliverables. I would think that a study of mechanisms to trace the actual source of Internet packets would pass the charter test. After all, there have been several proposals to do this by letting the routers mark bits in packets, using a probabilistic algorithm. This seem to fall in the single problem / existing proposed solution / concrete deliverable category. Indeed, we can also debate whether source tracing is useful... -- 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: Near-Unique Site-Local Identifier draft
You wrote: The probability of a duplicate assignment somewhere is N^2/2^38... which is not quite correct. The probability of at least one duplicate out of N assignments out of a space of size X is P = 1 - product(1..N)(1-(i-1)/X) Which is a bit hard to compute, and certainly does not result in N^2/X. Using a log approximation, you get Log (1-P) = sigma(1..N) log (1 - (i-1)/X) = sigma(1..N)(-(i-1)/X) + 0(N^3/X^2) Thus (1-P) ~= e^-(N.N-1/2.X) ~= e^-(N^2/2.X) P ~= 1 - e^-(N^2/2.X) if N^3 << X^2 I would suggest you correct your phrase to be a bit less assertive, something like "The probability of a duplicate assignment somewhere becomes significant is N^2 becomes close to 2^38" -- or just mention the birthday paradox. > -Original Message- > From: Paul Francis [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 26, 2001 10:41 AM > To: [EMAIL PROTECTED] > Subject: Near-Unique Site-Local Identifier draft > > > > I've posted a draft on assigning random site-local > identifiers at > http://www.aciri.org/francis/draft-francis-ipngwg-unique-site- > local-00.txt. > > This was submitted in time to make the Minn. ID deadline. > > Thanks, > > PF > > Abstract > >For many or most sites, site-local addresses are used for packets >between nodes within the site. The fact that site-local addresses >are not globally unique makes their usage and administration more >difficult than they would be if there were globally unique (or >nearly globally unique). For instance, before two sites can be >merged, one of them has to be renumbered. The meaning of > site-local >addresses becomes ambiguous when they are taken out of the > immediate >context of the IPv6 layer, for instance when they are conveyed in >email or stored in text files. > >All other things being equal, it would be preferable if the prefix >of addresses with site-local scope were as globally unique as >possible. This draft expands the format of the site-local address >to allow them to be near-unique. It does not, however, change the >definition or usage of the site-local address. This draft > describes >the format and assignment method of near-unique site-local > prefixes. >It also outlines some usage scenarios. > > > > > 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: Wade through the archives (was Re: another renumbering question)
The discussions always ended up on the same kind of conclusion: in theory it is a fine idea, but we would have to change existing implementation, and besides it is not easy to allocate unique numbers. There are basically four ways to allocate random numbers, and none of them is particularly attractive: 1) Picking numbers at random is easy, but you need a good random generator, and besides you hit the birthday paradox with 2^^19 entries, i.e. less than a million. There are way more than 1 million potential sites. 2) Deriving numbers from other pre-established registries is tempting, but there are not very many suitable pre-existing registries. IEEE-802 numbers are too large too fit; IPv4 addresses have the right size but not the right stability. 3) Starting a new registry looks simple on paper, but the practical problem are not so small -- for example, decide who will be king; find the right balance between automation and reliability; etc. 4) Combining random allocation with duplicate detection would go past the birthday paradox, but is almost impossible to conduct at the scale of the Internet... Now, if you can change that... -- Christian Huitema > -Original Message- > From: Paul Francis [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 19, 2001 2:36 PM > To: [EMAIL PROTECTED] > Subject: Wade through the archives (was Re: another > renumbering question) > > > > I took Steve up on his suggestion of looking through the > archives on this topic. > > With some effort I found three threads, all initiated by > Christian, in May '97, Dec '97, and Nov '99. I saved the > relevent messages...you can find them at > http://www.aciri.org/francis/IPv6> _site_id_threads.txt if you > are so inclined. This is > probably not exhaustive, so if anyone can point me to other > threads that would be helpful. > > I didn't see any major ideas in the previous threads that > weren't in the latest thread. > > A problem I found when looking over the threads is that a > complete picture of what a site ID would be and how it would > work was never generated, with the end result that different > people were talking about different things and to some extent > talking past each other. > > Having read the arguments, I still believe that there is > something to be said for the site-ID notion. The site-ID > would be for sites that want to have their own number space > for internal communications, with reasonable assurance that > nobody else is using the same space. > > The site-ID would not supplant the use of site-locals by > other sites who wanted to use them. Site-locals would remain > as defined. > > A site-ID would also not by itself identify what is and is > not in a given "site". In other words, one couldn't take two > addresses with site-IDs and, in the absense of any other > information (DNS entries or routing tables) say definitively > whether they could or could not reach each other using the > site-ID addresses. > > I'm inclined to write a draft specifying this so that we can > have a focused and consistent (and dare I say difinitive?) > discussion about it. Is there anyone out there who in > principle likes the idea of site-IDs and would care to work > with me on this? > > Thanks, > > PF > > > > > 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: The case against naïve anti-poison (was A6 and DNAME)
May I observe that most of the issues Dan are rising result from a specific approach to anti-poison, which is to rely strictly on the name hierarchy? I don't know who decided on that approach, but it clearly has the consequence of breaking existing practice, such as name servers located in another domain. That existing practice had been going on for quite a long time -- back in 1988, many of the name servers for "inria.fr" were located in ".edu". There is no mention anywhere that name server have to belong to the same hierarchy as the served domain. So, instead of asking everybody on earth to revise their delegation, it is probably avisable to make the anti-poison code a little bit smarter. Now, this is probably a subject for the DNS group, not IPNG. -- 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: The case against A6 and DNAME
I think we are hearing the same argument over and over again, so let's repeat the other side of the story: 1) Perl script don't help you if you must compute RSA signatures for 10,000 records -- or 10 millions. Having to sign one record instead of 10,000, on the other hand, is very beneficial. 2) If your site has 4 prefixes and 10,000 hosts, then A6 allows you to have four times less DNS records to handle. 3) With A6, you can exercize "site redirection" by publishing short lived A6 records for your site, while leaving the host and server records unchanged. The argument in the page is essentially an argument against dependency loops. The dependency loop occurs when one needs to contact a nameserver in order to get the address of that same nameserver. The problem is aggravated by "anti-poison" protections that essentially prevent serving cached records from domains for which the local server is not authoritative. May I observe that if "zone administrators (could) write trivial perl scripts", then they could just has well write a trivial perl script that checks for dependency loops? In any case, it is fairly easy to write reasonable guidelines on how to use the technology without creating loops -- the AOL example is a great way to explain what to do and what not to do. As for deprecating or otherwise removing standards, we have a clear IETF process. A standard progresses if it is implemented and used, and if we can demonstrate successful inter-operation between independent implementations. Let's just follow the process... -- 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: A6 benefits?
The motivation for A6 is the key database paradigm that atomic
information (e.g. a site prefix) should be stored exactly once. This has
major consequences on ease of update, as well as caching. The ease of
update argument is clear: it is simpler to update one record for a large
site than to update all records for all nodes in the site; this is
particularly true when the use of DNS security increases wildly the cost
of any given update. The caching argument is also a natural consequence
of the "atomic information" property: each component of the information
can be given an appropriate TTL, which means that information that does
not change, such as the lower bits of a node's address, can be stored
with a longer TTL than the site's prefix. The DNS is basically a
distributed database; database theory applies; storing atomic
information exactly once is a basic tenet of database theory; the A6
design is a direct consequence of the theory.
Jim, Randy and some other have made the argument that A6 would increase
the load on the DNS, by requiring several transaction for any given
exchange. This type of argument, however, does not take caching into
account. Prefixes are common to several nodes; the probability that a
prefix information will be cached increases for prefixes that are closer
to the root. If I am looking for the address of "node.example.com", and
I am returned an A6 that contains the node identifier and a reference to
"site-prefix.example.com", there are some serious chances that the A6
record for "site-prefix" is already present in my local cache. This is
specially true if the requesting node is itself a member of the
example.com domain.
We did in fact have this discussion in depth 2 years ago, when we
submitted the draft to the working group. The arguments on each side of
the issue have not changed. Usage examples showed that the DNS load
would be lessened, not increased, if we did caching right, and that the
total amount of information required to encode the addressing data for a
site would be lessened, not increased, in the case of multi-homed site.
In short, the A6 design trades off some additional design complexity for
a lesser management load and a lesser use of DNS resource when either
renumbering or multi-homing are frequent.
-- Christian Huitema
> -Original Message-
> From: Ian Jackson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 24, 2001 4:46 PM
> To: [EMAIL PROTECTED]
> Subject: Re: A6 benefits?
>
>
> Steven M. Bellovin writes ("Re: A6 benefits? "):
> > In message <[EMAIL PROTECTED]>, "D. J.
> Bernstein" writes:
> > >Is there some other claimed benefit of A6?
> >
> > Apart from not wanting more polling, the idea is to
> facilitate rapid
> > renumbering.
>
> When I described A6 to someone recently they said they thought it was
> so that you could renumber entire networks automatically based on core
> topology changes without the relevant leaf network admins' having to
> do anything.
>
> At the time I dismissed this idea as absurd; we have enough
> reliability problems as it is without large sites and networks being
> made unuseable even internally because someone somewhere at a
> different organisation made a mistake in a configuration and causes
> the DNS to start giving out wrong addresses.
>
> I haven't seen much motivation for A6 in the relevant RFCs and I-Ds,
> so perhaps I'm barking up the wrong tree - in any case, some
> explanation of why this is a good thing and how it is expected to be
> used would be helpful.
>
> Alternatively, perhaps I'm wrong and it is indeed the intent of the
> IPNG working groups that renumbering could happen entirely
> automatically, and need not involve an action by the administrator of
> the site being renumbered. If so I have to say I'm rather alarmed,
> but perhaps I've missed some vital reason why this is a good idea.
>
> On the other hand, I can't see another good reason for A6. After all,
> if renumbering is going to require an administrative action by the
> people who run the site being renumbered, they might as well use the
> entirely normal and standard zone changing mechanisms to do it.
>
> If an admin feels that doing a search-and-replace on their zone files
> is too difficult or error-prone, then they can easily use one of any
> number of tools to help them generate the zone files semiautomatically
> so that they only have to configure the network number in one place.
> If renumbering is too frequent to do like that (more than once a
> month, say) then I'm sure people will develop software to help manage
> it, and perhaps there would be a role for an IETF protocol for doing
> so in a secure and reliable way.
>
> So the
RE: Usage of IPv6 flow label
Brian Carpenter wrote: > > Francis Dupont wrote: > > > > In your previous mail you wrote: > > > >- figure out a way to make the other option in Alex's draft: > > > > 0 1 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |0| Server Port Number| H-to-H protocol| > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > >suitable for use by policy-driven diffserv classifiers. > > > > => can you explain why it is not enough to use the SPI in place of > > higher layer selectors? > > The SPI doesn't have the semantics. A QOS classifier needs to *know* > the port and protocol numbers; that's how it takes its decisions. > For example you might put traffic with protocol number 30 in a > different class from traffic with protocol number 41. > > Alex's idea of using "server port number" is in fact > interesting, since it would allow you to classify traffic > on its original well-known port #, without having to rely > on dynamically assigned port #s for classification. > I'm beginning to think he may be right. But I suggest > allocating 11 bits to the port number and 8 to the > protocol number, so that we can cover at least > some of the registered ports (up to 2047). But the flow > label isn't long enough for everything we need. What is useful for the policy decision is to have an indication of the user priviledges and then an indication of the application. Most policy decisions are about given some users some guaranties that they can run some applications. Addresses are only approximative indications of the users -- think about proxies, mobility, etc. -- and ports are only approximative indications of the application -- think about floating ports, applications multiplexed over HTTP, etc. Having a protocol + port indication in the flow id is a way to provide an indication about the indication. But we can do better than having a protocol + port tuple. What we really want is some registry of applications, into which we could fold the registered ports; then, once the registration becomes well known, it becomes easy to write rules that allow for packet classification. If we start from this registration perspective, then we want a format that allows for several classes: * Inherit registration from current registration of TCP and UDP ports -- probably two classes, * One class registration of new applications, e.g. provide codes for those applications that currently work on floating ports, * One class for non-registered applications, allowing for experimentation, * A null label for users who don't want to disclose what application they are running. If we do that, then the end system can easily set the application code, and the intermediate routers can easily use them. -- 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: Usage of IPv6 flow label
Brian, I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv." I think you have a model there in which the diffserv bits are set by some intermediate router, after examining the "5 tuple" of the packet. In this context, the five-tuple works somewhat. But it does not work well with IPSEC (ports are hidden), it does not work well with floating port applications such as VoIP, and it leads to some interesting header manipulation when we encounter stacks of IPv6 headers. There are at least two other ways to "enable diffserv." One way would be to just let the hosts set the diffserv bits, and then let the intermediate router do accounting, charging, and maybe rationing. Another way is to use RSVP to convey the requested quality of service, and the user credentials, to the intermediate routers; then, the flow-id can be use for flow classification, and the intermediate routers can on this basis set the diffserv bits however they see fit. -- Christian Huitema > -Original Message- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 27, 2000 2:49 PM > To: Michael Thomas > Cc: Jim Bound; Ipng (E-Mail) > Subject: Re: Usage of IPv6 flow label > > > Michael Thomas wrote: > > > > Brian E Carpenter writes: > > > Jim, > > > > > > It still isn't clear to me what the flow label adds to > the semantics > > > used by existing 5-tuple QOS classifiers. > > > >It seems intuitively more efficient for a flow classifier > >to use a single host-defined flow identifier than having > >to walk a potentially long list of extension headers. > >Another advantage is that, sort of like diffserv, the > >host itself can decide what is to be grouped in a particular > >flow instead of requiring that it match the normal 5-tuple. > > Just to make the point again: the 5-tuple has semantics that > allows a classifier to *classify* the traffic. Today at least, > the flow label has no such semantics - it's just plain bits. > That may help in IntServ but it's no use at all in DiffServ. > > 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] > > 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: An IPv4 anycast address for 6to4<->6bone gateways
Actually, what you want is to reserve sufficiently large IP address prefix, so that it will be accepted without questions by BGP routers -- at least a /19; a class B would be nice; in fact, if an address rich institution would donate a class B for that purpose, that would be even better; asking the IANA to reserve 191.255/16 for that purpose would also look cool. It would also be useful to dedicate an IPv4 AS number to that purpose. The IPv6 routers that have a complete access to both IPv6 and IPv4 would announce the corresponding prefix in their local IGP, as a route to an external network. The ASes that run such routers and are willing to provide access to the v6 network would announce a path to the v6 AS and to the 6to4 prefix using BGP; they could easily use the existing structure of peering and transit agreement to control to whom they are willing to provide service. The whole v6 network will appear to v4 as a single AS, with lots of peering points all over the place. The 6to4 gateways would then send use an address under the 6to4 prefix as a default route for reaching v6 packets. It will normally reach the service provided by their ISP, or by the closest ISP according to inter-domain routing. This scheme has many advantages. It is simple to implement in 6to4 gateways, it allows ISP to control to whom they are providing service, it allows for independent deployments of gateways to the 6Bone and the v6 network by multiple ISPs, it allows for scaling by deploying a large number of "peering points." In the acknowledgement section: I believe that scheme was first proposed by Randy Bush. -- Christian Huitema > -Original Message- > From: Brad Huntting [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 27, 2000 2:46 PM > To: f.johan.beisser > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Subject: An IPv4 anycast address for 6to4<->6bone gateways > > > > > http://www.kfu.com/~nsayer/6to4/ > > Actually this web page brings up another issue that a freind and > I were discussing just yesterday. Anyone who's actually tried to > use 6to4 (2002::/16) has probably noticed that they need a default > route to reach the 6bone. But even assuming you actually find such > a router it is almost always on the far side of the Internet; which > means that your packets get to take the scenic route on their way > to the 6bone. > > One simple solution to this would seem to be to use a well known > IPv4 "anycast" address (call it "a.b.c.d" for now) for all 6to4 > gateways. > > In this way, anyone using 6to4 could reliably use 2002:(a.b.c.d)::1 > (actual IPv6 address syntax will vary) as a default route to the > 6bone. > > 6to4 gateways would advertise to the their IPv4 peers that they > have a route for "a.b.c.d". And for their IPv6 peers (the 6bone) > they can advertise a route for 2002::/16. > > Does anyone see a problem with this? I dont suppose there's already > a block of IPv4 address space set aside for anycast? > > > brad > > 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: IPv6 and NAT
> NAT was proposed as a temporary solution for the shortage of > IP address, > which is solved with the IPv6 protocol. Currently I don't > expect IPv6 to be > deployed soon (within 1 or 2 years). My ISP, nor many ISPs, > aren't promoting > IPv6 yet, nor Microsoft provides IPv6 support for it's OSes. Well, actually, Microsoft's support is documented at: * Microsoft IPv6 Tech Preview News http://www.microsoft.com/PressPass/press/2000/Mar00/IPv6PR.asp * Microsoft IPv6 Tech Preview Kit http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp * Microsoft IPv6 white paper http://www.microsoft.com/technet/network/ipvers6.asp but let's go to your actual points: > However, some scenarios where NAT provides THE solution, are for > * private networks that may not be exposed to the Internet and > * for networks that have only one IP address available to use on the > Internet, > while host on the private network are required to make > 'direct' connections > to the Internet. IPv6 supports "private networks that may not be exposed to the Internet" through the use of scoped addresses, i.e. "site-local" and "link-local" addresses. This covers most of the cases in which some dumb hosts are allowed to connect to the network but not to the Internet. For example, if you have a light-switch that should not be activated by remote players, that light-switch should be configued to only use site-local and link-local addresses. It will never receive a packet from outside the network, nor send a packet to the outside. I don't really understand how your hypothesis of "networks that have only one IP address available" fit with the other statement, "for the shortage of IP address, which is solved with the IPv6 protocol..." -- 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: When should mobile nodes use their care-of address, etc...
May I observe that, in attempting to specify a source address selection algorithm, the WG goes well beyond the traditional IETF role, which is to focus on interoperability issues, not implementations? I would expect such algorithms to evolve in time, as we learn more on the subject. I would also expect them to vary a lot depending on how much a particular station knows about its environment, how far in the future it can predict the application's behavior, what arbitration is made between privacy and performance, etc. Rather than specify an actual algorithm, the WG should be content with a list of recommendations, in the form of "if you do this, expect that" or "don't do X, because it will cause interoperability problem Y." -- 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: Comment on draft-ietf-ipngwg-addrconf-privacy-02
Matt, The privacy requirements imply, if you use Dynamic DNS, that you create names, addresses, and reverse mapping. For the direct records, this is slightly different from the classic DDNS usage, in which you update the value of the address record for a pre-existing name. In particular, if the name already exists, the DNS can secure the transaction using pre-existing info, such as the public key associated with the name. Not sure that existing DNS servers will gladly let you create a large number of phony names. 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: SCTP API draft (was Re: New "IP Version 6 Addressing Architecture" draft)
> Note that how the system picks those addresses are still not "clearly" > specified. It may not make sense to pick all addresses > associated with an > interface. The reason for having multiple addresses is that > SCTP can failover > to another address if the primary fails. But if all the addresses are > associated with an interface, failover may not make sense at > all. There are > still a lot of work to be done in this area in the draft... If the multiple addresses have different prefixes, then the packets will be routed through different paths. This provides a useful failover situation, from a failing provider to a valid provider, even if the interface is the same. 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]
