IPv6UniquePrefixes
DraftUpdateandgenericreflectionsofIETFprogress
GunterVandeVelde
ProductLineManager@Nokia
UniqueIPv6PrefixPerHost
• draft-ietf-v6ops-unique-ipv6-prefix-per-host-02
•
•
•
•
Lastversionupdate:13March2017
PastWGLCon11April2017
IESGTelechat requestedafter28April2017
Intendedstatus:BCP
• Whatisitabout?
• IPv6prefixrecommendationforsharedpublicLAN’s(wiredandwireless)
• Traditionaladdressplanning
• LAN:/64
• Host:128bithostaddressfromtheLAN/64
• Newsuggestedaddressplanning
• LAN:non-defined
• EachhostonLANgetsa/64IPv6Prefix
• Why?
• Improvedsubscribermanagementandimprovedsubscribersecurity
UniqueIPv6PrefixPerHost
• ApplicabilityScope:
•
•
•
•
•
•
StableandsecureIPv6onlyexperience
Zeroperformanceimpact
Supportedbylargestsetofhosts
Allowinnovation
Securehost-to-hostcommunicationmanagedbyfirsthoprouter
BCPguidelines
IPv6Wi-FiSubscriberOnboardingProcedures(1)
• WhenUEconnectsitsendsaRStolearn
• IPv6Gateway,Prefixinformation,DNS,
remaininginfoforglobalrouting
• RSsendfromUEviatheAP-bridgetotheWLANGW
• Duetosplit-horizonforBUMtraffictheRSisnot
seenbyotherUE’sconnectedtothesameAP
• FirsttimeUEconnectsitisnotAuthorized
andWLAN-GWqueriesAAAserver
• AAAservercheckspolicyDBandreturns/64
togetherwithhttp-redirecttoCaptiveportal
viaRadius-acknowledgemessage
IPv6Wi-FiSubscriberOnboardingProcedures(2)
• WLAN-GWusesreceivedRadiusinfoto
composethe“RA”responsetotheUE
originated“RS”message
• RAcontainsfewimportantbitsofinformation
• AIPv6/64prefix
• Someflags
• (1)IPv6/64prefix
• LocallymanagedpoolonWLAN-GW
• PoolsignaledthroughRadius
• (2)Someflags
• IndicatetouseSLAACand/orDHCPv6
• Prefixison/off-link
• Isthereneedtorequest‘Other’information(e.g
DNS)?
IPv6Wi-FiSubscriberOnboardingProcedures(3)
• IPv6RAflagsforbestcommonpractice
• M-flag=0(UE/subscriberaddressisnotmanaged
throughDHCPv6),thisflagmaybesetto1inthe
futureif/whenDHCPv6prefixdelegationsupportover
Wi-Fiisdesired)
• O-flag=1(DHCPv6isusedtorequestconfiguration
informationi.e.DNS,NTPinformation,notforIPv6
addressing)
• A-flag=1(TheUE/subscribercanconfigureitself
usingSLAAC)
• L-flag=0(TheUE/subscriberisoff-link,whichmeans
thattheUE/subscriberwillsendpacketsALWAYSto
hisdefaultgateway,evenifthedestinationiswithin
therangeofthe/64prefix)
• Timers:
•
•
•
•
•
•
IPv6RouterAdvertisementInterval=300s
IPv6RouterLifeTime =3600s
Reachabletime=30s
IPv6ValidLifetime=3600s
IPv6PreferredLifetime=1800s
Retransmittimer=0s
IPv6FlowLabelSaga
• GeneralfeelingatIETF:
• Donottouchtheflow-label(non-permutablefield)
• Flowlabelisunpredictableandilldefined
• Ingeneralithasbeenuseless20bitsinIPv6header(anditisnotexpectedto
change)
• HoweverSPsdesiretomakeuseofIPv6Flowlabel
• https://tools.ietf.org/html/rfc6294
Alternatemarking
byTelekomItalia
• Draft:draft-ietf-ippm-alt-mark
• WhatissocoolaboutAlternateMarking
•
•
•
•
MetricsharvestedusingREALtraffic
Noinjectionofprobesorotherartificialmetrics
MethodhasstandardefforthappeningonIPv4,MPLS,BIER
IPv6hasbeenleftout… untilnow…
• Howdoesitwork?
•
•
•
•
5minutewindowtomark(5-minutemark‘0’,5-minutemark‘1’,5-minutemark‘0’,etc)
ACLsareusedtocountpacketsegress/ingressofeachinterface
Countersareharvestedeach5minutesandsenttomanagementsystem
Analyticsaredoneonthemanagementsystem
Alternatemarking
byTelekomItalia
Ref.TelekomItalia(GiuseppeFioccola)
Alternatemarking
IPv6FlowLabelsforTelemetry(byTelekomItalia)
• IPv6basedAlternatemarking
• Note
• onlyinmanagedandcontrolleddomain
• Originalflow-labelreconstructedwhenleavingSPcontrolleddomain
• TechnologycanbeusedtogetherwithSRv6
• SRv6policyandotherIPv6tunnelencapsulations
• IPv6SRv6Encap
• OuterSRv6headeruses1or2bitsfrom20bitflow-labelfield
• OuterSRv6headerremovedwhenexitingtheSPdomain
• OriginalFlow-labelrestoredategress
• IPv6SRv6EHinsert
• SRv6EHinsertproposesinsertionofIPv6ExtensionHeaders(howeverinRFC2460bisitwasruled
againstinsertionofEHs,makingSRv6headerinsertfutureuncertain)
• Originalflow-labelcanbecarriedasOpaquedataTLVinSRv6headers,andbyegressdeviceused
fororiginalheaderconstruction
SegmentRoutingforIPv6- twoproposals
(IPv6ExtensionHeadersorUnifiedRoutinginstructions)
• draft-ietf-6man-segment-routingheader
• IPv6EHtodriveSegmentRouting
• CleanIPv6puristapproach
• However
• HWunfriendly(noteasytopushmultiple128
bitaddresseswithHWsupport)
• (justlookatMPLSMSDofyourfavoritevendor
ormerchantsilicon)
• LotsofIPv6headeroverhead
• IffyIPv6ExtensionHeaderinsertionproposal
toreduceoverhead
• baseIPv6Protocolneedstobemodifiedto
evensupportthis
• IETF6man(30March2017):proposed
RFC2460bisEXPLICITELYforbidintermediate
nodestoinsertEHs
• draft-xu-mpls-unified-source-routinginstruction
• NewandpresentedatIETF98– well
receivedbySPRINGWorkingGroup
• NativeIPv6dataplane usingUDP
• NochangesneededtoIPv6atall
• Sizematters:Persegmentonly20bitsare
needed(SRv6EHneeds128bits)
• Virtualizationandentropyfriendly
• alreadysupportedonanydevice
supportingMPLScontrolplaneandIPv6
data-plane
• MPLSencapsulatedinaIPv6UDPheader,and
eachsegmentisidentifiedby20bit’s
• WorksseamlessacrossNATIVEIPv4,IPv6and
MPLS
WhatelseIPv6ishappeningatIETF?
Notafullview… justshortoverview
• draft-ietf-opsec-v6isinWGLCrightnow
• CheckwithEricVyncke becauseheiseditorofthiswork
• 6MANLastCallSummary
• https://www.ietf.org/proceedings/98/slides/slides-98-6man-ietf-last-call-summary00.pdf
• Updates:rfc2460bis,rfc4291bis,rfc1981bis
• Elevation(butno change):rfc4443,rfc3595
• Requirements docs
• IPv6Node Requirements (draft-clw-rfc6434-bis)
• Requirements for IPv6Router(draft-ali-ipv6rtr-reqs)
• BasicRequirements for IPv6CustomerEdgeRouters(draft-palet-v6ops-rfc7084-bis)
WhatelseIPv6ishappeningatIETF?
Notafullview… justshortoverview
• v6ops
• Theeternaldiscussionon“makingRDNSSaMUST”
•
•
•
•
Twomechanismsforsamepurpose(->sendconfig infotohost)
Onlyonetendstobeused,sodeveloping2iskindofsilly
Veryreligiousdiscussion
Nooutcomeyet… virtualhumongoing…
• WGLCfordraft-ietf-v6ops-v4v6-xlat-prefix
• Start:11April– end:25April
• UpdatesRFC6890(=Special-PurposeIPAddressRegistries)
• IPv6prefix64:ff9b:1::/48forlocalusewithindomainsthatenableIPv4/IPv6translationmechanisms
• 7084bis(BasicRequirementsforIPv6CustomerEdgeRouters)
•
•
•
•
HNCPisproposedasaMUSTbysome,butstronglydebated(googleispushingforinclusion)
LISPisproposedasMUST,butagainstronglydebated
Prefixdelegationmorespecified(/48-/64forCPErouters)
Proposesmultipletransitiontechnologies,andrightnowitisdiscussedifthatisreallythe“best”?