Re: NAT Not Needed To Make Renumbering Easy
Christian Vogt wrote: Why would an IPv6 NAT need to find the checksum if the checksum does not need to be changed anyway? Hmmm, you should be assuming that all the transport checksums will be 1's complement 16 bit sum, even though modern transport protocols are using different checksum. Anyway, checksum of ICMP error generated against ICMP echo must still be changed, and the error packet may (though does not usually have to) be fragmented. BTW, I have noticed that possibly-lengthy extension header is not protected by IP nor transport checksum, which should be a flaw of IPv6. Also, SCTP ignores to protect source and destinaiton addresses in IP header, maybe for NAT transparency, though IPv6 expect transport protocls to do so. IPv6 specification requires IPSEC, which means outer most IPv6 must also support IPSEC. Sure, no one is arguing with this. My point was that, while IPv6 NAT does interfere with some modes of IPsec, there are other IPsec modes that are not affected by IPv6 NAT. Makes sense? The problem is that IPSEC requirement of IPv6 is not specified as some modes of IPsec should be supported. Instead, IPv6 requires support for AH and ESP extension headers. I think we can laugh at the reason why IPv6 insists on IPSEC documented in rfc2463. 5.1 Authentication and Encryption of ICMP messages ICMP protocol packet exchanges can be authenticated using the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an Authentication Header when sending ICMP messages if a security association for use with the IP Authentication Header exists for the destination address. The security associations may have been created through manual configuration or through the operation of some key management protocol. Received Authentication Headers in ICMP packets MUST be verified for correctness and packets with incorrect authentication MUST be ignored and discarded. where, thanks to IPSEC, DoS by ICMP can be prevented only with a *SMALL* amount of computation and message exchanges of some key management protocol. :-) Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
Phillip Hallam-Baker wrote: I assert that regardless of whether NAT66 is a good or a bad thing, anything that layers on IPv6 must be NAT66 tolerant. Because IPv6 is a bad thing, there should be nothing on IPv6. Observation: Without NAT44 the internet would already have run out of address space. Observation: With NAT44 and unicast class E (and part of D) the IPv4 Internet would not run out of address space for the time being. I think that it is now very clear that the IPv6 transition will take at least another decade Considering that development of IPv6 did not take so many years, it is better to have another IPng which is more easily deployable than IPv6. If we accept these two observations we arrive at a proof that NAT66 is unavoidable. Only if IPv6 were worth deploying. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
Masataka Ohta writes: Only if IPv6 were worth deploying. Isn't this a little... late? A few hundred million devices are deployed with IPv6, including all the commonly deployed versions of Windows and IOS. By comparison, here's an overview of how an alternative might fare: 1. Some drafts are published. 2. A BOF is held at IETF77 (fortunately for this BOF, IETF77 is held in a country that cherishes free speech). 3. Some more drafts are published. 4. There's fighting over whether to do a WG at all, and vile fighting over the design of the perfect IPng. 5. A WG has its first meeting at IETF79. 6. On the Tuesday of IETF80 the IANA switches to armageddon rules and transfers the last ten /8s to RIRs. 7. On the following Wednesday, the press reports that the internet is out of addresses and IPv6 becomes a big buzzword. Game over. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
Arnt Gulbrandsen wrote: Only if IPv6 were worth deploying. Isn't this a little... late? A few hundred million devices are deployed with IPv6, including all the commonly deployed versions of Windows and IOS. By comparison, here's an overview of how an alternative might fare: Within IETF, maybe. As ITU, these days, is doing much better than IETF that IPng could better be discussed there or somewhere else. 6. On the Tuesday of IETF80 the IANA switches to armageddon rules and transfers the last ten /8s to RIRs. Can you say NAT and unicast class E? Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 79 Announcement
On Nov 9, 2009, at 2:24 AM, Ray Pelletier wrote: The IAOC is pleased to announce the ancient and historic city of Beijing as the site for IETF 79 from 7 - 10 November 2010. Nov 7-10? Sunday-Wednesday? That's unusually short for an IETF meeting. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 79 Announcement
On Nov 9, 2009, at 12:06 PM, Steven Bellovin wrote: On Nov 9, 2009, at 2:24 AM, Ray Pelletier wrote: The IAOC is pleased to announce the ancient and historic city of Beijing as the site for IETF 79 from 7 - 10 November 2010. Nov 7-10? Sunday-Wednesday? That's unusually short for an IETF meeting. Fall 2010 - 79th IETF November 7-12, 2010 Regards Marshall --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 79 Announcement
Yeah, that should of course be 7 - 12, Sunday to Friday as usual. Just goes to show that no matter how long you stare at text there is still at least one obvious error letf ;-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Mon, 9 Nov 2009, Steven Bellovin wrote: On Nov 9, 2009, at 2:24 AM, Ray Pelletier wrote: The IAOC is pleased to announce the ancient and historic city of Beijing as the site for IETF 79 from 7 - 10 November 2010. Nov 7-10? Sunday-Wednesday? That's unusually short for an IETF meeting. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Circle of Fifths
On Thu, Nov 5, 2009 at 5:44 PM, Steve Crocker st...@shinkuro.com wrote: Full disclosure: I serve on the ICANN board of directors, and I chair ICANN's Security and Stability Advisory Committee (SSAC). Both of these are volunteer, i.e. unpaid, positions, but ICANN does pay my travel expenses for meetings. It's mildly amusing to see how this thread has drifted from where it started. Also annoying. See inline for responses. On Nov 5, 2009, at 12:53 PM, John Levine wrote: As near as I can make out, ICANN collects bucketloads of cash without really having any idea why. The only rationale seemed to be to pay a rather surprising large salary to the CEO. Agreed, except for the surprise part. The whole staff is paid impressively large amounts and has been as long as I've been watching ICANN. They seem to feel that their peer organizations for compensation purposes are investment banks rather than other non-profits. I don't have access to the salaries of individual employees, and I doubt you do either. In general, ICANN pays its staff competitively in order to attract and retain skilled people. A very large number of people also participate in ICANN as volunteers, similar to the way the IETF, ISOC and other organizations work. $722,079 for the services of Twomey was far more than he could have expected in any other role and far more than his performance in the job justified. In response to John,: I think that prior to his appointment all of us would be very surprised to know what Twomey would be making in a few years time. Beckstrom can clearly demand a very substantial salary in other roles. That is why I used the past tense. Instead they are currently looking to raise even more money through the sale of TLDs but last time I heard were curiously uninterested in providing any material support to the root operators who would be bearing the expense of supporting these new domains. If I were a root server operator, it would take an implausibly large amount of money to be worth the strings that ICANN would attach. A key reason that the DNS still works is that there's no root server contract, so the root operators can individually or jointly tell ICANN to pound sand if they don't care for the root zone that ICANN offers them. Hence ICANN is very cautions about changes. This is multiple pieces of nonsense: o ICANN is very cautious about changes to the root because that's the right thing to do. A huge amount of work goes into vetting each and every requested change. To suggest they are cautious only because of the root operators is both factually wrong and insulting. It's really time to stop bashing the ICANN staff. When they make a mistake, they'll admit it and fix it. The competence level inside ICANN is surely as good as in the IETF and other organizations. One of the problems of living in the US is that there is really very little experience of long lived institutions. Let us stipulate for the sake of argument that all the current staff are competent, what guarantees do we have for situation 20 years from now, how about 50? How about 500? There is a College in Oxford that is currently facing the imminent expiry of its 499 year lease. I really don't think that this degree of thinking is evident in the design of ICANN. The type of situation that we can end up in is illustrated by the French recording rights society, which U2 withdrew their songs from after receiving a pittance (I seem to rememer it was less than $100) while the President of the organization proudly unveiled the grandiose multi-hundred million dollar building on which the money collected on behalf of U2 and the other artists had been spent. o The idea that the root operators would actually catch or stop errors in the root zone is more fantasy than reality. The root operators are highly automated and don't generally look at the content of each update of the root zone. At a recent meeting in the EU, a senior official at a major registry made the claim that the root operators were the last line of defense against malicious or capricious behavior by ICANN or the U.S. Government, and that DNSSEC would diminish the ability of the root operators to protect a registry from being removed from the root zone. I took the opportunity ask if the root operators were, in fact, ready, willing and able to serve in such a capacity. If so, were there realistic plans and practice in place? We're living in a post 9/11 world where organizations take such questions seriously. They prepare plans and they practice dealing with contingencies. I followed up with the root operators at a subsequent meeting. No such plans exist, and the root operators do not seem inclined to organize themselves to act in such a capacity. (I'm not taking a position pro or con as to whether they should have such a role. I'm only saying there's no connection between the claim that they have this role and any
RE: Broadband Forum liaison to IETF on IPv6 security
On Thu, 5 Nov 2009, Dunn, Jeffrey H. wrote: I may be missing something, but it appears that, in the cases described, the two hosts downstream of two separate cable modems are off link to each other. This brings up the question: Do there two cable modems constitute two virtual interfaces, like two VLANs on the same physical router interface? If so, this is an architectural, rather than an implementation, question. Thoughts? This is basically forced forwarding for the L2 aggregation layer. It's often done on ETTH deployments as well as cable environments, in IPv4 it's done in conjunction with local-proxy-arp (in your IP subnet, the ISP router will answer all ARP requests with its own MAC and all traffic between clients within the subnet is done via the router which does not send out ICMP redirects). In my mind it's unsuitable for clients to run SLAAC in these environments and the only real alternative is full DHCPv6(-PD) with SAVI-like functionality in the L2 equipment along the way (in v4 the L2 equipment does DHCP-snooping and installs L3 filters accordingly). -- Mikael Abrahamssonemail: swm...@swm.pp.se ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Circle of Fifths
On Fri, Nov 6, 2009 at 5:55 AM, Steve Crocker st...@shinkuro.com wrote: One of the problems of living in the US is that there is really very little experience of long lived institutions. Let us stipulate for the sake of argument that all the current staff are competent, what guarantees do we have for situation 20 years from now, how about 50? How about 500? There is a College in Oxford that is currently facing the imminent expiry of its 499 year lease. Yes, one of the problems of living in the U.S. is it's a young country that is unafraid to invent, experiment and reflect on its institutions. Thus comes the Internet, invented even though we have the oldest operating democracy. The US Constitution was an attempt to recreate the English Constitution which at the time was at least 500 years old with incremental improvements based on the best research of the day. It was 'built to last'. The founders took the time to understand the security risks and built in checks and balances. ICANN is not built in that fashion. It has no reall checks or balances, just a set of people who airily dismiss the notion that they might have a duty of accountability. After every revolution, the plotters withdraw into a cabal and carve up the power. Steve, it appears that you do not understand the security concerns that are driving the politics of DNS. The concern that ICANN might drop the Palestine zone out of the root is precisely the source of the Egyptian delegation concern. That is the reason why the ex-Interim Prime Minister of the Palestinian authority took the time to meet with Twomey, I can assure you that it was no social call. The concern that ICANN might drop Cuba out of the root zone is one of the principal drivers of the Brazilian concerns. The Russian and French delegations have no specific concerns that they have voiced to me but they certainly understand that ICANN has power over the communications system that is only checked by the US government, if at all. Some folk in the old US State department thought this situation was just dandy. Some folk in the new administration are less than happy with the situation. It means that all it takes to create an international crisis is for some fool in Congress to put in a bill to force ICANN to drop Cuba, Palestine or whatever other country they want to grandstand against out of the root. There is no particular secret to learning these concerns, you just have to do some active listening. We're pretty far afield. Conspiracy theories are easy to create. Conspiracies happen. You are playing in the big leagues here. Those people you dismiss as 'conspiracy theorists', they made the events of the latter half of the 20th century happen. they spent thirty years doing things like situating the West German TV masts in places that intentionally creat overspill into East German areas, developing technical standards that ensure that the East Germans can watch. It is easy to tell a nutty conspiracy theory from a real one, the nutty theory will be discussed endlessly (Roswell, JFK, etc.) the real conspiracy theories are ignored. We know for a fact that Col. Ollie North was supplying arms to the Iranian government and using the receipts to supply Latin American terrorists. That is an incontrovertible fact, it was a conspiracy but we don't need to talk about it because we all know it is true. I have listened to these sorts of arguments, including directly from the principals of some of the countries. Simply not connected to reality, but definitely understandable in terms of the broader long standing, slowly evolving geopolitical drama. No, that is their reality. Like you, I have been in the meetings where cybersecurity is discussed. I am pretty sure you know that the policy of the US State department is and has been for some time to ensure that the Internet is as free as possible from censorship controls as a means of destabilizing authoritarian regimes. These are not conspiracy 'theories', they are conspiracies that you and I know are fact because we have been a part of them. The Internet is the political pawn of the decade. It's important to sort out which issues are specific to the Internet and which are really proxies for the broader east vs west, north vs south, developing vs developed political tensions. No, it is not important for you to understand the reasons behind the concern at all. What you have to do at ICANN is to deal with the concern of your customers regardless of whether or not you consider them to be well founded. Whether the concerns are credible or not, they are genuine. And some of the people who hold them have the power to ensure that DNSSEC is not deployed in their country. The decision whether to deploy DNSSEC within an existing ccTLD is up to that operator. Those decisions will be based on a wide variety of factors. Some have already deployed. Many more are in the process of doing so and
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
On Fri, 6 Nov 2009, Dunn, Jeffrey H. wrote: The problem is IMHO the following: How to assign an IPv6 UGA to CPE hosts attached to a BMA LAN (usually Ethernet or Wi-Fi) that is in turn connected via a CPE router through an NBMA link (cable modem or DSL) to an ISP router that provides Internet access. Currently, there are two And what happens when there are multiple CPE routers a) connected via a BMA LAN to the DSL or cable modem and/or b) 'connected' via separate NBMA links but are on the same WAN subnet (assigned by the ISP) I think in the latter, if the ISP decides to silo the individual NBMA links then they need to adjust for that in how they do the sub-delegation which is I think what the issue is. But if the ISP actually bridges the separate NBMA links, then there's no silo issue and the CPE can pretend they're in 'a'. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
The key is that the access router (which is the only router that knows this is an NBMA link and not a BMA link) can selectively decide to send ND messages (either NA's or NS(DAD) messages) when the access router detects that there is a duplicate on the link. This is the minimum requirement to support DAD on an NBMA link. This would need to specified in an NBMA-specific document and probably doesn't need to be mentioned in a document like RFC 4861. - Wes -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 2:18 PM To: Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Antonio, Regardless of whether the ISP bridges the NBMA links or not, the CPE router will not propagate the ND or NS messages onto these links. The Ethernet and Wi-Fi BMA LAN segments are separate logical links from each other and the ISP link(s). How will the CPE router be convinced to bridge these link-local scoped messages off link? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Friday, November 06, 2009 1:35 PM To: Dunn, Jeffrey H. Cc: Thomas Narten; Fred Baker; 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Thomson; v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security On Fri, 6 Nov 2009, Dunn, Jeffrey H. wrote: The problem is IMHO the following: How to assign an IPv6 UGA to CPE hosts attached to a BMA LAN (usually Ethernet or Wi-Fi) that is in turn connected via a CPE router through an NBMA link (cable modem or DSL) to an ISP router that provides Internet access. Currently, there are two And what happens when there are multiple CPE routers a) connected via a BMA LAN to the DSL or cable modem and/or b) 'connected' via separate NBMA links but are on the same WAN subnet (assigned by the ISP) I think in the latter, if the ISP decides to silo the individual NBMA links then they need to adjust for that in how they do the sub-delegation which is I think what the issue is. But if the ISP actually bridges the separate NBMA links, then there's no silo issue and the CPE can pretend they're in 'a'. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Broadband Forum liaison to IETF on IPv6 security
Mikael Abrahamsson a écrit : On Thu, 5 Nov 2009, Dunn, Jeffrey H. wrote: I may be missing something, but it appears that, in the cases described, the two hosts downstream of two separate cable modems are off link to each other. This brings up the question: Do there two cable modems constitute two virtual interfaces, like two VLANs on the same physical router interface? If so, this is an architectural, rather than an implementation, question. Thoughts? This is basically forced forwarding for the L2 aggregation layer. It's often done on ETTH deployments as well as cable environments, in IPv4 it's done in conjunction with local-proxy-arp (in your IP subnet, the ISP router will answer all ARP requests with its own MAC and all traffic between clients within the subnet is done via the router which does not send out ICMP redirects). In my mind it's unsuitable for clients to run SLAAC in these environments and the only real alternative is full DHCPv6(-PD) with SAVI-like functionality in the L2 equipment along the way (in v4 the L2 equipment does DHCP-snooping and installs L3 filters accordingly). The initial question mentionned link-local duplicate. For a reason: ther are not assigned by DHCPv6 which preq their existence and unicity. SLACC is your only choice. Eric ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: our pals at ICANN, was Circle of Fifths
On Fri, Nov 6, 2009 at 5:28 AM, Steve Crocker st...@shinkuro.com wrote: On Nov 5, 2009, at 11:30 PM, John R. Levine wrote: This is multiple pieces of nonsense: I actually don't think we have any serious disagreement here. ICANN's management of the root zone is cautious for all sorts of reasons, and as you note the root server operators have no plans to say no to what ICANN offers them. It's always been clear that one reason is that the consequences if any of the root servers felt unable or unwilling to accept ICANN's root would be too awful to contemplate, so it'll never happen. No, it's not too awful to contemplate. Far from it. As a matter of prudent planning, consideration of the consequences of a root operator refusing to update the root zone is definitely something that ought to be part of contingency and disaster planning. So a contingency that a few posts ago you dismissed as 'nonsense' now turns out to be something that does require extensive consideration. But I note that you are actually discussing a different contingency, the consequences of a single default. Clearly the root operators are responsible to and accountable to the Internet community. I would expect that a default by a single root operator would be dealt with by ISPs redirecting packets sent to that IP address block to a different root. It is not that hard, it is merely a matter of the BGP cabal deciding that the expectations of the Internet community are not being met and adjusting accordingly. But that was not the scenario at issue. The scenario at issue was the case that it is ICANN that is considered to be in default. That is not going to happen because the consequence would be the end of ICANN. Some of the root operators would back the ICANN line of course, perhaps they all would. But if some part of the US government was to decide to abuse the degree of control it has over ICANN, other governments would respond in the same fashion and order their domestic ISPs to redirect traffic away to approved roots. The consequences for the Internet would be rather small. I doubt that there would be much disruption of Internet service. But the diplomatic dislocation would be huge and ICANN would be utterly broken in the process. The essential weakness of ICANN's position was recognized very early on, before the organization was founded in fact. And that is why it was tolerated in its current form. DNSSEC with a single root of trust would transform it from constitutional monarch to absolute monarch. Having people respond to such concerns by saying 'trust me, you are paranoid' is not the way to win friends and influence people. As you admit in your own posts, the national security issue has been raised with you by the sovereign powers directly. Who do you think you are to dismiss those concerns as delusions? But to return to the original issue, ICANN has plenty of money if they wanted to support the IETF. But the IETF needs to get organized enough to ask in a way to which you and the rest of the board can say yes. You've just changed the subject from support for the root operators to support for the IETF. The IETF situation was already discussed in detail. And that topic was avoided as well, which is hardly surprising. ICANN has already conceded the principle of supporting the IETF through the highly conflicted award of the .org contract to a group including ISOC. That is not a transparent or accountable mechanism. It sets up a whole series of conflicts of interest for the ICANN and ISOC boards. It would be much better to simply give the money in the form of a grant. Giving money to the IETF and W3C would provide a political support base that ICANN desperately needs. It would also be justified on the basis that ICANN exists to further the development of the Internet and that ICANN revenues are driven by increased use of open Internet protocols. -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
The reason I raised the historical perspective is that so many people make arguments against NAT based on historical claims that are contrary to my recent conversations with David Clark amongst others. My position, which I have been fairly consistent in is that there is only one Internet namespace: the DNS. All other network namespaces are secondary. That is not something to rue, it is something to celebrate. Messing with the DNS is hard precisely because it will eventually become the uber-namespace that subsumes everything (even telephone numbers will go eventually). The architectural gain that we should be looking for in the IPv6 transition is to liberate the architecture from dependence on IP protocol. That will give us more flexibility to do interesting things at the IP level without having the oppressive weight of legacy deployment assumptions bearing down. The technical circumstances that favor packet switching as a paradigm are not necessarily constant as we go into realms such as cloud computing. I can well imagine circumstances where I want to have an IP tunnel to an endpoint that is living in the cloud with an intermediate circuit switched layer involved at some point. Deciding that IP is the only protocol for all time might be a mistake. On Thu, Nov 5, 2009 at 1:01 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Phillip Hallam-Baker hal...@gmail.com The original architecture made no assumption that IP would run end to end, let alone that the IP address would be constant end to end. Say what? That's not my recollection at all. But this isn't the Internet-History list, so I'll move on. I do not see any architectural value in insisting that applications assume that the IP address is constant from one end of a communication to the other. That's a complex question, and it depends in part on how many other namespaces there are. It is not a necessary assumption .. it is not one that any application protocol can rely on if it is to work on 99% of the Internet deployed today. Well, that is certainly true. IPv6 should be as little different to deployed IPv4 as possible. That has minuses as well as pluses, though. A big one is that if IPv6 is just IPv4 with a few more bits of address, then you sort of limit the capability, and therefore the benefits, of IPv6. No architectural changes - no new/additional capabilities. Remember that the first rule of the Internet is: You are SO NOT in charge here (for all values of YOU). A powerful observation, one we should all remember... Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
Antonio, Regardless of whether the ISP bridges the NBMA links or not, the CPE router will not propagate the ND or NS messages onto these links. The Ethernet and Wi-Fi BMA LAN segments are separate logical links from each other and the ISP link(s). How will the CPE router be convinced to bridge these link-local scoped messages off link? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Friday, November 06, 2009 1:35 PM To: Dunn, Jeffrey H. Cc: Thomas Narten; Fred Baker; 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Thomson; v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security On Fri, 6 Nov 2009, Dunn, Jeffrey H. wrote: The problem is IMHO the following: How to assign an IPv6 UGA to CPE hosts attached to a BMA LAN (usually Ethernet or Wi-Fi) that is in turn connected via a CPE router through an NBMA link (cable modem or DSL) to an ISP router that provides Internet access. Currently, there are two And what happens when there are multiple CPE routers a) connected via a BMA LAN to the DSL or cable modem and/or b) 'connected' via separate NBMA links but are on the same WAN subnet (assigned by the ISP) I think in the latter, if the ISP decides to silo the individual NBMA links then they need to adjust for that in how they do the sub-delegation which is I think what the issue is. But if the ISP actually bridges the separate NBMA links, then there's no silo issue and the CPE can pretend they're in 'a'. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
Wes, That is an interesting idea. One question occurs to me that you can probably answer. What happens if a host behind the CPE router does SLAAC, configures a UGA? Since it has already done DAD, the host assumes it has an unused address. When the host finally tries to use the UGA to access the Internet and the access router sends an NA or NS(DAD), what should the host do? It has already validated the UGA using DAD. My interpretation is that it should reply to the NS(DAD) with an NA (based on RFC 4862). I am not sure about a duplicate NA, since DAD is supposed to prevent this. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Wes Beebee (wbeebee) [mailto:wbee...@cisco.com] Sent: Friday, November 06, 2009 4:48 PM To: Dunn, Jeffrey H.; Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security The key is that the access router (which is the only router that knows this is an NBMA link and not a BMA link) can selectively decide to send ND messages (either NA's or NS(DAD) messages) when the access router detects that there is a duplicate on the link. This is the minimum requirement to support DAD on an NBMA link. This would need to specified in an NBMA-specific document and probably doesn't need to be mentioned in a document like RFC 4861. - Wes -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 2:18 PM To: Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Antonio, Regardless of whether the ISP bridges the NBMA links or not, the CPE router will not propagate the ND or NS messages onto these links. The Ethernet and Wi-Fi BMA LAN segments are separate logical links from each other and the ISP link(s). How will the CPE router be convinced to bridge these link-local scoped messages off link? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Friday, November 06, 2009 1:35 PM To: Dunn, Jeffrey H. Cc: Thomas Narten; Fred Baker; 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Thomson; v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security On Fri, 6 Nov 2009, Dunn, Jeffrey H. wrote: The problem is IMHO the following: How to assign an IPv6 UGA to CPE hosts attached to a BMA LAN (usually Ethernet or Wi-Fi) that is in turn connected via a CPE router through an NBMA link (cable modem or DSL) to an ISP router that provides Internet access. Currently, there are two And what happens when there are multiple CPE routers a) connected via a BMA LAN to the DSL or cable modem and/or b) 'connected' via separate NBMA links but are on the same WAN subnet (assigned by the ISP) I think in the latter, if the ISP decides to silo the individual NBMA links then they need to adjust for that in how they do the sub-delegation which is I think what the issue is. But if the ISP actually bridges the separate NBMA links, then there's no silo issue and the CPE can pretend they're in 'a'. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: t...@lava.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
This is the same thought I emailed about that the access concentrator in the NBMA link performing ND Proxy - Wes and I are saying the same thing - he put is very nicely in concise form. The access concentrator is also the first hop IPv6 router to the broadband enabled home and note that a router interface joins only the all-nodes mcast address and the interface solicited-node mcast address. Such an interface mcast join will not let the router see all NS(DAD)s on the link. That is why when a router in the BMA or NBMA link starts sniffing all mcast traffic, then the router sees all the NS(DAD)s on its link and this sniffing for all mcast traffic happens to be the first requirement of a ND Proxy! As for your question below, the CPE Router in the home has got to have been delegated a prefix and each home gets a different prefix, so how can the UGA from the home device from one home ever encounter a dup at the access concentrator? If anything dups can exist within the same home, but the CPE Router already takes care of those dups in the home LAN link. Hemant -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 6:26 PM To: Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Wes, That is an interesting idea. One question occurs to me that you can probably answer. What happens if a host behind the CPE router does SLAAC, configures a UGA? Since it has already done DAD, the host assumes it has an unused address. When the host finally tries to use the UGA to access the Internet and the access router sends an NA or NS(DAD), what should the host do? It has already validated the UGA using DAD. My interpretation is that it should reply to the NS(DAD) with an NA (based on RFC 4862). I am not sure about a duplicate NA, since DAD is supposed to prevent this. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Wes Beebee (wbeebee) [mailto:wbee...@cisco.com] Sent: Friday, November 06, 2009 4:48 PM To: Dunn, Jeffrey H.; Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security The key is that the access router (which is the only router that knows this is an NBMA link and not a BMA link) can selectively decide to send ND messages (either NA's or NS(DAD) messages) when the access router detects that there is a duplicate on the link. This is the minimum requirement to support DAD on an NBMA link. This would need to specified in an NBMA-specific document and probably doesn't need to be mentioned in a document like RFC 4861. - Wes -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 2:18 PM To: Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Antonio, Regardless of whether the ISP bridges the NBMA links or not, the CPE router will not propagate the ND or NS messages onto these links. The Ethernet and Wi-Fi BMA LAN segments are separate logical links from each other and the ISP link(s). How will the CPE router be convinced to bridge these link-local scoped messages off link? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Antonio Querubin [mailto:t...@lava.net] Sent: Friday, November 06, 2009 1:35 PM To: Dunn, Jeffrey H. Cc: Thomas Narten; Fred Baker; 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Thomson; v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
OK. Then the CPE router has a unique /64 for all of its broadcast domains? Does that mean that the customer needs to tell the ISP how many /64 prefixes they need? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Hemant Singh (shemant) [mailto:shem...@cisco.com] Sent: Friday, November 06, 2009 7:24 PM To: Dunn, Jeffrey H.; Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security This is the same thought I emailed about that the access concentrator in the NBMA link performing ND Proxy - Wes and I are saying the same thing - he put is very nicely in concise form. The access concentrator is also the first hop IPv6 router to the broadband enabled home and note that a router interface joins only the all-nodes mcast address and the interface solicited-node mcast address. Such an interface mcast join will not let the router see all NS(DAD)s on the link. That is why when a router in the BMA or NBMA link starts sniffing all mcast traffic, then the router sees all the NS(DAD)s on its link and this sniffing for all mcast traffic happens to be the first requirement of a ND Proxy! As for your question below, the CPE Router in the home has got to have been delegated a prefix and each home gets a different prefix, so how can the UGA from the home device from one home ever encounter a dup at the access concentrator? If anything dups can exist within the same home, but the CPE Router already takes care of those dups in the home LAN link. Hemant -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 6:26 PM To: Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Wes, That is an interesting idea. One question occurs to me that you can probably answer. What happens if a host behind the CPE router does SLAAC, configures a UGA? Since it has already done DAD, the host assumes it has an unused address. When the host finally tries to use the UGA to access the Internet and the access router sends an NA or NS(DAD), what should the host do? It has already validated the UGA using DAD. My interpretation is that it should reply to the NS(DAD) with an NA (based on RFC 4862). I am not sure about a duplicate NA, since DAD is supposed to prevent this. Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Wes Beebee (wbeebee) [mailto:wbee...@cisco.com] Sent: Friday, November 06, 2009 4:48 PM To: Dunn, Jeffrey H.; Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security The key is that the access router (which is the only router that knows this is an NBMA link and not a BMA link) can selectively decide to send ND messages (either NA's or NS(DAD) messages) when the access router detects that there is a duplicate on the link. This is the minimum requirement to support DAD on an NBMA link. This would need to specified in an NBMA-specific document and probably doesn't need to be mentioned in a document like RFC 4861. - Wes -Original Message- From: owner-v6...@ops.ietf.org [mailto:owner-v6...@ops.ietf.org] On Behalf Of Dunn, Jeffrey H. Sent: Friday, November 06, 2009 2:18 PM To: Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Antonio, Regardless of whether the ISP bridges the NBMA links or not, the CPE router will
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
Jeffrey, The answer to your question is a yes. Alternatively, the ISP may just dole out a delegated prefix shorter than a /64 and the CPE Rtr has to live with it but the ISP may use something like a /55 that gives sufficient number of links in the home LAN. I will reply to any more discussion on this thread once I reach Hiroshima. Hemant -Original Message- From: Dunn, Jeffrey H. [mailto:jd...@mitre.org] Sent: Friday, November 06, 2009 7:31 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security OK. Then the CPE router has a unique /64 for all of its broadcast domains? Does that mean that the customer needs to tell the ISP how many /64 prefixes they need? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
Hemant, Fair enough. I suppose that there are enough /55's or /56's that every household can have one; however, it does make right sizing the initial allocation to the ISP very important. We would not want to be allocating non-contiguous /28's on a regular basis :-) Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) -Original Message- From: Hemant Singh (shemant) [mailto:shem...@cisco.com] Sent: Friday, November 06, 2009 8:07 PM To: Dunn, Jeffrey H.; Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Jeffrey, The answer to your question is a yes. Alternatively, the ISP may just dole out a delegated prefix shorter than a /64 and the CPE Rtr has to live with it but the ISP may use something like a /55 that gives sufficient number of links in the home LAN. I will reply to any more discussion on this thread once I reach Hiroshima. Hemant -Original Message- From: Dunn, Jeffrey H. [mailto:jd...@mitre.org] Sent: Friday, November 06, 2009 7:31 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security OK. Then the CPE router has a unique /64 for all of its broadcast domains? Does that mean that the customer needs to tell the ISP how many /64 prefixes they need? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
On Wed, 23 Sep 2009, Bill Manning wrote: the japanese equivalent of the OMROM V600-D23P71 Bill, the Omron V600 system is a 530kHz system typically used for industrial automation. The documentation being handed out on-site says the system installed is a 13.56MHz system. Was there perhaps some change in the plans? -- Sam On Wed, Sep 23, 2009 at 09:16:37AM -0700, Ole Jacobsen wrote: I have asked Osamu and Kato to answer. Stay tuned. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Wed, 23 Sep 2009, Samuel Weiler wrote: I'm interested in the answers to the questions asked by EKR a couple of weeks ago... I'd also like to know which frequency band these tags use: are these 125kHz or 13.56MHz tags? -- Sam On Mon, 7 Sep 2009, Eric Rescorla wrote: Alexa, Can you clarify what, if any, the security properties of this system are: In particular: 1. Will the RFID tag in question respond to any reader or just those controlled by the secretariat? 2. Is the information on the tag in the clear or encrypted? My general experience with RFID systems suggests that the answer to these questions is likely to be yes and in the clear, but I'd certainly be pleasantly surprised to hear otherwise. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
We are so not in charge. Support for IPSEC is a requirement to describe an implementation as IPv6. That is all, it does not mean anyone has to use it, or that they will use it. There are two typical modes of deployment for IPSEC, the first is as a lousy remote access protocol where the lack of NAT support makes it far more effort than other solutions. SSL and SSH remote access just works, IPSEC VPN may or may not work depending on the phase of the moon. The third party clients are terrible, the built in support in the O/S is unusable because it does not have the tweaks necessary to get through the firewall. So we do not really have a standard for IPSEC remote access. The other mode for IPSEC is not really an Internet application, it is creating a virtual network by joining together a bunch of routers at local sites. Here the NAT issue is moot because the objective is to create a single network with a consistent IP address space. The fact that this is usually NAT space is not really relevant unless you are attempting to create an industry wide network. Have fun with that. What IPSEC has never got close to achieving is providing an Internet security solution in which packets are secure at the transport layer by default. The obvious reason for this is that IPSEC is not connected to a pervasively deployed PKI for authenticating the end points. There is no commercial infrastructure to support this today, and I doubt that there will be one for some time. NAT is relevant to this scenario only insofar as it will be aa fait acompli long before any PKI is established that might support pervasive IPSEC. And lest folk think I am picking on them here, the reason I raise problems is because I want to see them fixed, not just to carp. I want to deploy DNSSEC because I think that it is the most appropriate PKI to support packet level security. I use NAT for a very simple reason: I do not want my machines to be on the Internet by default. I only want my printers to be accessed by machines in my network. I only want the security system, the home automation system, the daleks, the lab, the coffee maker to be accessible from the network. I do not want Mr Coffee talking to strange computers, he has little common sense. Now I would like my network to have a greater geographic extent than just my house. But there is still a very clear distinction between machines that I own, that I am responsible for, that I want to connect to my network core and all the rest of the stuff on the Internet. Some computers, the desktops and laptops, I do want to have greater access, but there are only eight of them in total, that is a small fraction of my network. The ability to give these devices and IP address THAT WILL NOT ROUTE is very valuable to me as a security control. It is not a perfect control, but I have many, many layers to my defense in depth and I want all of them. We are not in charge of the Internet, but I am in charge of my network, and my policy is to use NAT. In a commercial environment, policy is everything. You do not get security from security technology, you get it from the security practices that the technology supports. Changing a security policy in a commercial environment is a very expensive affair. People are going to demand NAT66 (and cisco is going to support it) because it is cheaper to deploy NAT66 than change the policy. But even then, we are getting way ahead of ourselves. In the real world every network is going to have IPv4 devices on it for decades. I have a 36 plotter upstairs that is ten years old. I am not paying $3K to upgrade it just for the sake of IPv6. On Sat, Nov 7, 2009 at 9:30 PM, Christian Vogt christian.v...@ericsson.com wrote: On Nov 7, 2009, Masataka Ohta wrote: I'm not talking about the amount of value to be offset but the location of transport checksum. The location of transport checksum can be known only by traversing all the extension headers from the beginning of a (unfragmented) packet. So, the second and latter fragments of the packet may or may not contain transport checksum to be offset, which means IPv6 NAT must first reassemble fragmentation. Why would an IPv6 NAT need to find the checksum if the checksum does not need to be changed anyway? IPv6 specification requires IPSEC, which means outer most IPv6 must also support IPSEC. Sure, no one is arguing with this. My point was that, while IPv6 NAT does interfere with some modes of IPsec, there are other IPsec modes that are not affected by IPv6 NAT. Makes sense? - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
I assert that regardless of whether NAT66 is a good or a bad thing, anything that layers on IPv6 must be NAT66 tolerant. While folk can postulate alternative universes in which enterprises will not demand or vendors refuse to implement NAT66, there is another area that is harder to wish away. Observation: Without NAT44 the internet would already have run out of address space. I don't think this can be seriously disputed. Observation: Without NAT46 and NAT64, we cannot transition from IPv4 to IPv6. OK, so when I first started making this claim I was widely dismissed as a fool, a lunatic and other unpleasant things. I think that it is now very clear that the IPv6 transition will take at least another decade to be near completion and that large parts of the net will not support IPv6 access for many years to come. Contrawise, consumers and enterprises are going to require that their ISP provides Internet service that works with the devices they have, not the ones that hardware vendors might hope to sell them. When the US settled for a single lightbulb socket standard there were many different systems in use. The only reason that a transition was possible was due to adapters. The same will be true of the IPv6 transition. If we accept these two observations we arrive at a proof that NAT66 is unavoidable. It will happen any time an IPv6 device with IPv4 service attempts to connect to an IPv6 server. NAT64 + NAT46 = NAT66. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Room for Smart Grid Bar BOF on Wednesday night at IETF 76
[Sorry about the shotgun nature of this email; in the absence of a dedicated email list, I am a bit concerned about missing interested folks!] Folks, We have been assigned Acacia 1 for the Smart Grid Bar BOF. We will start around 8:30PM so that folks attending the plenary will have an opportunity to eat before the session. I expect to windup around 11:00 PM, but that depends largely upon the participants' energy and enthusiasm... Given the scale of this bar BOF (64 IETFers have indicated they wish to attend already!), we will need to be a bit more formal than the usual bar BOF. Here is a draft agenda, subject to usual in meeting agenda bashing: Bar BOF Agenda I. Agenda Bashing Tim Polk II. Smart Grid Overview Jim St. Pierre/Tim Polk II. Introduction to the IP Priority Action Plan Tim Polk III. Discussion of draft-baker-ietf-core Fred Baker IV. Is the IETF the right place to do this work? Russ Housley V. How should the work be organized? (contingent on IV.) Ralph Droms Thanks, Tim Polk ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Room for Smart Grid Bar BOF on Wednesday night at IETF 76
Polk, William T. wrote: Given the scale of this bar BOF (64 IETFers have indicated they wish to attend already!), we will need to be a bit more formal than the usual bar BOF. Here is a draft agenda, subject to usual in meeting agenda bashing: I presume this extends to the provision of an actual and stocked and functioning /bar/, at the back of the room? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Room for Smart Grid Bar BOF on Wednesday night at IETF 76
That would be lovely, but I just couldn't sort the government paperwork to make that happen. Billing it as meeting materials didn't work out... Tim From: iesg-boun...@ietf.org [iesg-boun...@ietf.org] On Behalf Of Dave CROCKER [dcroc...@bbiw.net] Sent: Sunday, November 08, 2009 7:11 PM To: Polk, William T. Cc: ietf@ietf.org; Golmie, Nada T.; pe...@peter-dambier.de; Phil Roberts; IESG IESG; Hiroshi Esaki; Henning Schulzrinne; rec...@ietf.org; Dodson, Donna F.; r...@ietf.org; Russ Housley; Peny Yang; David R Oran; Richard Shockey; IAB IAB; Michael Dillon; Ralph Droms; 76...@ietf.org; Paul Hoffman; Su, David H.; St. Pierre, James A.; Leslie Daigle; Sean Turner; Brian E Carpenter; Fred Baker Subject: Re: Room for Smart Grid Bar BOF on Wednesday night at IETF 76 Polk, William T. wrote: Given the scale of this bar BOF (64 IETFers have indicated they wish to attend already!), we will need to be a bit more formal than the usual bar BOF. Here is a draft agenda, subject to usual in meeting agenda bashing: I presume this extends to the provision of an actual and stocked and functioning /bar/, at the back of the room? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Room for Smart Grid Bar BOF on Wednesday night at IETF 76
Polk, William T. wrote: That would be lovely, but I just couldn't sort the government paperwork to make that happen. Billing it as meeting materials didn't work out... Too bad. Cultural mismatch. Choose the right government and it's not only acceptable, it's assumed... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Fwd: Broadband Forum liaison to IETF on IPv6 security
So have I and Wes been able to close the issue for the DSL Forum folks? Implement ND Proxy at your first-hop IPv6 router/access concentrator. Thanks, Hemant -Original Message- From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Saturday, November 07, 2009 10:07 AM To: Dunn, Jeffrey H.; Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; Erik Nordmark; su...@core3.amsl.com; savi-...@tools.ietf.org; Robin Mersh; Susan Thomson (sethomso); Fred Baker (fred); v6ops-...@tools.ietf.org; i...@core3.amsl.com; IPv6 Operations; Mailing List; JINMEI Tatuya / 神明達哉 Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security Jeffrey, The answer to your question is a yes. Alternatively, the ISP may just dole out a delegated prefix shorter than a /64 and the CPE Rtr has to live with it but the ISP may use something like a /55 that gives sufficient number of links in the home LAN. I will reply to any more discussion on this thread once I reach Hiroshima. Hemant -Original Message- From: Dunn, Jeffrey H. [mailto:jd...@mitre.org] Sent: Friday, November 06, 2009 7:31 PM To: Hemant Singh (shemant); Wes Beebee (wbeebee); Antonio Querubin Cc: Thomas Narten; Fred Baker (fred); 6man-...@tools.ietf.org; SAVI Mailing List; william.allen.simp...@gmail.com; Hesham Soliman; i...@core3.amsl.com; Erik Nordmark; savi-...@tools.ietf.org; IPv6 Operations; Susan Thomson (sethomso); v6ops-...@tools.ietf.org; Robin Mersh; Mailing List; su...@core3.amsl.com; JINMEI Tatuya / 神明達哉; Dunn, Jeffrey H. Subject: RE: Fwd: Broadband Forum liaison to IETF on IPv6 security OK. Then the CPE router has a unique /64 for all of its broadcast domains? Does that mean that the customer needs to tell the ISP how many /64 prefixes they need? Best Regards, Jeffrey Dunn Info Systems Eng., Lead MITRE Corporation. (301) 448-6965 (mobile) IETF IPv6 working group mailing list i...@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 79 Announcement
On Mon, Nov 09, 2009 at 02:24:21AM -0500, Ray Pelletier rpellet...@isoc.org wrote a message of 119 lines which said: The meeting will be held at the Shangri-La Beijing Hotel. So, in the end, what was signed with the hotel, regarding the ability of the hotel to cancel the meeting if one IETF participant says something that could be interpreted as political? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF Flickr Group
There are enough photographers within the crowd that I figured we should have a flickr group for documenting the work and meetings in a NON-ascii way for once. http://www.flickr.com/groups/ietf Feel free to join the group and add pictures if you're interested! After reading the requirements first, of course :-) -- Wes Hardaker Cobham Analytic Solutions ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 79 Announcement
On Nov 9, 2009, at 2:39 AM, Stephane Bortzmeyer wrote: On Mon, Nov 09, 2009 at 02:24:21AM -0500, Ray Pelletier rpellet...@isoc.org wrote a message of 119 lines which said: The meeting will be held at the Shangri-La Beijing Hotel. So, in the end, what was signed with the hotel, regarding the ability of the hotel to cancel the meeting if one IETF participant says something that could be interpreted as political? The provision was removed from the contract. The Hotel will not be monitoring the sessions or canceling the meeting. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: our pals at ICANN, was Circle of Fifths
On Nov 6, 2009, at 9:30 AM, Phillip Hallam-Baker wrote: Clearly the root operators are responsible to and accountable to the Internet community. Err, no. First, the root server operators are all independent actors performing a service for the Internet community for their own reasons. They are formally responsible and accountable to different communities, e.g., the folks who run C are responsible to their share holders and the folks who run A and J do so under a cooperative agreement with the US government. Secondly, there are no formal terms of responsibilities nor accountability to the Internet community. In the past, specific root servers have been operated abysmally poorly and there was nothing that could be done by the Internet community to force root server operators to change the way they do things. With one arguable exception (that of VeriSign) there are no service level agreements, no penalties for failure to perform, and no formal commitments whatsoever. How exactly is that being accountable to the Internet community? DNSSEC with a single root of trust would transform it from constitutional monarch to absolute monarch. I have no idea what this means. As I'm sure you are aware, DNSSEC merely allows folks to validate data hasn't been modified between the point in which the data is signed and the validator. If folks don't want to trust the ICANN/IANA KSK and/or VeriSign ZSK, they're free to import the individual trust anchors however they choose. There is no magic here. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: our pals at ICANN, was Circle of Fifths
David Conrad wrote: There is no magic here. Oh good grief. You are clearly entirely too close to this. It is /all/ f'ing magic. Every f'ing thing about the Internet is magic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: our pals at ICANN, was Circle of Fifths
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/10/09 6:27 AM, Dave CROCKER wrote: David Conrad wrote: There is no magic here. Oh good grief. You are clearly entirely too close to this. It is /all/ f'ing magic. Every f'ing thing about the Internet is magic. Any sufficiently fubar'd technology is indistinguishable from the Internet? ;-) /psa -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkr4iiAACgkQNL8k5A2w/vwzEwCfa5+AsdswPgFNq5C8zCD/Jr7V z0AAnjmKKil5qGOd7sFuSOQUuFaJ3jqm =1Vkq -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-l3vpn-2547bis-mcast-bgp (BGP Encodings andProcedures for Multicast in MPLS/BGP IP VPNs) to Proposed Standard
Jie, Hi, Here are some comments on this draft. (hope this is not too late:) see in-line... 1. 4-octets ASN support The IANA Consideration section says the Source AS extended community is 2-octet AS specific. Consider that 4-octet ASN is supported in other sections of this draft, a 4-octet AS specific equivalent should also be defined. Agreed. 2. Section 8: PE distinguish Labels Attribute +-+ | PE Address| +-+ | Label (3 octets)| +-+ ... +-+ | PE Address| +-+ | Label (3 octets)| +-+ If my understanding is correct, this attribute can contain multiple PE address-Label pairs. thus more than 1 PE address can exist in this attribute. So the statement below may be inaccurate: The attribute is also considered to be malformed if the PE Address field is expected to be an IPv4 address, and the length of the attribute minus 4 is not a multiple of 3, or the PE Address field is expected to be an IPv6 address, and the length of the attribute minus 16 is not a multiple of 3. Thanks for catching this. The correct text should be as follows: The attribute is also considered to be malformed if the PE Address field is expected to be an IPv4 address, and the length of the attribute is not a multiple of 7, or the PE Address field is expected to be an IPv6 address, and the length of the attribute is not a multiple of 19. 3. In section 11.1.3, it says: Inter-AS I-PMSI A-D routes are not used to support non-segmented inter-AS tunnels...The Source AS field in the C-multicast route is set to value of the Originating Router's IP Address field of the found Intra-AS I-PMSI A-D route. Does this mean that for non-segmented inter-AS tunnel, the Source AS filed of C-multicast route will be filled with an IP address? Yes. It may not consistent with statement in the first paragraph of this section: From the selected UMH route the local PE extracts (a) the autonomous system number of the upstream PE (as carried in the Source AS extended community of the route), and (b) the C-multicast Import RT of the VRF on the upstream PE (the value of this C-multicast Import RT is the value of the VRF Route Import Extended Community carried by the route). The Source AS field in the C-multicast route is set to that autonomous system. The text you are quoting above applies when one uses segmented inter-AS tunnels. Besides, if the Originating Router's IP Address is an IPv6 address, it cannot be filled into the Source AS field of C-multicast route (4-octet). 4. Considerations about Route advertising Efficiency In this draft, A-D route may carry a PMSI tunnel attribute. MCAST-VPN NLRIs with different PMSI tunnel attributes have to be advertised using different BGP update messages. Different multicast flows using different P-tunnels will be advertised using individual update messages. This can be acceptable. However, if multiple multicast flows are aggregated into the same P-tunnel, due to the different upstream/downstream labels in their PMSI tunnel attributes, they still cannot be combined into one update message. Maybe there is some space to improve the efficiency? For example, the label field in PMSI tunnel attribute could be moved into the NLRIs of A-D route. When multiple multicast flows are aggregated into the same P-tunnel, and each of these flows uses different upstream-assigned label, then it is likely that these flows belong to different MVPNs. As such, the routes that advertise these flows and their P-tunnel have different RTs, and thus should not be combined into a single BGP Update message. Yakov. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: our pals at ICANN, was Circle of Fifths
In message a123a5d60911060930i691985f0re23a12155dc38...@mail.gmail.com, Phill ip Hallam-Baker writes: On Fri, Nov 6, 2009 at 5:28 AM, Steve Crocker st...@shinkuro.com wrote: On Nov 5, 2009, at 11:30 PM, John R. Levine wrote: This is multiple pieces of nonsense: I actually don't think we have any serious disagreement here. =A0ICANN's management of the root zone is cautious for all sorts of reasons, and as= you note the root server operators have no plans to say no to what ICANN off= ers them. =A0It's always been clear that one reason is that the consequences= if any of the root servers felt unable or unwilling to accept ICANN's root would be too awful to contemplate, so it'll never happen. No, it's not too awful to contemplate. =A0Far from it. =A0As a matter of = prudent planning, consideration of the consequences of a root operator refusing to update the root zone is definitely something that ought to be part of contingency and disaster planning. So a contingency that a few posts ago you dismissed as 'nonsense' now turns out to be something that does require extensive consideration. But I note that you are actually discussing a different contingency, the consequences of a single default. Clearly the root operators are responsible to and accountable to the Internet community. I would expect that a default by a single root operator would be dealt with by ISPs redirecting packets sent to that IP address block to a different root. It is not that hard, it is merely a matter of the BGP cabal deciding that the expectations of the Internet community are not being met and adjusting accordingly. But that was not the scenario at issue. The scenario at issue was the case that it is ICANN that is considered to be in default. That is not going to happen because the consequence would be the end of ICANN. Some of the root operators would back the ICANN line of course, perhaps they all would. But if some part of the US government was to decide to abuse the degree of control it has over ICANN, other governments would respond in the same fashion and order their domestic ISPs to redirect traffic away to approved roots. The consequences for the Internet would be rather small. I doubt that there would be much disruption of Internet service. But the diplomatic dislocation would be huge and ICANN would be utterly broken in the process. The essential weakness of ICANN's position was recognized very early on, before the organization was founded in fact. And that is why it was tolerated in its current form. DNSSEC with a single root of trust would transform it from constitutional monarch to absolute monarch. No, it wouldn't. ISP's would just graft Cuba back onto the net. It requires a little reconfiguration to add a trust anchor for Cuba as well as the root but the world would route around such idiocy. This would be a little like SiteFinder. There would be a short disruption until the world routes around the idiocy. If new code is needed it would appear at about the same rate anti SiteFinder code appeared (read overnight). Having people respond to such concerns by saying 'trust me, you are paranoid' is not the way to win friends and influence people. As you admit in your own posts, the national security issue has been raised with you by the sovereign powers directly. Who do you think you are to dismiss those concerns as delusions? But to return to the original issue, ICANN has plenty of money if they wanted to support the IETF. =A0But the IETF needs to get organized enoug= h to ask in a way to which you and the rest of the board can say yes. You've just changed the subject from support for the root operators to support for the IETF. =A0The IETF situation was already discussed in deta= il. And that topic was avoided as well, which is hardly surprising. ICANN has already conceded the principle of supporting the IETF through the highly conflicted award of the .org contract to a group including ISOC. That is not a transparent or accountable mechanism. It sets up a whole series of conflicts of interest for the ICANN and ISOC boards. It would be much better to simply give the money in the form of a grant. Giving money to the IETF and W3C would provide a political support base that ICANN desperately needs. It would also be justified on the basis that ICANN exists to further the development of the Internet and that ICANN revenues are driven by increased use of open Internet protocols. -- = New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: NAT Not Needed To Make Renumbering Easy
In message a123a5d60911080822g3797e480h4bd9b01d8f3f2...@mail.gmail.com, Phill ip Hallam-Baker writes: We are so not in charge. Support for IPSEC is a requirement to describe an implementation as IPv6. That is all, it does not mean anyone has to use it, or that they will use it. There are two typical modes of deployment for IPSEC, the first is as a lousy remote access protocol where the lack of NAT support makes it far more effort than other solutions. SSL and SSH remote access just works, IPSEC VPN may or may not work depending on the phase of the moon. The third party clients are terrible, the built in support in the O/S is unusable because it does not have the tweaks necessary to get through the firewall. So we do not really have a standard for IPSEC remote access. The other mode for IPSEC is not really an Internet application, it is creating a virtual network by joining together a bunch of routers at local sites. Here the NAT issue is moot because the objective is to create a single network with a consistent IP address space. The fact that this is usually NAT space is not really relevant unless you are attempting to create an industry wide network. Have fun with that. What IPSEC has never got close to achieving is providing an Internet security solution in which packets are secure at the transport layer by default. The obvious reason for this is that IPSEC is not connected to a pervasively deployed PKI for authenticating the end points. There is no commercial infrastructure to support this today, and I doubt that there will be one for some time. NAT is relevant to this scenario only insofar as it will be aa fait acompli long before any PKI is established that might support pervasive IPSEC. And lest folk think I am picking on them here, the reason I raise problems is because I want to see them fixed, not just to carp. I want to deploy DNSSEC because I think that it is the most appropriate PKI to support packet level security. I use NAT for a very simple reason: I do not want my machines to be on the Internet by default. I only want my printers to be accessed by machines in my network. I only want the security system, the home automation system, the daleks, the lab, the coffee maker to be accessible from the network. I do not want Mr Coffee talking to strange computers, he has little common sense. Well give your printers a ULA addressand don't advertise the prefix. You don't need NAT to provide this seperation. Now I would like my network to have a greater geographic extent than just my house. But there is still a very clear distinction between machines that I own, that I am responsible for, that I want to connect to my network core and all the rest of the stuff on the Internet. Some computers, the desktops and laptops, I do want to have greater access, but there are only eight of them in total, that is a small fraction of my network. The ability to give these devices and IP address THAT WILL NOT ROUTE is very valuable to me as a security control. It is not a perfect control, but I have many, many layers to my defense in depth and I want all of them. We are not in charge of the Internet, but I am in charge of my network, and my policy is to use NAT. In a commercial environment, policy is everything. You do not get security from security technology, you get it from the security practices that the technology supports. Changing a security policy in a commercial environment is a very expensive affair. People are going to demand NAT66 (and cisco is going to support it) because it is cheaper to deploy NAT66 than change the policy. But even then, we are getting way ahead of ourselves. In the real world every network is going to have IPv4 devices on it for decades. I have a 36 plotter upstairs that is ten years old. I am not paying $3K to upgrade it just for the sake of IPv6. And your boxes will talk to it over IPv4 even if you don't have a external IPv4 connection. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
Sorry in advance for the length of the post and, in parts, the rudeness of my spleen. On 8 Nov 2009, at 17:55, Phillip Hallam-Baker wrote: I assert that regardless of whether NAT66 is a good or a bad thing, anything that layers on IPv6 must be NAT66 tolerant. In the whole of the foregoing discussion about NAT and IPv6, the question that I'm only really left with is whether or not we actually lost anything by doing NAT. I have never seen the link between the application layer and the network layer (or whatever you call these things, Layer being a highly inadequate term), and taking the effects of NAT and the resultant protocol drain by way of example, now no longer See what end-to-end connectivity is good for ... Until I remember FTP. And SIP. And IKE... And I question the quality expectations and degraded service the Internet's users have endured. The attitude is no longer that Address exhaust came, NAT pushes back the emergency but If it weren't for NAT, we'd have run out of addresses by now. You know, as if the botches we take for granted today are in any way good, as though the strategies we know and love to get around NAT are in any way acceptable, as though replacements for NAT-unfriendly protocols are somehow heavenly and divine. And whose idea was it to make the above protocols easily dependent on universal addressing, anyway? Was it necessary? It would only be fair to wonder how FTP and SIP would be, if designed today. It would be a shame not to mention WebDAV and, oh, Skype. And SIP, done today, would probably depend on connection reuse, fixed ports and no payload rewriting to get around NAT, those features being both desirable in NAT and of presumably great use in circumstances where realm translation happens, as with proxying where translating the IP or application header is absolutely the most you can do and where, presumably, NAT or similar can actually be justified for those who simply must have it. But one thing's damn certain, I will never, ever, ever configure a passive-mode FTP server behind a NAT ever again - not so long as the gateway supports FTP ALG but only if the behind-NAT FTP server pretends to be oblivious to the existence of NAT, while flopping completely if you try to be clever and set up ports and addresses to be given to clients. Worse yet, if it uses UPnP to open the needed holes. Do you care for a healthy Internet? I do. That sort of thing is beyond me, and I want somebody to tell me it's okay and it will all be over soon. And really, a lot of the excuses people give for keeping NAT are highly lame, in many instances suboptimal even for their intended purpose (source address spoofing behind NAT is my favourite argument against security held to be a value of NAT) and generally miss one or two points about the initial, healthy development of the 'net unencumbered by NAT. For a particularly aggressive take: http://www.fourmilab.ch/speakfree/ link And, of course, RFC 2993 is standard reading. So yes, I need to know why we put up with NAT, or why you think others should. I also need any justification you may have about why end-to- end is wrong or never held for the Internet's design, and if it did, why it did. While folk can postulate alternative universes in which enterprises will not demand or vendors refuse to implement NAT66, there is another area that is harder to wish away. Observation: Without NAT44 the internet would already have run out of address space. I don't think this can be seriously disputed. But see above. Observation: Without NAT46 and NAT64, we cannot transition from IPv4 to IPv6. Not now, no. It was the grand master plan though, back when. And, yes, capitalism and managers are to blame and, no, I don't feel the slightest sympathy for the slow movers who end in hot water because they didn't plan ahead. Really, it's a crisis whose only quandary is money and is entirely of their own making, and if they can't see beyond that point, it doesn't matter if they lose business. I don't know why the IETF keeps its hands out like that, when for years the clean start proposal was, while perhaps rather optimistic, perfectly adequate and, on the whole, of sound engineering. But now, vendors have begun pedalling the latest in CGN, and I'm tempted to imagine that if the transition had begun sooner there's a very real possibility the impetus and usefulness of IPv6 would have made the notion of CGN infeasible and unsellable. And don't get me started on the silly proposals to recycle unused IPv4 address space, they won't work longer than five minutes a time. Any market value those addresses may have is significantly outperformed by the real benefit of IPv6, when IPv6 is all there is to give. Still, FWIW, I see the transition this way: CGN (carrier-grade NAT) will happen now and in response to future demand on
Re: NAT Not Needed To Make Renumbering Easy
On 8 Nov 2009, at 16:22, Phillip Hallam-Baker wrote: There are two typical modes of deployment for IPSEC, the first is as a lousy remote access protocol where the lack of NAT support makes it far more effort than other solutions. SSL and SSH remote access just works, IPSEC VPN may or may not work depending on the phase of the moon. The third party clients are terrible, the built in support in the O/S is unusable because it does not have the tweaks necessary to get through the firewall. So we do not really have a standard for IPSEC remote access. There's at least one product making actual money in this space, Hamachi ( http://www.hamachi.cc/ ). Basically third-party-mediated IPSec-lite that goes over NAT. If you must use NAT, at least be aware of what can come back to your network due to NAT behaviour and internally initiated connections. I don't think NAT is providing the right kind of security here. But I must be careful not to start another flame war. But anyway, IPv6/Teredo does the same thing, and better; Microsoft is working on going that extra mile with IP over HTTPS, too, so soon we'll have peer-to-peer VPNs that really do Just work. In every case it is better than Hamachi's use of unassigned address space, and in no case better than fixing the trouble at the root, and shredding NAT. But, if NAT's your thing ... Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
On Nov 9, 2009, Masataka Ohta wrote: Anyway, checksum of ICMP error generated against ICMP echo must still be changed, and the error packet may (though does not usually have to) be fragmented. Sure, applications that use address referrals don't work well through NAT; we mentioned this earlier. ICMP is one of these applications. - Christian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates' to Proposed Standard
The IESG has approved the following document: - 'Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates ' draft-ietf-sip-eku-08.txt as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Cullen Jennings and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-eku-08.txt Technical summary. This memo documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with a Session Initiation Protocol (SIP) service. As such, in addition to providing rules for SIP implementations, this memo also provides guidance to issuers of certificates for use with SIP. Working group summary. There is consensus in the working group to publish this document. Document Quality There has been no indication of implementation. Personnel The document shepherd for this document was Keith Drage. The responsible Area Director was Cullen Jennings. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
