Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe workable network topologies #20

Open
ekr opened this issue Sep 9, 2020 · 8 comments
Open

Describe workable network topologies #20

ekr opened this issue Sep 9, 2020 · 8 comments
Labels

Comments

@ekr
Copy link

@ekr ekr commented Sep 9, 2020

This document does not seem to describe which topologies this is supposed to work in.

Two specific cases seem like they need attention:

  1. Non-upgradeable CPE provided by the carrier.
  2. Local non-upgradeable access point/NAT connected to the carrier-provided CPE.

Do we expect that designs should work when I have a client behind each of these?

@chris-box
Copy link
Contributor

@chris-box chris-box commented Sep 9, 2020

It's intended that case 1 is covered by the "Unencrypted forwarder" section, but I agree this needs expanding. Essentially given a non-upgradable device there needs to be a way to communicate the associated encrypted resolver that only leverages basic functionality the CPE already has.

Case 2 is not clear to me. A WiFi access point is a layer 2 device so should not be relevant. But do you mean a router that is performing NAT? Are you thinking of something like a smartphone personal hotspot?

@ekr
Copy link
Author

@ekr ekr commented Sep 9, 2020

Case 2 is not clear to me. A WiFi access point is a layer 2 device so should not be relevant. But do you mean a router that is performing NAT? Are you thinking of something like a smartphone personal hotspot?

Yes, I am assuming a NAT, which in my experience many home wireless APs are.

@tireddy2
Copy link

@tireddy2 tireddy2 commented Sep 9, 2020

Eric is referring to internal CPE (see figure 5 in https://tools.ietf.org/html/draft-btw-add-home-08#section-3.2).

@chris-box
Copy link
Contributor

@chris-box chris-box commented Sep 9, 2020

Ok, so case 2 includes any NAT router that is subdividing the local LAN. It's clearly not ideal having two levels of NAT, but given it seems to be prevalent I agree we should support Adaptive DNS Discovery in such an environment.

@tireddy2
Copy link

@tireddy2 tireddy2 commented Sep 10, 2020

@ekr
Copy link
Author

@ekr ekr commented Sep 10, 2020

@tireddy2
Copy link

@tireddy2 tireddy2 commented Sep 10, 2020

@ekr
Copy link
Author

@ekr ekr commented Sep 10, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants