[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [BEHAVE] Re: CPE equipments and stateful filters

Le lundi 30 juillet 2007, james woodyatt a écrit :
> So long as the IPv6
> architecture is defined such that communications between endpoints
> are always expected to originate with nodes behind firewalls and
> mediated by services in data centers, we will be saddled with the
> need for either 1) application transparency helpers inside network
> firewalls, and/or 2) an improvement to the core IPv6 specifications
> along the lines of my Application Listener Discovery (ALD) proposal.

I would not that the architecture is defined such. First, because the 
IETF, as an SDO, has an history of NOT specifying architectures. 
Second, because there is clearly NOT a consensus on that topic.

*But*, I would agree that, in any case,
- whatever the IETF mandates, recommends, suggests, or not,
- whether or not this is a good idea,
- whether or not it abides to the IETF design principles,
- whether ir not this is good engineering,
- whether it displeases some consumer ISPs,
- whether it breaks IETF transport protocols,
- whether it breaks IETF mobility protocols [1],
- whether or not it makes IPv6 rather useless compared to IPv4+NATs,
- ...

...there will be stateful firewalling middleboxes in some "unmanaged" 
network cases. And it will also definitely happen on consumer-grade 
radio links.

--- Footnote: ---
[1] Mobile IPv6 has been notoriously absent from this debate so far. It 
is all the weirder as it has been at the center of another recent IETF 
IPv6 hot topic: RH0 deprecation.
---

Therefore, as an individual, I think there would be value for IETF in:

- working on ALD or something along its line,

and,

- working on BEHAVE-ish recommendations for such boxes, to minimize the 
damage to the works of the IETF Transport and Internet areas (and 
indirectly the RAI and Apps areas). By this, I mean non-UDP transport 
protocols, mobility/multihoming stuff, and some future proofing.


My 2 cents,

-- 
Rémi Denis-Courmont
http://www.remlab.net/