Front posting: I think we are using "walled garden" to mean several
things and that is confusing.

In my mind it refers to a captive customer scenario where a service
provider is intentionally limiting a customer's access to the global
Internet or (by playing DNS and/or HTTP proxy tricks) presenting a
distorted view of the the global Internet.

This becomes especially obnoxious if the customer has multiple
providers that attempt to enforce different walled gardens. But
that's a MIF issue, I think.

That is quite different from stating that a customer network should
be separated from the Internet by a security fence of some kind and
may also need a local namespace. I thought that was normally called
an intranet.

Regards
   Brian Carpenter




On 2012-03-30 00:48, Michael Richardson wrote:
>>>>>> "Brian" == Brian E Carpenter <Brian> writes:
>     >> I much prefer to engineer for walled gardens using globally
>     >> unique addresses GUA (not globally reachable) ("GUAnGR"?), than
>     >> for NAT66.
>     >> 
>     >> I also want to point out that the experience with IPv4 "walled
>     >> gardens" usually involves either operators squatting on
>     >> "unallocated" address spaces, or enterprises running non-unique
>     >> RFC1918 networks with VPNs/Remote-Access.  None of these things
>     >> are going away.
>     >> 
>     >> The example of "Joe's web cam", and whether we should use: -
>     >> ULA/GUA in DNS with views (what about caches and DNSSEC?)  or -
>     >> ULA+GUA in DNS (multiple AAAA) plus Happy Eyeballs
>     >> 
>     >> is pertinent.  Because the ULA is a walled garden.  And if it's
>     >> really "Joes' office webcam via VPN", then the Enterprise is a
>     >> walled garden.
> 
>     Brian> But neither of those are "captive customers" in the sense
>     Brian> that WAP threatened or that some carriers still seem to be
>     Brian> hoping for.
> 
> So, is the term "walled garden" inappropriate then, and we are arguing
> about nothing?
> 
> We aren't talking about captive customers.  The specific *technical*
> requirement is actually:
>          You can't *there* if you start with that source IP.
> or:      If you want to go *there*, you must start from *here*
> or:      Ingress filtering rules
> 
> (with allusions to: http://c2.com/cgi/wiki?WouldntStartFromHere )
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to