gmane.ietf.general

Re: [BEHAVE] Lack of need for 66nat : Long termimpacttoapplicationdevelopers

Steven M. Bellovin — 2008-12-02T03:38:33

On Mon, 1 Dec 2008 19:07:35 -0800 Christian Huitema windows.microsoft.com> wrote: I'm not sure I believe in the need for topology hiding. But if I did, on v6 I'd just allocate a separate subnet or group of subnets for external access. If really necessary, have such hosts set up IP over IP or L2TP tunnels to a concentrator; that will make this external access net look flat. Services like Microsoft DirectAccess? --Steve Bellovin, http://www.cs.columbia.edu/~smb

RE: [BEHAVE] Lack of need for 66nat : Long termimpacttoapplicationdevelopers

Christian Huitema — 2008-12-02T03:07:35

GSE/8+8 also does not achieve topology hiding, not if the mapping between internal and external /64 is a one-one. Of course, you could smash multiple internal subnets to a single /64 external view, but then you would probably need a new duplicate address detection algorithm to avoid conflicts, not to mention recognize cases of a single host using the same host ID on multiple subnets. Of course, Iljitsch points an interesting issue. If NAT66 behaves exactly like, say, NAT 64, then why would the organization bother to use IPv6 rather than sticking with net 10?

Handwaving? [Re: [BEHAVE] where to have the NAT66 discussion (wasRe: Please move this thread to BEHAVE mailing list ... )]

Brian E Carpenter — 2008-12-01T23:02:25

Keith, With some reluctance, I have't changed your cc list. But my conclusion is that this particular discussion belongs on the RRG list as much as anywhere. On 2008-12-02 09:52, Keith Moore wrote: ... I don't think that is quite the argument. It is more like this: 1. We know of no alternative to a longest-match based approach to routing lookup for the inter-AS routing system (commonly known as the DFZ). 2. To control the long-term scaling of that approach, we need to control the long-term size of the lookup table and the long-term rate of dynamic updates to that table. 3. We assume there will be continued unbounded growth in the number of sites requiring multihoming, but today each site that requires multihoming thereby requires its own entry in the DFZ lookup table. In the long term, this is unsustainable. [Digression about numbers and dates omitted.] 4. The known solutions to this all require some mechanism for aggregating site prefixes into ISP prefixes. [There's space for a digression about the r

Re: [BEHAVE] Lack of need for 66nat : Long termimpacttoapplicationdevelopers

Iljitsch van Beijnum — 2008-12-01T21:15:26

Not really. Or rather, it will, at the following costs: - all IPv6 implementations must be rewritten - need an IPv6->GSE transition strategy but unlike v4->v6 addresses look the same - still renumbering necessary when switching ISPs - identity theft trivial unless we implement id<->locator security protocols - no multihoming without extra protocols to detect and repair failures See draft-ietf-ipngwg-esd-analysis-05.txt or http://www.iab.org/about/workshops/routingandaddressing/routingws-gseproblems.pdf As I've been saying for years: if you fix the problems with GSE, you end up with something that looks a lot like shim6.

where to have the NAT66 discussion (was Re: [BEHAVE] Please movethis thread to BEHAVE mailing list ... )

Keith Moore — 2008-12-01T20:52:05

Mumble. As usual in IETF when we are talking about issues that have a profound effect on the architecture, the discussion is fragmented. - The greatest concentration of NAT experts in the IETF are probably in the BEHAVE group. They do have a NAT-centered view of the problem/solution space. But don't discount them entirely, as many of the participants in that group have a deeper grasp of the implications of NAT (at least when viewed from that angle) than the average IETF participant. - Some of the pressure to have NATs (other than for IPv6 transition) seems to be coming from routing area people who can't figure out how to make the core routing scale, so they want to push part of the problem to the edges. So clearly we need input from routing people. (I'm not saying it's an inherently unreasonable approach, though sometimes I do wonder if it smacks of "let's make this somebody else's problem so we don't have to deal with it". And BTW, no area has a monopoly on this kind of wishful thinking.) - Other

Re: [BEHAVE] Lack of need for 66nat : Long termimpacttoapplicationdevelopers

Fred Baker — 2008-12-01T09:21:06

I'll repeat what said in behave a few days ago. I think this capability actually gives the e2e guys (whom I count myself among) 99% of what they are looking for while giving rrg-etc, which is to say "the ISPs", 99% of what they're looking for. GSE/8+8 gives us the ability to manage the addresses we exchange in routing down to a number of prefixes on the order of (eg equivalent to a small multiple of) the number of autonomous systems. PI addressing, which is where we are in fact going, gives us a number of prefixes on the order of the number of things that want ot attach to the network, which is on the order of hundreds of thousands to millions now and tens of millions pretty soon, per Marshall Eubanks' analysis for NANOG. As specified, it calls for the use of some form of local address in the edge networks and a translation to PA at the DMZ between the edge and the core. What the Apps are looking for is a way to connect across the network core to provide whatever services they wa

Re: The internet architecture

Mark Seery — 2008-11-30T15:38:11

Some questions have also risen WRT identity: http://www.potaroo.net/presentations/2006-11-30-whoareyou.pdf Is identity a network level thing or an application level thing? ----- Original Message ---- From: Noel Chiappa mercury.lcs.mit.edu> To: ietf< at >ietf.org Cc: jnc< at >mercury.lcs.mit.edu Sent: Sunday, November 30, 2008 7:11:59 AM Subject: Re: The internet architecture > From: Keith Moore network-heretics.com> > while it's true that IP addresses don't have the right semantics, > neither do DNS names. What aspects of DNS semantics makes them inappropriate for this function? If you could specify an 'ideal' endpoint name, what semantics and syntax would it have? (Serious query, in case it wasn't obvious.) Noel _______________________________________________ Ietf mailing list Ietf< at >ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: [BEHAVE] Lack of need for 66nat : Long termimpacttoapplicationdevelopers

Fred Baker — 2008-11-30T00:35:19

Did you review the slides I discussed during the behave working group meeting as to what I view as the principal value of the technology? If not, may I suggest that you obtain them from ftp://ftpeng.cisco.com/fred/gse/behave-nat66-gse.pdf At this point, given the amount of discussion that has happened that presumes that "we", for some definition of that term, are wise, smart, and good, and everyone else (in your email, those thieving greedy vendors), without taking into account the written statements or the discussion that happened in the working group meeting (which is the email address you conveniently dropped from the thread), I am at a loss for words. Take time to find out what I took time to tell people about my motivations. Then, and only then, sit in judgement. As a matter of fact, the IETF is looking very hard at solutions to the problem I raise and has for the past several years been very explicitly reaching out to operators and others. A GSE/8+8 approach, which is th

Re: The internet architecture

Carsten Bormann — 2008-12-01T15:41:56

On Dec 1, 2008, at 15:43 , bt.com> bt.com > wrote: This is a side-track, but: Some people in the IETF, as well as in the industry, might disagree... Watch out for the next billion nodes on the Internet. Gruesse, Carsten (not speaking as 6lowpan co-chair today)

RE: The internet architecture

Hallam-Baker, Phillip — 2008-12-01T15:16:08

_______________________________________________ Ietf mailing list Ietf< at >ietf.org https://www.ietf.org/mailman/listinfo/ietf

RE: The internet architecture

2008-12-01T14:43:55

This is wildly out of date. For at least the last 10 years cheap and common PICs have been made with more RAM than that. The IP stack has been implemented in 1K bytes of code that will run on the 8-bit PIC CPUs. Exactly. Process control doesn't need IP at all at the edge of their network. They have other solutions that work well for them. Whether it is I2C or one-wire or RS-485, data can be relayed onto an IP network by devices which speak both protocols. There is no problem here. --Michael Dillon

RE: The internet architecture

Hallam-Baker, Phillip — 2008-12-01T14:29:03

_______________________________________________ Ietf mailing list Ietf< at >ietf.org https://www.ietf.org/mailman/listinfo/ietf

Re: [tsv-dir] tsv-dir review ofdraft-ietf-mext-nemo-v4traversal-06.txt

Rémi Denis-Courmont — 2008-12-01T14:25:48

Depends what you need to survive... If you only do DNS and a few TCP-based protocols which the brain-damaged ALG would not affect, it might just work. We probably don't care about MIP not passing through such abomination though.

Re: [tsv-dir] tsv-dir review ofdraft-ietf-mext-nemo-v4traversal-06.txt

Matt Mathis — 2008-12-01T14:13:05

I'd really hate to have address 32.116.104.101 (" the").... Such devices can't possibly survive, can they? Aghast, --MM-- ------------------------------------------- Matt Mathis http://staff.psc.edu/mathis Work:412.268.3319 Home/Cell:412.654.7529 ------------------------------------------- Evil is defined by mortals who think they know "The Truth" and use force to apply it to others.

Re: The internet architecture

Iljitsch van Beijnum — 2008-12-01T13:59:15

Who cares? Identification is a different problem from classification. The same ambiguity exists with IP addresses, anyway. Or did you really think 74.125.77.99 is a single machine?

Re: [tsv-dir] tsv-dir reviewofdraft-ietf-mext-nemo-v4traversal-06.txt

Colin Perkins — 2008-12-01T11:12:11

Right - the issue should be documented, and if there is a trivial fix it should be recommended, but this isn't a big issue.

Re: [tsv-dir] tsv-dir reviewofdraft-ietf-mext-nemo-v4traversal-06.txt

Magnus Westerlund — 2008-12-01T11:06:35

Hesham Soliman skrev: I don't think we should go to far to correct this bug in implementations. My understanding is that this have been observed but is not a common behavior as these generic ALGs do break things randomly and horribly. I would only do something about if it has no minimal impact on the specification and any deployed implementations. Otherwise the fix is likely to cause more grief than the few devices that are broken. Cheers Magnus Westerlund IETF Transport Area Director & TSVWG Chair ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund< at >ericsson.com ----------------------------------------------------------------------

Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt

Colin Perkins — 2008-12-01T10:13:21

One would assume these broken devices will potentially corrupt encrypted packets, the same as they will potentially corrupt any other packet. Hiding the source address when it appears in the payload (either by encryption, or using some trivial obfuscation as does STUN) simply reduces the probability of such corruption so it's no longer 100% guaranteed that the payload will be mangled.

Re: tsv-dir review of draft-ietf-mext-nemo-v4traversal-06.txt

Colin Perkins — 2008-12-01T08:52:40

Hesham, Thanks - one minor follow-up inline. Colin On 1 Dec 2008, at 08:29, Hesham Soliman wrote: My understanding from the STUN work is that NATs have been observed which rewrite any sequence of four aligned bytes matching the source IP address, irrespective of its location within the packet (section 15.2 of RFC 5389).

Re: The internet architecture

Dave CROCKER — 2008-12-01T05:05:34

John Day wrote: "The problem at hand" is what, exactly? Concretely and specifically. Ignoring, for the moment, that a domain name does not always map to an IP Address, nevermind that it often maps to a set of them, the fact of mapping is not quite the same as being "synonymous". It can be -- and often is -- equivalent to find a path to the named resource. A path is not a synonym. www.example.com is a common name for the an organization's online web presence. That sort of description of the name is quite different from the mechanical and narrow simplicity of a host name or a synonym for a *set of* IP Addresses that might refer to a single machine or to multiple. d/

Re: The internet architecture

John Day — 2008-12-01T03:32:29

As we have known since the early 80s, naming the host has nothing to do with the problem at hand. It is sloppy and gets in the way of getting it right. Currently, domain name is a synonym for an IP-address. The IP-address names the interface and is largely redundant since the MAC address does the same thing. Naming the host is sometimes useful for network management purposes, but really has nothing to do with the problem of forwarding or delivering packets. I realize there is a lot of sentimental attachment to the idea of naming a host, but as I said that was a sloppy habit we got in very early and for some reason sloppiness has prevailed. The "entity" to be named is whatever the packets are delivered to. That may reside on a host, but that fact is purely coincidental. As long as sentimentality trumps logic, it will be difficult to get it right, but in the current climate it will be possible to publish a lot of papers. Take care, John