Problem #2 (connectivity to two ISPs with different PA assignments and
source address filtering) does seem forth addressing... if we can.
Standardizing and mandating NPT66 (RFC 6296, not standards track) would
seem highly undesirable.
However, so are all the other answers I know of, such as source address
sensitive routing.
As for the later cases, while folks will build that, I think that
solutions for those are probably better defined in places that can at
least discuss business tradeoffs.
Yours,
Joel M. Halpern
On 10/4/2011 10:49 PM, Erik Nordmark wrote:
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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
