RE: ORCID - unique identifiers for bibliographers
I do have an identical twin brother, and hashing the DNA sequence collides more regularly than either random or MAC-based interface-identifiers in IPv6. Also, he doesn't have the same opinions. Greg Daley From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Phillip Hallam-Baker Sent: Tuesday, 17 September 2013 11:33 AM To: John Levine Cc: IETF Discussion Mailing List Subject: Re: ORCID - unique identifiers for bibliographers On Mon, Sep 16, 2013 at 3:45 PM, John Levine jo...@taugh.commailto:jo...@taugh.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since this has turned out to be ambiguous, I have decided to instead use a SHA-256 hash of my DNA sequence: 9f00a4-9d1379-002a03-007184-905f6f-796534-06f9da-304b11-0f88d7-92192e-98b2 How does your identical twin brother feel about this? His opinion is identical to my own. -- Website: http://hallambaker.com/
RE: Backwards compatibility myth [Re: Last Call: draft-weil-shared-transition-space-request-14.txt]
Hi Randy and Brian, I am sure the discussion of the discussion has been had before, but: IPv4 provides no mechanism whatever for addresses greater than 32 bits. Therefore, mathematically, there is no possible design for an IP with bigger addresses that is transparently backwards compatible. We've known that since at least 1992. i guess you forget the discussion of variable length. i hope we don't have to rehash it here. decisions were made. some were quite bad. v6 had some real zingers. remember tla/nla? no feature parity, such as dhcp (a war which has not finished)? it is almost as if it was designed to fail. randy I think that the compatibility issue is a key reason why adoption has been difficult. Others are: No compelling IPv6 only features - From my reading several key features were directed at IPv6 only originally, like IPsec. Successive works to provided all non-address IPv6 features in IPv4. - This in part is being addressed by helpful capabilities such as DHCPv6PD (although we could kill things entirely by back porting this to IPv4 ;-) No local use benefit - Ostensibly deploying IPv6 only gets you (slightly) more work. - compare this to transformative technologies such as Ethernet and IPv4, which had a better price point and enabled new local capabilities, which did not rely on neighbours adopting the same protocol. Of course, these are short-sighted analysis. Being able to uniquely address a peer device is a key benefit which we will see drive adoption once 103.X/8 is gone. Another key benefit is local addressability which handles organizational merges/changes/private peering with ULAs (resolves the RFC-1918 collision problem). For a few years I have been involved in an extremely pragmatic market where people want to see the money they will save by deploying a networking technology. What would get my customers adopting would be a compelling TCO argument. Sincerely, Greg Daley Solutions Architect Logicalis Australia Pty Ltd gda...@au.logicalis.com t +61 3 8532 4042 m +61 401 772 770 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Hi Doug, We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today. This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today. This has been covered many times, but once more (with feeling) ... The problem that 4941 is designed to fix is to avoid being able to track the same user on *different* networks. This is possible because by default the host portion of the address remains constant, and theoretically globally unique. Privacy for a user that is always connecting through the same network is a whole different basket of bagels. We have not had carrier NAT solutions until walled gardens came in with 3G networks, and now people are mooting CGNs, but I have not seen many in general use for access networks. Up until now, we have migrated addresses when a new PDP-Context, PPP (Dialup/xDSL) or DHCP Lease has been supplied. In IPv4, the session uniquely identifies/identified the session and links to the user during that interval. The same is true for IPv6, except that IPv6 defaulted to MAC based IIDs. With 4941, the same Layer 2 identity is removed, and we have the same circumstances with IPv4 and IPv6. So CGNs for IPv4 are an answer to a new question that you pose where the implicit assumption is that it is insufficient to maintain address unlinkability between different PDP-Context/PPP/DHCP sessions. Given that we have good local addressing mechanisms in IPv6 (ULA, Link-local) and automatic global prefix configuration mechanisms (SAA/RA/DHCPv6/DHCPv6-PD), I would like to know: What are the advantages of CGNs for IPv6 and does the cost to application development justify the change? Sincerely, Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NATx
Hi Martin, As long as the current IPv4 characteristics are not transparently available with IPv6, it will probably deter adoption of IPv6 for the installed base. I would argue that this is a commonly held incorrect view: The problem is not that feature sets are unavailable, but that there is no compelling local economic case for installing IPv6. IPv4 networks could not do everything that IPX networks were doing when the Internet boom occurred. There was a compelling local use case which drove parallel adoption. What we should be doing is identifying the key features of IPv6 that cannot be addressed by IPv4, and ensuring that these are available. If these are good enough, IPv6 will be deployed. Today the only feature IPv6 has which is absolutely better than IPv4 is end-to-end addressability. Introducing CGNs places a barrier to this addressability. Really if you want address-user unlinkability, use HMIPv6 or some other signalling based protocol to get temporary addresses in the carrier. At least in that case the applications will know their addresses because they will be locally configured. Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
Hi Mark, Adding a address range as non-public to existing equipment is a lot easier than adding IPv6 so that you can use DS-Lite. Much CPE equipment doesn't have the flash capacity to do the later. The former is trival provide the company that supplied the fireware is still in business. I'm mixing this conversation with the discussion on Class E, because I think that your responses are perhaps less true if the address space is sourced from that block. I would contend that attempts to use non-traditional (Class A/B/C) addresses will not be trivial for two reasons: Firstly there are inherent assumptions in the uses of particular address classes which can be littered through code. This is a similar issue to the signed-integer time_t issue (though perhaps simpler, still not trivial). Additionally, host communicating with address classes outside the predefined unicast set may not be able to reliably connect to older IPv4 devices, or devices on specific networks (e.g. with existing Bogon filters). Class E relies upon the endpoint understanding the format and purpose of the address in a similar fashion to IPv6. From my point of view, CGNs and Class E usage are part of a continuum of IPv4 address quality degradation. I'm not against these addresses being used, but would seek to ensure that any uses of addresses in this fashion reflects the current internet environment, and doesn't require engineering changes on third party, legacy devices. Sincerely, Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Hi Martin, The assumption that information is present only within the IP address is erroneous. This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack. We have local source address selection mechanisms in recent Windows versions that use randomized IIDs on outbound connections today. This doesn't prevent exposure of the information regarding the internal network structure, but nor do firewalls at publically addressed IPv4 institutions today. Putting NATs on the path just causes the device inside the network to be unaware of its presented addresses, which means that it will impede peer-to-peer communications, as it cannot even describe its available services without external information services. This is the awful situation in IPv4 today: Address scarcity is not the problem, addressability is the problem. Greg Daley -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Martin Rex Sent: Tuesday, 6 December 2011 1:00 PM To: mail-dated-1325290081.a3a...@sabahattin-gucukoglu.com Cc: ietf@ietf.org Subject: Re: Netfilter (Linux) Does IPv6 NAT Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working- on -NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. I fail to understand the issue that you have with this. Doing home gateways and *NOT* using dynamic temporary IPv6 addresses for outbound connections by default (i.e. *NO* static network prefix that can be linked to a single ISP customer) would be extremely irresponsible with respect to data privacy protection. Without that, I consider IPv6 a complete no-go. And many DSL routers are based on Linux, so having an implementation of such a NAT is a prerequisite before IPv6 can be reasonably offered to home customers in Europe. I'm perfectly OK with folks getting static IPv6 network prefixes for specific applications that desperately need it. But the default definitely ought to be temporary dynamic IPv6 addresses, especially for outbound connections. -Martin ___ 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: Netfilter (Linux) Does IPv6 NAT
Hi Martin, -Original Message- From: Martin Rex [mailto:m...@sap.com] Sent: Tuesday, 6 December 2011 1:30 PM To: Greg Daley Cc: m...@sap.com; mail-dated-1325290081.a3a4e0@sabahattin- gucukoglu.com; ietf@ietf.org Subject: Re: Netfilter (Linux) Does IPv6 NAT Greg Daley wrote: The assumption that information is present only within the IP address is erroneous. This has been studied for mobile IPv6 users as well, and there is information leakage up and down the stack. Your reasoning is obviously flawed. Having a temporary dynamic IP address assigned will not prevent any negligent or privacy-ignorant protocols and apps higher up the stack to reveal identifying information about you. My point is that it is unhelpful to ignore the principles underpinning IPv6 architecture in order to fail to achieve your privacy goal. But _without_ a temporary dynamic IP address, each and every of your network communcation will be 100% identifyable as you for everybody that can oberserve you IP datagrams floating by, even when you're using IPSEC. Yes, when your outbound sessions hit the internet, devices on the path can see where you come from. In my world, these people can see what they can already learn from watching my IKEv1 aggressive mode identity (if not using certs) or WWW cookies, or TCP stack behaviour and use profile. In your world you gave up peer-to-peer IPSec, SIP, etc initiated from either end to gain a false feeling of privacy. I fail to understand what you mean by randomized IIDs. What you need is a temporary network address randomized by you ISP so that your address blends within the entire customer base of that ISP. Please read RFC 4941 Privacy Extensions for Stateless Address Autoconfiguration. Putting NATs on the path just causes the device inside the network to be unaware of its presented addresses, which means that it will impede peer-to-peer communications, as it cannot even describe its available services without external information services. Asking your border router for the temporary external IP-Address is trivial compared to performing a secure DNS lookup. I have no interest in comparing apples to oranges. I have implemented ICE and I can say it is non-trivial. Sincerely Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Dear Martin, I think you're confused. Whatever IPv6 source address is in the outgoing packet from the CPE is bound 1:1 to the subscriber. You can't conceal the address of the subscriber, if you ever want to get any packets back. The outgoing packet is bound 1:1 to the ISP of the subscriber, any only the ISP knows to which of his customers he is routing the datagrams during any specific point in time. The DHCP lease should be 24h at most and the ISP is bound by data protection laws to not make the mapping publicly accessible except under very specific legal exceptions. I do not know if this is a current environment, or what you would like to see (A reference would be good). If you wish to rotate through address space, you could still use the 24 hour lease either as a replacement for or in addition to your static prefix in IPv6, but you do not need to use NAT. One would use DHCPv6-PD to request the lease for a period, Router Advertise it downstream to your devices, which use it only for 24h, and at the end of the time return the prefix to the pool. The mapping then becomes a routing one, rather than a NAT one, and the routing mapping only exists as long as the connection is available (if using PPP) AND the DHCP lease is held (under the same rules or laws you indicate). While I do not think there is an option to return this prefix to the pool, and assign me a different prefix, it would be trivial to implement, and would not create a barrier to sessions like NAT would. (Note that I would decouple the prefix return and assignment to de-link them in time). This is presented as a counter-example to NAT is the answer, because this is a technologist perspective, and there are other solutions. What we should really be doing is engaging with industry to identify the actual need, not choosing technical paths because of their feasibility in code. Sincerely, Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Netfilter (Linux) Does IPv6 NAT
Is the problem that they don't get what IPv6 is for? Or that we haven't articulated the use cases appropriately? Alternatively, Is there something they are trying to achieve other than more=good? Greg Daley -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Thursday, 1 December 2011 11:08 AM To: ietf@ietf.org Subject: Netfilter (Linux) Does IPv6 NAT In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on- NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ 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: Advance travel info for IETF-78 Maastricht
I wasn't in Dublin, so I don't know the issue there. Was the problem like in Vienna? I have to say, that I didn't find Vienna a problem at all. There was a great mass transit system, and a two minute train trip to all the restaurants in the centre of town. I don't often stay at the venue though, so I am used to a hike. Greg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Make the Internet uncensorable to intermediate nodes
Hi Mark,
You are incorrect. I am not referring to IPSec, VPNs or Secure Shell.
I am not even referring to TOR (I don't put the solution before the problem).
I am referring to the goal:
1) Unsnoopable
2) Untraceable
The set {IPSec, VPNs, SecSH} meet only the first of these.
There is a functional difference between IETF continuing to work on
protocols associated with 1), which there is a commercial need for today,
and embarking upon standardizing protocols which address 1) and 2),
for which the purpose is political.
I am not opposed to this work.
Does it have to be standardized, and does it have to be IETF?
With regard to affronting hosts, I would think that anyone who visited
a home or a country would behave politely.
I am always polite and respectful of people in the USA when I visit, and
understand it is a privilege (as a non-Citizen) to be there.
My message alluded to the fact that there are different patterns of
politeness in many East Asian countries. One of the issues is that
politicising IETF work would put our peers in China in an untenable
position with regard to the authorities.
These are the people we are going to China to engage with and encourage.
The people you may be angry with are not these people.
Please take the political activism somewhere else, where it will be more
effective.
Sincerely,
Greg Daley
From: Mark Atwood [mailto:m...@pobox.com]
Sent: Wednesday, 24 March 2010 2:16 PM
To: Greg Daley
Cc: MtFBwU; ietf@ietf.org
Subject: Re: Make the Internet uncensorable to intermediate nodes
On Sun, Mar 21, 2010 at 11:24 PM, Greg Daley
gda...@netstarlogicalis.com wrote:
I would actually not encourage IETF to work on such a
technology as this,
particularly in the lead-up to IETF Beijing. That would be a
serious affront
to our hosts.
By as this, you are referring to both technologies such as Tor, and
also similarly useful technologies as IPsec, VPNs, and Secure Shell, all of
which are useful and are used today to Make the Internet uncensorable to
intermediate nodes.
The Chinese government seem to be excessively affrontable, and entirely
too many westerners are enablers of this. It's insulting, by western
standards. If the west has to worry about insulting China, then China
can get a clue about being insulting to the west. The Chinese government can
grow a thicker skin.
..m
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: Make the Internet uncensorable to intermediate nodes
Dear MtFBwU, Please excuse my weasel words. My country is apparently about to adopt an internet censorship scheme. I'm not happy about it, but I'm unlikely to build a system to circumvent the protection. I would actually not encourage IETF to work on such a technology as this, particularly in the lead-up to IETF Beijing. That would be a serious affront to our hosts. It is quite important to ensure that the IETF particularly is not subject to any external party's agenda in the lead-up to the meeting. In purely technical terms, there is a conflict with IETF's existing routing practices which are shortest (routing) path oriented, so that communications between pairs of devices will send most or all channels of data down the same path. Any form of communications which sends multiple elements down the same routing path is subject to collation and correlation by an intermediate agency, assuming that they use the same correlation mechanisms as the end-nodes. So that means using diverse data paths, or creating some sort of protected payload is required to ensure that only the parties to a conversation can receive the data. If there is a portion of the data which can be exchanged out-of-band, then a protection scheme can be negotiated there, or the sensitive content can be sent with the remnant providing only innocuous context. Alternatively, a system which can send data out-of-band which the parties can use to shuffle the data so that sensitivity is reduced. In some environments use of such shuffle techniques and out-of-band channels is not legal, and I wouldn't encourage anyone to act illegally. Out-of-band communications schemes such as have been mentioned are likely to be focussed on by authorities. Participation in particular schemes could get someone in trouble. Systems which increase the apparent entropy of a communication path could even be detected, and local endpoints (for example within a protected zone) could be identified based on the increased entropy. This would be dangerous for the participants, especially if they thought that the channel they had was unidentifiable. IETF's job is to make Standards, which are reliable, stable and widely available. Regardless of the focus of a protocol (routing, privacy or reliability), it's not sufficient to create a system which is good-enough for today, but could be dangerously ineffective tomorrow. I believe this is something which is not something IETF should rush into willy nilly, ideology of participants aside. Sincerely, Greg Daley ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [77all] No Host for IETF 77
How about getting a corporation's IPv6 prefix aligned with their name? 2001:c0ca:c01a::/48? Greg -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Tuesday, 23 March 2010 11:47 AM To: IETF Discussion Subject: Re: [77all] No Host for IETF 77 Ever had a dot on your badge? Well this is your chance. ... You can buy a green dot at the registration desk for your badge for $20. Oh boy. There's a model for the way to pursue this, from highway beautification sponsorship. Might be interesting to walk down the IETF halls, with signs along the way, stating that this person or that person has has sponsored a segment of the hallway... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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
Malthus ( was RE: Motivation to submit an idea in IETF?)
Hi Dean, Sorry while I interrupt your melancholy ;) Its' a good read as well, and I highly recommend it; my depressing theory, however, is that we're falling off the tail of the success hump and sliding back into a strictly Malthusian model of supply, demand, and starvation. -- Dean If (as I guess) you are right that demand outstrips our ability to generate resources, then the least we can do is push back the barrier by making things more efficient. IETF protocols have been one of the mechanisms which have significantly reduced the cost of deploying useful robust communications networks. Eventually, this may reach a point where networking is commodified beyond the point where companies have an interest in flying staff around the world to attend meetings. I hope that by that stage we will have done work enough to eat our own dog food and run equally as effective (and more efficient) meetings online. Notably, I have attended via work, and self funded (intermittently). My finding us that it is hard to get a company to stump up cash for IETF trips unless they have a pecuniary or academic (which I guess is similar) interest. Greg ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Motivation to submit an idea in IETF?
Hi Ashishek
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Behalf Of Abhishek Verma
Sent: Friday, 22 January 2010 12:31 PM
To: Paul Hoffman
Cc: ietf@ietf.org
Subject: Re: Motivation to submit an idea in IETF?
Hi Paul,
At 6:27 AM +0530 1/22/10, Abhishek Verma wrote:
I spoke to several people offline and i couldnt get any
good answers.
I suspect that you got many good answers, maybe all
different. The fact that many people have different
motivations for submitting their work to the IETF instead
of {something else} is a feature, not a bug.
And what are those motivations? Wouldnt patenting be the most obvious
thing to do?
The typical response was that most ISPs prefer multiple
vendors, and a
patented solution will cause issues as the other vendor
will not have
that support. Is this the only reason?
No.
This may not be the only reason, but is this a valid reason at all?
(Please note that my response is informational only and does not constitute
comments on any IETF policy or existing IPR claim.)
I think that whetever the reason, documents submitted to the IETF
are less likely to become standards track RFCs if there is critical
IPR which must be licensed in order to construct the protocol.
The IPR BCPs for the IETF enforce disclosure of known IPRs when an idea
is submitted for consideration. This tries to make the issue above board.
When IPR becomes known, unless it is accompanied by permissive license
statements
the community often prefers unencumbered technologies. This allows the
standards
to be adopted by the widest number of users on the Internet, regardless of
whether they have money to pay license fees.
In terms of benefits which may be acquired by submitting IPR-free or
royalty-free IPR ideas to IETF, there may be value purely from creating a common
protocol to talk between vendors, an end-user may wish to drive standardized
solutions where no or vendor only solutions exist, or there may be a desire
to make the Internet better from a community interest point of view.
As far as I know, in terms of creating or adding value to a business aligned
with work on IETF, there may be additional non-IETF focussed systems which can
be built on-top of, or around an unencumbered idea. Such peripheral IPR could
then be used to build a business case with some protection. It may require
some sophistication to ensure that the external idea/IPR does not impinge upon
the
IETF submitted idea.
Please note that I am not an expert on this and you would need an Intellectual
Property Lawyer to look into the issue, if your business depended on building
IPR.
I hope this helps,
Sincerely,
Greg Daley
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
RE: NAT Not Needed To Make Renumbering Easy
Hi Dean, I appreciate that this is a realistic challenge for one of the key users of the technology. As a key user of the technology. Why didn't we learn about this earlier in the process? Perhaps if we did, we could have supplied a solution which doesn't suck as badly as NAT. I am quite interested to know your opinion. Was it because we weren't looking to meet the customer's need, a breakdown in requirements specification, or something else? Sincerely, Greg -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dean Willis Sent: Wednesday, 28 October 2009 3:02 AM To: Sabahattin Gucukoglu Cc: ietf@ietf.org Subject: Re: NAT Not Needed To Make Renumbering Easy On Oct 25, 2009, at 10:49 AM, Sabahattin Gucukoglu wrote: Not in the IPv6 address space, anyway. And if it is, there's something wrong and we should put it right. Just been reading IAB's commentary on IPv6 NAT. It seems to me that we are perpetuating the worst technology in existence *simply* for one feature, network mobility, that is better served by proposing new techniques and technologies and, in particular: we need a simple way to express host relationships inside an organisation that is independent of external homing. I refuse to suffer because of NAT any longer and don't want to accommodate those that prefer it. If IPv6 does ever get wide enough deployment, and I truly hope it does, I might just *give up* things to accommodate the trouble-free life that is no NAT. What do we have right now, first? As I understand it, the folks really pushing for IPv6 NAT are from the US department of defense. Let's consider a battlefield operation. We have a hierarchical organizational structure. At any given level, there are a collection of numbered boxes. For example, consider infantry companies, of which there might be 8 or so in an infantry battalion. Company A has a bunch of networked boxes, A1, A2, A3, and so on. Companies B, C, D, and so on have the like. A1 is configured exactly like B1, C1, D1, and so on, with the same IP addresses, passwords, default routes, everything. The inter-layer boxes use NAT to make everything work, even that we have re-used local addresses at every level of the hierarchy. The battalion command post may also have some spare #1 boxes, #2 boxes, etc. Assume artillery falls on the command posts for Company A and Company B and blows up some of their boxes. Recovery may necessitate combining the networked boxes and command structures of both companies. So, while getting shot at, the network techs are busy running boxes back and forth. Let's make a simple case: Boxes A2, A5, and A7 got hit, so they're replaced by B2, B5, and B7. B3 and B4 are also hit, bringing the B network down completely Meanwhile, the battalion guys are shipping out spare #2, #3, #4, #5, and #7 boxes to company B. The B-boxes need to work instantly when plugged-in as replacements for A boxes. There's no time for manual reconfiguration, probably no time for dynamic topology discovery, or anything else. The techs on the ground don't have the passwords, equipment, or know-how to reconfigure the boxes anyhow -- mostly, they just know to plug wire 1-4 into box 1 port 5. And the same goes when the spare boxes from the battalion level arrive at company B -- they have to plug in and work instantly without renumbering anything. NAT is the glue that makes all this work with minimal reconfiguration, and isolates what manual reconfiguration is needed to a specific set of boxes at interconnect points, for which standardized procedures can be developed that allow topology to be reconfigured on demand under very difficult circumstances. Keep in mind that all this stuff also has to be wrapped in military- grade crypto, resist Tempest-style interception, remote radio data insertion attacks, jamming, and sorts of protocol attacks, so brutal simplicity is the by-word of the day. We can't have a network fall apart just because some enemy sapper managed to clamp a rogue Linksys access point with a DHCP server onto a wire somewhere ... So, if IP applications and protocols worked entirely differently, we could get away without NAT in IPv6. We'd kind of hoped that things like Bonjour and multicast service discovery and P2P would have matured fast enough to plug the gap, but so far they haven't been seen as adequate (and I'm not an expert on why not). Plus, the military mindset is understandably reluctant to change things that work. And since NAT made all this stuff work for IPv4, they're planning to use it for IPv6 too. -- Dean ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reduce jitter in routed network for voip applications
Hi Daniele, Daniele Giordano wrote: RTP is transparent at the transport layer. We analyse TCP and UDP: TCP is connection oriented and so the communication begins with the definition of a virtual circuit. A virtual circuit is a temporary connection of sequence nodes with relative reservation of bandwidth. A connection oriented service gives the certainty that all information units use the same nodes with a same medium latency. Same latency maintains reduced the jitter. [chop udp discussion] What do you think about this? TCP does induce delay variation when retransmission is considered. End-to-end retransmission of VoIP is not useful in many cases. TCP by default does this. The additional mechanisms in TCP to throttle transmissions when multiple duplicate ACKs are seen will reduce the rate of transmission in some cases for VoIP. This will also cause packet delay variation. TCP is not well suited to VoIP for these reasons. Additionally, UDP and TCP packets travel through the network at the same rate (if no differential forwarding is used). The premise that TCP and UDP have different properties on the forwarding plane is thus flawed. Greg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: anti-climatic odometer sighting
Hi Michael, Michael Richardson wrote: -BEGIN PGP SIGNED MESSAGE- So, I noticed that RFC4003 was issued. Wow, so we passed the 4000 mark. I went to find out what rfc4000 was. Aha... not yet issued. That's kind of anti-climatic. Oh well. Maybe 4096 will be more fun :-) indeed: 10^3 Our first real milestone. Greg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Authors soliciting comments
Hi Fred, I've previously worked with the Bureau of Meteorology (BoM) here in Australia, and they propagate several of these type of warnings between meteorological, seismic and aviation agencies here and around the world using message switching systems. The Internet is used for dissemination in a number of ways. In the late 90's tcp/telenet sessions were in use on extranet/leased line links, and pager, fax and other direct to the public warning dissemination systems were in use. It's probably worth trying to get input from existing agencies tasked with this role in various countries, and some organizations (such as the World Meteorological Organization) may be interested in contributing time and effort in this direction, but I don't know. Perhaps there are also existing systems which may be used as a model. Unfortunately, I don't believe that there is an actively monitored tsunami service in the Indian ocean, which may have been able to transfer such warnings. The role of a generic, authenticated, internet-based warning system may be useful in furture though. Greg Daley Fred Baker wrote: Date: Tue, 11 Jan 2005 15:36:10 -0500 Subject: I-D ACTION:draft-baker-alert-system-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Structure of an International Emergency Alert System Author(s) : F. Baker, B. Carpenter Filename: draft-baker-alert-system-00.txt Pages : 19 Date: 2005-1-11 The authors propose a way in which people could be warned of an impending event in a geographic region. This is similar to and may use services such as the US Emergency Alert System, but differs in that message distribution is targeted only to the affected locality. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-alert-system-00.txt To remove yourself from the I-D Announcement list, send a message to [EMAIL PROTECTED] with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username anonymous and a password of your e-mail address. After logging in, type cd internet-drafts and then get draft-baker-alert-system-00.txt. A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: [EMAIL PROTECTED] In the body type: FILE /internet-drafts/draft-baker-alert-system-00.txt. NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the mpack utility. To use this feature, insert the command ENCODING mime before the FILE command. To decode the response(s), you will need munpack or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with multipart MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY - In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select Messaging, Email-Related, Mail Routing Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique
Re: Why, technically, MIP and IPv6 can't be deployed
Hi Francis and Ohta-san. - Original Message - From: Francis Dupont [EMAIL PROTECTED] Date: Wednesday, November 10, 2004 2:15 am Subject: Re: Why, technically, MIP and IPv6 can't be deployed In your previous mail you wrote: Could you describe why exactly IPv6 can't run on the (layer 2?) WLAN infrastructure? That ND extensively, without any valid reason to do so, use multicast, which is not acknowledged at WLAN L2, means IPv6 or its ND is unreliable over congested WLAN. If multicast ND packet is lost by congestion, it is not retransmitted by L2. = Masataka san, your argument is right (I saw 40% lost rate on multicast over IEEE 802.11b) but it applies to IPv4 (ARP uses broadcast) too... I understand this is the case, but we can still modify the hosts to do something about it. Multicast or Broadcast are necessary if we want generic address discovery in IPv4/6 networks. Obviously we'll have problems with MAC level acknowledgements for messages received by multiple hosts. RFC 2461 (as described by a recent individual submission of mine) allow Neighbour cache entries to be created with reliable 802.11 MAC transport (unicast toDS=0,toDS=1, multicast toDS=1) where there is only one MAC recipient in the contention domain. This may be done to preemptively place neighbour cache entries into first hop routers. Since Ohta-san mentioned MIPv6 here, the router becomes the most relevant peer for neighbour discovery. The mechanism doesn't require protocol modification, and is available today (If it's practically helpful, and implemented). It may need some further documentation though. Greg Daley draft-daley-ipv6-preempt-nd-00.txt This has been implemented in 40 lines of C in the Linux Kernel. Results, while early are fairly promising. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Why, technically, MIP and IPv6 can't be deployed
- Original Message - From: Masataka Ohta [EMAIL PROTECTED] Date: Wednesday, November 10, 2004 2:50 am Subject: Re: Why, technically, MIP and IPv6 can't be deployed Francis Dupont wrote: Could you describe why exactly IPv6 can't run on the (layer 2?) WLAN infrastructure? That ND extensively, without any valid reason to do so, use multicast, which is not acknowledged at WLAN L2, means IPv6 or its ND is unreliable over congested WLAN. If multicast ND packet is lost by congestion, it is not retransmitted by L2. = Masataka san, your argument is right (I saw 40% lost rate on multicast over IEEE 802.11b) but it applies to IPv4 (ARP uses broadcast) too... Yes, it does, but not so badly. ARP actually use broadcast for request but not for reply. ND uses unicast for replies (Router Discovery may not though). Moreover, ARP request from terminals to base stations, which are often routers, are unicast at lower L2. Same with ND. Same with _any_ MAC unicast with toDS=1... So, over WLAN, ARP works a lot better than ND. It should also be noted that, with IPv4, it is natural to have link specific adaptation mechanism for each different link type that it is perfectly fine to have IP over WLAN which is different from IP over Ether. Your premises are incorrect, the comparisons you are using are invalid. On the other hand, ND, an attempt to have a universal adaptation mechanism ignoring link specific properties, which contradicts with the very basic reason to have adaptation, is a total failure. Really, so does ARP, except where it's not supported, and requires servers. It should be noted that MIPv6 is hopelessly tainted by ND. I'l take hopeless ND taints any day. The ND architecture as part of IPv6 (rather than the link-layer) allows L3 neighbour security mechanisms to be implemented once in IP. I think that retransmission timers, and ordering of messages in ND can be altered. The insecurity of ARP cannot. Which do we need for the future 10-15 years of the Internet? Greg ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Oz Bar BoF Time and Place proposal.
Hi, Sorry for not sending this out earlier, but thought I had. I was thinking of meeting in the hotel lobby after the plenary session on Wednesday night, and proceeding to the Childe Harold Saloon down Connecticut Avenue http://www.childeharold.com/directions.html Please tell me if this is suitable or we need a better time or venue. Greg ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: RE: RE: Oz Bar BoF @ IETF 61
Hi Tom, - Original Message - From: Thomas Gal [EMAIL PROTECTED] Date: Friday, November 5, 2004 7:53 pm Subject: RE: RE: Oz Bar BoF @ IETF 61 What secret? That nobody in Australia actually drinks Fosters? -Tom [EMAIL PROTECTED] What! don't tell them that! Now they'll all come to the BoF... Greg ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: RE: Oz Bar BoF @ IETF 61
Hi Eric, - Original Message - From: Eric Burger [EMAIL PROTECTED] Date: Saturday, November 6, 2004 10:02 am Subject: RE: Oz Bar BoF @ IETF 61 Would I count as Australian if I like Australian Wine and Beer? ;-) You'd have to at least know the secret of Australian beer exports... I'd guess that we'd be talking mostly about Australian technology adoption (access technologies, IPv6, VoIP), the current level of knowledge dissemination and and such like (regulation??), as well as standing around telling travel stories. In terms of self-regulation, if you're able to contribute (except for just the travel stories) then please come along. Greg -Original Message- From: Greg Daley [mailto:[EMAIL PROTECTED] Sent: Friday, November 05, 2004 1:41 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Oz Bar BoF @ IETF 61 Dear IETF'ers. Please excuse the exclusiveness of this invitation, but I'd like to invite people to an Australian Bar BoF in the coming week at IETF61. If you're Australian (resident or otherwise) or working on Australian projects with your internet or IETF work, please contact me so that we can organize a location and time to suit as many loud-mouthed antipodeans as possible. It may be a good chance to get together and meet others in different areas, and should provide an interesting forum for discussing the state of the industry, technology adoption in Oz and standardization from an Australian perspective. The first round of drinks is on my funding source, the Australian Telecommunications Cooperative Research Centre (ATcrc). I hope to hear from you, or I'll have to drink the budget myself. Yours Sincerely, Greg Daley ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Oz Bar BoF @ IETF 61
Dear IETF'ers. Please excuse the exclusiveness of this invitation, but I'd like to invite people to an Australian Bar BoF in the coming week at IETF61. If you're Australian (resident or otherwise) or working on Australian projects with your internet or IETF work, please contact me so that we can organize a location and time to suit as many loud-mouthed antipodeans as possible. It may be a good chance to get together and meet others in different areas, and should provide an interesting forum for discussing the state of the industry, technology adoption in Oz and standardization from an Australian perspective. The first round of drinks is on my funding source, the Australian Telecommunications Cooperative Research Centre (ATcrc). I hope to hear from you, or I'll have to drink the budget myself. Yours Sincerely, Greg Daley ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 62
Hi Ben and Sam, Ben Crosby wrote: Hear hear! I debated posting after the fingerprint thread, and then again after the Cancun comment. Sam's email accurately sums up my own view. Further, as the host of IETF61, we explored at least four possible venues, one of which was Ottawa - too bloody awkward to get to, since there are very few direct flights, and even fewer venues big enough to support the meeting - and another was Florida, a WDW Conference hotel. This venue was ultimately rejected for a few reasons, one of which was the implications of work, not play. DC was ultimately selected as a good business town, and I hope it will be a succesful meeting. It's worth realizing that fingerprinting is a current issue (and likely a future one) which makes people uncomfortable and may discourage people from making their first (or next) visit to IETF, if it's in the 'States. Considering the high level RIPE/APNIC activity with IPv6, it's certainly worth minimizing some of the barriers to new participants in coming to IETF. Personally, I believe that if I enter a country as its guest, I subject myself to their rules and security tests. It doesn't mean I have to like being fingerprinted though. I know people for whom this dislike is a serious disincentive to attend. If we continue to have the high proportion of events scheduled (by default) in the USA, we may see the variety of international attendees diminish. When there have been so few (2 I think) IETFs in Canada it seems a shame to default to North America == USA and just ignore major cities such as Montreal or Toronto, because they're an hour or so further to fly. As far as I can see, Minneapolis isn't a direct destination for all the major airlines either. Like it or not IETF isn't a political organization, but a politically important one. If we're choosing locations, sometimes the reason has to be political (I'm not talking about going to Canada here). Seoul IETF apparently made good business sense. It made even better political sense, since it encouraged government and business figures in Korea to support IPv6. If we're prepared to ignore political issues then we may miss such opportunities for positive outcomes for IETF. My current opinion only, Greg Daley ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
