Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Further to that, ifindexes of tunnels and PPP sessions can change dynamically as the bearer connection goes up and down, even if the interface has the same name and authenticated identity. That raises the interesting question of whether even the interface name is stable, as on many systems it is pure chance if the same name-identity mapping repeats itself. If you want a stable address, you want to use something that actually has the exact stability properties you require, and interface indexes and names are seldom what you actually need. Andrew On Thu, Apr 25, 2013 at 7:00 PM, t.p. daedu...@btconnect.com wrote: - Original Message - From: Christian Huitema huit...@microsoft.com To: Fernando Gont fg...@si6networks.com; SM s...@resistor.net Cc: RJ Atkinson rja.li...@gmail.com; ietf@ietf.org Sent: Tuesday, April 23, 2013 6:02 PM snip Instead, the draft goes into great details on how to actually implement the random number generator. Apart from not being necessary, some of these details are wrong. For example, the suggested algorithm includes an interface index, but different operating systems have different ways of enumerating interfaces, and the variations in enumeration could end up violating the stable address property. tp The ifIndex, as it appears in the IF-MIB is not stable; it can change on each and every re-boot of a system, depending on the order in which modules are loaded. It remains the same only until the next re-boot. I do not know what impact this has on the ipi6_ifindex as used in the IPv6 API, whether that in turn is unstable. (This is a property of the IF-MIB and is a reason why the YANG equivalent has used a name to index the interface table and not the index value, which may give the users of the YANG module, also currently in Last Call, an interesting migration problem). So if you want a stable address, perhaps you should not use the interface index. Tom Petch /tp I would suggest reworking the draft to separate a normative section, effectively a variation of the 3 lines paragraph above, and an informational section, the current specification of the algorithm as an example of a way to achieve this result if the operating system meets certain condition, like stable interface identifiers. I would also explain the inherent issues that have to be solved, e.g., swapping interfaces, or enabling multi-homed hosts. And I would observe that the DAD problem cannot be solved ina reliable way. -- Christian Huitema
Re: Time zones in IETF agenda
Heh. NZDT is UTC+13... Having just moved to Australia from New Zealand... NZ has better airline connections, especially for flying eastward across the Pacific. As for being far away... well, you get used to that. My personal definition of 'long flight' starts at 9 hours... 'short flight' would be less than 3. On Fri, Mar 1, 2013 at 4:53 PM, Dave Crocker d...@dcrocker.net wrote: On 3/1/2013 12:41 PM, John R. Levine wrote: I've said it before: just go back and forth between Iceland and Hawaii. Oh, and maybe Minneapolis for old-time's sake. ;-) New Zealand, please, in easy to remember UTC+12 A Brit who'd recently moved to Sidney said that he was still getting used to its relationship to the rest of the world: You fly for 8 hours, and then you start your trip. New Zealand is even better: You fly for /12/ hours, and then start your trip. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: Stupid NAT tricks and how to stop them.
On 29/03/2006, at 5:10 AM, Scott Leibrand wrote: On 03/28/06 at 7:00am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Agreed, but they reduce the amount of money you must pay to your ISP each month by a factor of ten or more. Your ISP charges you 9 times as much for IPv4 addresses as they do for bandwidth? I'd recommend switching ISPs. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. Not if you don't live in the US. There are no options here that are at all cheap. Usually you get a flat we don't do that. And they don't do v6 either. And people wonder why NATs proliferate... much of the world has no option but to live with them. This is a direct result of policy discouraging IPv4 address allocation. Andrew ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
On 24/03/2006, at 9:52 AM, Yu-Shun Wang wrote: Just another me-too data point about the Mac. It'll be good to know why that happened. Mine is a 15 Powerbook. I also brought a Cisco 11a NIC, and used it about 3-4 times w/out any problems. yushun The problem also occurs with Broadcom radios on PowerBooks under Linux, so it isn't OS X, it seems to be the Broadcom radio or its drivers. Andrew ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Venue Selection Criteria
On 20/10/2005, at 11:25 PM, Brian E Carpenter wrote: It's very hard to get those data. We've tried looking at how many local first-time attendees from (say) Korea later became regular attendees but the data are hard to state in any meaningful way and the time constants are long (years). There is no objective way to identify 'primary contributors' other than by assuming the regular attendees are also contributors. We certainly know that going a long way from most places, as we did in Adelaide, impacts attendance significantly - but my recollection is that Adelaide was a very successful meeting in terms of WGs making progress. As a data point, I'm now a regular attendee, and that is entirely because the Adelaide meeting was within the radius of where I could travel just to see if participating would be useful. As it turned out, it was and has been useful, certainly to me and my company and I'd hope to the IETF. Andrew ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Solving the right problems ...
-BEGIN PGP SIGNED MESSAGE- - --On Thursday, August 28, 2003 07:05:19 PM +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On woensdag, aug 27, 2003, at 19:51 Europe/Amsterdam, Fred Templin wrote: The hard part is coming up with a way to do the host/location mapping in a way that is simple, fast, cheap, secure, flexible and reliable. Wouldn't we all start deploying, e.g., HIP tomorrow if we had a solution for this? I'm not exactly current on what's happening with HIP but aren't there supposed to be working implementations today? There are. Four of them, in fact, but none are yet production quality. If anyone wants to play or read some code, these are the available ones: http://gaijin.iki.fi/hipl/ Linux USAGI, IPv6 only http://www.hip4inter.net/index.shtml NetBSD, dual stack http://www.sharemation.com/adm01bass/pyhip-2003-07-19.tar.bz2 Linux, Python in userspace (therefore needs no kernel IPSEC), dual stack There are drafts about the various mappings, but no implementation yet. There are also ideas around about how to transparently autodetect HIP support in the responder, with no a-priori knowledge. The (new) hipsec mailing list is at http://honor.trusecure.com/mailman/listinfo/hipsec. Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP07DOVGmVIGYWzvRAQFTHQP7BUYZ6x/jBX1s7yP3Oro5qEa28ABZumGY nOQwval68BsGkTjdX6qxrXbMNsnvNbLpIrY0u01/rthVSfDNTH4+FMLhUzjUl0+e 1K+H+2tygLmYCUPKf5xBOwKSgmwp9vaOMfC9EH1ZkaLmC2q7tFX3RJasBv41OG/u 1TyDMOXf5Vo= =G9KU -END PGP SIGNATURE-
Re: Netmeeting - NAT issue
Or, get a NAT which *does* connection-track H.323. They do exist, open-source and not, and work just fine. Better, get a proper H.323 gateway (which will work behind an H.323 aware NAT if done properly) so people can call in as well as out. However, NAT is still brokenness. (and so is H.323) Andrew --On Tuesday, March 12, 2002 15:17:35 -0800 Joe Touch [EMAIL PROTECTED] wrote: NAT doesn't support Netmeeting. It uses H.323 encoding, which uses IP addresses and dynamically assigned ports in-band (inside the connection). The NAT is translating the outer IP addresses, but because your NAT doesn't understand H.323, it doesn't know it would have to also translate the inner addresses and ports. Netmeeting expects that it can dynamically select a port to use to connect back to your machine, but that defeats what a NAT thinks the Internet looks like (notably because it's incorrect). The best solution: get real IP addresses. It's cheaper than wasting your time figuring out why things don't work. Joe
RE: Netmeeting - NAT issue
--On Sunday, March 17, 2002 18:51:48 -0800 Peter Ford [EMAIL PROTECTED] wrote: If one really believes in end to end architectures, then one probably would want generalized protocols for supporting hosts telling the network what to do wrt opening holes at NATs/Firewalls for inbound traffic. Doing this form of traversal mapping on a protocol by protocol basis (e.g. H.323 gateway, SIP proxies, etc.) does create an interesting market niche for the firewall vendors, but it is not clear this is the right model for the long term. I don't think it is; my suggestion below was merely practical. Microsoft has recently addressed the NAT traversal issue for multimedia scenarios by shipping Messenger in Windows XP and it uses universal plug and play protocols (www.upnp.org) to open holes on upnp capable internet gateways. There are many vendors building upnp capable NATs in 2002. Nice. Even if the *AT* in NATs go away, the reason people buy them won't. There needs to be a way for applications and firewalls to coordinate - perhaps in the same way that highway designers and car designers usually agree on the basic design parameters of on/off ramps. I agree; it's going to be hard to secure, but I guess that's what makes it interesting. Regards, peter -Original Message- From: Andrew McGregor [mailto:[EMAIL PROTECTED]] Sent: Sunday, March 17, 2002 5:34 PM To: Joe Touch; Vivek Gupta Cc: [EMAIL PROTECTED] Subject: Re: Netmeeting - NAT issue Or, get a NAT which *does* connection-track H.323. They do exist, open-source and not, and work just fine. Better, get a proper H.323 gateway (which will work behind an H.323 aware NAT if done properly) so people can call in as well as out. However, NAT is still brokenness. (and so is H.323) Andrew --On Tuesday, March 12, 2002 15:17:35 -0800 Joe Touch [EMAIL PROTECTED] wrote: NAT doesn't support Netmeeting. It uses H.323 encoding, which uses IP addresses and dynamically assigned ports in-band (inside the connection). The NAT is translating the outer IP addresses, but because your NAT doesn't understand H.323, it doesn't know it would have to also translate the inner addresses and ports. Netmeeting expects that it can dynamically select a port to use to connect back to your machine, but that defeats what a NAT thinks the Internet looks like (notably because it's incorrect). The best solution: get real IP addresses. It's cheaper than wasting your time figuring out why things don't work. Joe
Re: PPP
That top-layer-calls-next-layer etc ad-nauseam model seems to have been one of the original ideas for how to implement a stack. Actual current implementations do all kinds of wierd stuff, but mostly pass around accumulating collections of buffers; so the payload buffer doesn't get copied to accomodate each new header, instead the kernel has a second buffer to contain the header (and later layers can add more). What gets passed around (by way of various queues and internal plumbing schemes) is a structure of pointers to pieces of packet, which gets put together on transmission, often by the DMA engine in the device or by the device driver. The layering is just a conceptual model for the logic of what is going on, and has no resemblance to the flow of control in a typical actual implementation. There are simple educational implementations that follow the layering fairly closely, and they are interesting to read but tend not to be practical for high performance applications. --On Tuesday, 5 March 2002 11:02 p.m. -0800 Christopher Evans [EMAIL PROTECTED] wrote: Here is a question that will tax your synapes to bursting point! How is PPP and TCP/IP libs wired together? Like, DO I (OSI 8) call TCP and it calls IP and down the chain till it spills over and gets real physical (OSI 1)? I am confused. At 10:02 AM 3/5/02 -0500, you wrote: whoa, it's in the TCP/IP suite, it's not. So let me get this straight. TCP and UDP are part of IP. TCP provides error sum UDP doesn't and is therefore faster than TCP. They are encapsulated in IP, which is put into the data bitstream of a PPP frame. Layer 1 is the physical layer, are bitstreams sent at that level. BTW I have 56K dial-up no ISDN or DSL. - Original Message -