Re: [v6ops] draft-ietf-v6ops-ula-usage-recommendations - work or abandon?

[Mark Smith <[e-mail]>]

On 6 November 2015 at 21:08, Nick Hilliard <[e-mail]> wrote:
> On 06/11/2015 00:20, Lorenzo Colitti wrote:
>
> It breaks any application that requires that the application know its source
> address. Examples are SIP, FTP, audio/video chat, etc.
>
> your argument is the wrong way around: some protocols deliberately introduce
> layering violations by demanding that transport identifier information is
> encoded at the application layer.  Transport identifier translation merely
> shows up this brokenness.  The brokenness is not with the translation
> mechanism but with the higher level protocols.
>
> You could argue that this is an angels-on-the-head-of-a-pin style argument
> and that it doesn't matter which bit is broken because at the end of the
> day, breakage happens and users get hurt.  The point is that is IETF working
> groups like to get up on their collective high horses about identifier
> translation but apparently don't bat an eyelid when people create entirely
> new protocols with glaring layering violations.
>
> I'd happy to see disapproval notices for NPTv6 appearing in this draft if
> the IETF first issues explicit recommendations against using SIP, FTP,
> audio/video chat and all other protocols which mandate layering violations.
>

So this draft is advice about what should and shouldn't be done in the network.

Networks need to aim to best facilitate applications, because
supporting applications is the *sole* reason for networks (a network
without applications has no reason to exist). Network shouldn't be
imposing limitations on applications that don't need to be there,
because it creates a cost and causes cost shifting - the cost of those
network limitations ends up being borne by the applications, as they
then have to implement mechanisms to work around those limitations,
and they will, hence STUN, TURN, UDP or HTTP encapsulation of other
protocols.

We know that some applications use IP addresses as identifiers, and we
should be recommending IPv6 network deployments that best support
applications our networks' customers want to use, not telling them
"don't use that application because it stops me using a type of
device/function in the network I might want to use.". Doing so is
forgetting who's creating the need and reason for network operators
existence.

Regards,
Mark.