discovering provisioning domain names and data
TRANSCRIPT
DiscoveringProvisioningDomainNamesandData
draft-ietf-intarea-provisioning-domains-00
P.Pfister,E.Vyncke,T.Pauly,D.Schinazi,M.Keane
Thepurpose ofthis draft is to:
1.Identify Provisioning Domains (PvDs).
2.Give PvD Additional Information.
DifferentiateprovisioningdomainsbyusingFQDNidentifiers.
Name,characteristics,captiveportal,etc…
[RFC7556]Provisioning Domains (PvDs)areconsistentsetsofnetworkproperties that can be implicit,oradvertised explicitly.
Step1:IdentifyPvDs
intareaWGIETF100
WiththePvD IDRouterAdvertisementOption
- AtmostoneoccurrenceineachRA.- PvD IDisanFQDNassociatedwithoptionsintheRA.- HbittoindicateAdditionalInformationisavailablewithHTTPS.- LbittoindicatethePvD hasDHCPv4onthelink.- Seq.numberusedforpush-basedrefresh.
Step1b:IdentifyingPvD (Cont.)
• InformationinaRAwithoutPvD IDislinkedtoanimplicitPvD(identifiedbyinterface&link-localaddressofrouter)• OptioninRAcanchangeofPvD whentheyarereceivedinaRAwithadifferentPvD ID• DHCPv6informationMUSTbeassociatedtoaPvD IDreceivedonthesameinterfacefromthesamelink-localaddress
Step2:GetthePvD AdditionalData
intareaWGIETF100
RA
WhentheHbitisset:GEThttps://<pvd-id>/.well-known/pvd
Usingnetworkconfiguration(sourceaddress,defaultroute,DNS,etc…)associatedwiththereceivedPvD.
Step2:GetthePvD AdditionalData
intareaWGIETF100
HTTP/TLS
WhentheHbitisset:GEThttps://<pvd-id>/.well-known/pvd
Usingnetworkconfiguration(sourceaddress,defaultroute,DNS,etc…)associatedwiththereceivedPvD.
Step2:GetthePvD AdditionalData
intareaWGIETF100
{"name": "Foo Wireless","expires": "2017-07-23T06:00:00Z","prefixes" : ["2001:db8:1::/48", "2001:db8:4::/48"],"localizedName": "Foo-Hôtel à Paris Wifi","dnsZones": ["example.com","sub.example.com"];"characteristics": {
"maxThroughput": { "down":200000, "up": 50000 },"minLatency": { "down": 0.1, "up": 1 }
}}
Someotherexamples(seealsohttps://smart.mpvd.io/.well-known/pvd) :noInternet : true,metered : true,captivePortalURL : "https://captive.org/foo.html”
Step 3:Hostbehavior
RA1PvD 1
DefaultRouteMoreSpecificRouteMoreSpecificRouteAddressAddressDNSfromR1
RA2PvD 2
DefaultRouteAddressDNSAddressDNSAddress
Hostsandapplicationsbehave according toexistingspecs ononeormorePvDs.
ChangesinDocument
• IANAconsiderationfollowsRFC8126• PvD IDFQDNencodedperRFC1035• “dnsZones”addedback• Privacysectionadded• Aiming“standardtrack”
PvD IDFQDNencodedperRFC1035
• BeforethePvD wasplainASCII• Couldhavedifferentrepresentation
• Now,RFC1035encodingisusedTheFQDNusedasPvD IDencodedasdescribedinSection3.1ofRFC1035.Notethatforsimpledecoding,thedomainnamesMUSTNOTbeencodedinthecompressedformdescribedinSection4.1.4ofRFC1035.ThisencodingisthesameastheoneusedinRFC8106.TheencodingMUSTendwithanull(zero-length)label.
WhataboutPrivacy?
• ThemainconcernistheOPTIONALfetchoverHTTPSofadditionalinformationfromaserver• But,• ThisserverisinthesamemanagementdomainasDHCP,AAAorDNS• Notoverthe“wild”Internet• BettertodiscovercaptiveportalviaPvD additionalinformationthanablindrequesttohttp://captive.example.com/hotspot-detect.html (defaultbehaviorofmostcurrentOS)
• Section6isnowtheprivacyconsideration
Implementation status
- pvdd:ADaemontomanagePvD IDsandAdditionalData- LinuxKernelpatchforRAprocessing- iproute toolpatchtodisplayPvD IDs- Wiresharkdissector- RADVDandODHCPDsendingPvD ID
Linux- https://github.com/IPv6-mPvD
Implementedinonecommercialvendorrouter
Nextsteps
• Feedback,suggestions,…arewelcome
• IfWGconsensus,requestIANAforanNeighborDiscoveryoption• Section13ofRFC4861“reclaimableinfuture”• Currentlyusing253“experimental”• Severalimplementations=>needtohaveacodeASAPtoensureinterop
intareaWGIETF100