Thomas,
Can someone explain to me the rationale for mandating 4191 in 6204?
What was the scenario that was envisioned that necessitates 4191?
it was the only way we found to keep support for ULA prefixes. the
scenario is if you have a home CPE with ULA enabled, but no upstream
IPv6
I do not see exactly what your problem is.
Is it the default policy to be defined in RFC3484bis ?
Or, RFC3484's flexibility to prefer/de-prefer ISATAP ?
If it's the latter case, you can configure the policy table so that it
de-prefer your own ISATAP prefix. As you mention it,
+1 - this articulates my concerns and what I'd like to see done to resolve.
Wes George
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of John
Leslie
Sent: Monday, May 09, 2011 7:27 PM
To: Brian E Carpenter
Cc: ipv6@ietf.org; RJ Atkinson
Subject:
Earlier, Brian Carpenter wrote:
I suggest squaring this circle by retaining the MUST NOT (which IMHO
is the present consensus) but making it clear in the security
considerations that there will be exceptions. The problem here is that
the RFC 2119 language doesn't provide MUST NOT UNLESS...,
Thanks. You have answered my basic question in that it is possible to
encode individual ISATAP subnet prefixes, and I accept that'll probably
work for most people (together with the assumption that RFC1918 IPv4 +
NAT is now global.)
I'm just trying to explore the boundaries and assumptions
On 2011-05-11 00:38, Ran Atkinson wrote:
Earlier, Brian Carpenter wrote:
I suggest squaring this circle by retaining the MUST NOT (which IMHO
is the present consensus) but making it clear in the security
considerations that there will be exceptions. The problem here is that
the RFC 2119
