Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06

2013-04-25 Thread Andrew McGregor
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

2013-03-10 Thread Andrew McGregor
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.

2006-03-29 Thread Andrew McGregor


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

2006-03-24 Thread Andrew McGregor


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

2005-10-20 Thread Andrew McGregor


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 ...

2003-08-29 Thread Andrew McGregor
-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

2002-03-17 Thread Andrew McGregor

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

2002-03-17 Thread Andrew McGregor



--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

2002-03-09 Thread Andrew McGregor

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 -