Text 10483, 64 rader
Skriven 2013-09-26 17:26:27 av Michiel van der Vlist (2:280/5555)
     Kommentar till en text av mark lewis (1:3634/12.0)
Ärende: IPv4 and IPv6
=====================
Hello mark,

On Wednesday September 25 2013 17:06, you wrote to me:

 MvdV>> In the case of dual stack, I don't see it either. Presently all
 MvdV>> IPv6 capable nodes are dual stack.

 ml> you've tested all OSes for this?

Test them for what?

 MvdV>> Some day in the future however we may see IPv6 only nodes.
 MvdV>> If/when that happens we may have use for an IPNOV4 flag or
 MvdV>> something to that effect.

 ml> why not just IPV6 to indicate IPV6 capability?

Because IPv6 capability is not really what we want to signal.

 ml> perhaps limit the definition to "IPV6 only"...

That goes against how we have used flags in the past. V34 does not mean
V34-only, it means V34 capability in addition to the others listed or implied.
X75 does not mean X75-only, MNP does not mean MNP-only, etc, etc.

Departing from that convention is confusing.

 ml>  IPV4 is assumed...

Indeed. The problem arises when that assumption is not met. So what we want to
convey is not IPv6 capability but the /absence/ of IPv4 capability. You want to
block calls to certain nodes, not because they have IPv6, but because they do
NOT have IPv4. Is it not?

Hence IPNOV4.  Or maybe just IN4?

 ml>  IPV4 is assumed...

Or maybe we should drop that assumption. Assume that IPv4 is absent unless
there is an IP4 flag. That means that every IP capable node that is presently
in the nodelist must carry the flag, but in the very long run that flag will
disappear as IPv4 fades out...

A self cleaning solution..

 MvdV>> I say "may" because it will only be useful when by that time
 MvdV>> there are still a significant number of nodes that do not have
 MvdV>> at least outgoing IPv6 capability.

 ml> as you did in recent times with a proposal that is not yet needed,

Please refresh my memory, which one was that?

 ml> why not go ahead and set the item into the documents so there is no
 ml> question or problem in the future?

Because I think it is premature and hasty. See my previous messages.

Perhaps we should move this to FTSC-PUBLIC?

Cheers, Michiel

--- GoldED+/W32-MINGW 1.1.5-b20110320
 * Origin: http://www.vlist.org (2:280/5555)