On 10/4/11 12:24 PM, Mark Townsley wrote:
Homenet is concerned with how to make the network in the home work, so what
would happen today if I took two routers, connected them to two IPv6-enabled
ISPs, and then connected them to the same LAN in the home? Most residential
ISPs support source-address filtering today (at least in IPv4, and in every
IPv6 design I have ever seen), so your #2 seems to be the most likely starting
point.
If a home network is multi-homed, then I suspect we'd need to solve at
least #2.
But what if it turns out that we do that and the real problem that needs
to be solved is walled gardens that behave as #6? Then our solution to
#2 doesn't do any good.
Hence I think we need to write down the requirements around home
multihoming and if we are going to dismiss 4-7 below we'd better have a
good argument why those are a bad idea.
Now the question becomes whether the routers take over and try to keep a single
prefix within the home and be smart about what traffic goes where, or allow the
two prefixes to be advertised and punt the multihoming problem to the hosts. If
we let the hosts handle it, I have to say it is tempting to continuing punting
the problem up the stack and make this a transport issue rather than an IP
issue....
For #2 I can see us exploring network-layer solutions like RFC6296.
But for #3-7 that might not help.
I think we had a discussion about application awareness of addresses and
topology a while back (the IPv6 site-local debate) which seemed to
indicate that applications don't want to deal with this. I could be that
#4-7 are a bad idea and inconsistent with the architectural assumptions
we make, but the IETF hasn't tried to make that statement AFAIK.
Erik
- Mark
On Oct 4, 2011, at 3:46 AM, Erik Nordmark wrote:
On 9/21/11 1:19 PM, Ray Hunter wrote:
1) I contend that multi-homing is probably going to become the "norm" in
Europe by 2022, due to The European Electricity and Gas Directive. That
corresponds at least to picture 4, if not more.
If we believe that multi-homing will be more common, then I think we need to
understand what the constraints are for the multihoming in particular as this
relates to walled gardens. I can see many different possibilities, which imply
different requirements.
1. Just two paths to the Internet; the home gets one PA prefix from each ISP.
2. Like #1 but in addition the ISPs run ingress filtering so that the source
address in a packet from the home has to match the prefix that ISP delegated.
3. Like #1, but there are QoS guarantees for traffic local to an ISP. Thus a
host in the home can connect to foo.ispA.net over either ISP-A or ISP-B, but
gets better voice/video quality when doing it over ISP-A's connection.
4. Looking up foo.ispA.net works when asking the DNS server at ISP-A, but fails
(NXDOMAIN) when asking ISP-B.
5. The lookup of foo.ispA.net works over either DNS and returns the same IP
address, but fails (due to firewalls) for packets that are sent out via ISP-B.
6. The lookup of foo.ispA.net works over either DNS and returns the same IP address, but
the application-layer content is completely different (e.g., a "subscriber"
view when connecting over the ISP-A connection).
7. The lookup of foo.ispA.net returns different IP addresses when asking ISP-A
vs. ISP-B.
Do we really want to solve all those problems in homenet? We can't tell the
difference between behavior #1 and #6 at the IP layer.
Erik
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
