Ինչ է բանակցում IPv6CP-ն, և ինչին դեռ պետք է նախածանց
PPP միջերեսի link-local հասցեն տեղադրման քայլ է, ոչ թե IPv6 հասանելիություն։ Առանձնացրեք նույնացուցիչների փոխանակումը նախածանցներից, երթուղիներից և հաճախորդի ինտեգրումից։
IPv6-ը բարձրանում է PPP միջերեսի վրա, հայտնվում է link-local հասցե, և փոփոխությունը հայտարարվում է ավարտված։ Հետո ոչինչ չի երթուղվում, գլոբալ հասցե գոյություն չունի, և հանրային նպատակակետին ուղղված թեստը ձախողվում է, մինչ միջերեսը դեռևս կարգավորված է երևում։ Կապը բարձրացավ, ցանցը՝ երբեք։ Կատարեք ստորև նշված չորս ստուգումները հերթականությամբ և կանգ առեք այն մեկի վրա, որը բացատրում է բացը։
Ինչ է իրականում ապացուցում link-local հասցեն
IPv6CP-ն բարձրացնում է IPv6-ը PPP կապի վրա և յուրաքանչյուր կողմի համար բանակցում է միջերեսի նույնացուցիչ։ Այդ նույնացուցիչը ստեղծում է link-local հասցե, որը բավարար է կապի միջով գործընկերոջ հետ խոսելու համար և բավարար չէ որևէ այլ բանի հասնելու համար։ Հասցեն ապացուցում է, որ կապը պատրաստ է IPv6-ին, և ոչինչ չի ապացուցում գործընկերոջ հետևում գտնվող ցանցի մասին։ Այն որպես հասանելիության հասցե կարդալը այն սխալն է, որով սկսվում են այս հետաքննությունների մեծ մասը։
Ստորև նշված չորս հարցերը բաժանում են այն, ինչ որոշում է կապի շերտը, այն ամենից, ինչ պետք է տրամադրի ծառայությունը։ Պատասխանեք հերթականությամբ, որովհետև ավելի ուշ հարցին հնարավոր չէ պատասխանել, քանի դեռ ավելի վաղ հարցը բաց է։
| Question | Answered by | What it does not settle |
|---|---|---|
| Is IPv6 up on the link? | IPv6CP: interface identifiers, then link-local addresses | Any address reachable beyond the peer |
| Where does a global prefix come from? | Router advertisement, delegated prefix, DHCPv6 or static configuration | IPv6CP carries no prefix of its own |
| Who owns the routes? | The client's tunnel configuration and the server's return path | A link-local address implies no route at all |
| How does this client get configured? | Explicit tunnel settings or router advertisements, depending on the client | The standard does not choose for the implementation |
Որտեղից պետք է գա նախածանցը
Գլոբալ հասցեին նախածանց է պետք ինչ-որ տեղից՝ երթուղիչի հայտարարություն, պատվիրակված նախածանց, DHCPv6 կամ ստատիկ կարգավորում։ IPv6CP-ն ոչ մեկը չի կրում, և կապի վրա ցանկացած սպասելը չի ստեղծի այն։ RFC 5072-ը IPv6CP-ն դնում է որպես տեղադրման այն քայլ, որն աշխատում է նախքան կապի վրա այլ IPv6 արձանագրությունների աշխատելը, և դա է նրա ողջ շրջանակը՝ կապը նախապատրաստելը, ոչ թե ցանցը համարակալելը։ Տրամադրեք նախածանցը, և միջերեսը կսկսի տրաֆիկ կրել՝ պարզապես գոյություն ունենալու փոխարեն։
Երթուղիչի հայտարարությունները սովորական պատասխանն են տեղական ցանցում և ավելի քիչ հուսալի՝ կետ-կետ թունելում, որովհետև հաճախորդը պետք է և՛ հարցումներ ուղարկի, և՛ ընդունի պատասխանը։ Որոշ թունելային հաճախորդներ ոչ մեկը չեն անում։ Ստուգեք, թե ինչն է հաճախորդը պատրաստ ընդունել, նախքան որոշելը, որ սպասարկիչը պետք է ուղարկի այն։
Նույն նախածանցը պետք է հասանելի լինի նաև մյուս ծայրից։ Հաճախորդը, որն ունի գլոբալ հասցե, բայց վերադարձի ուղի չունի, կարգավորված է, ոչ միացված։
Երթուղիները առանձին խոստում են
Անգամ հասցեով հաճախորդը պետք է իմանա, թե որ նպատակակետերն են պատկանում թունելին, և սպասարկիչին վերադարձի ուղի է պետք այդ նպատակակետերի համար։ Դրանք երկու որոշումներ են՝ կայացված երկու տեղերում։ Թունելը, որը կրում է ամբողջ IPv6 տրաֆիկը, պահանջում է լռելյայն երթուղի հաճախորդի վրա և վերադարձի երթուղի սպասարկիչի վրա, իսկ բաժանված թունելը պահանջում է, որ երկու կողմերը համաձայնեն նույն նախածանցների ցանկի շուրջ։ Երբ նրանք չեն համաձայնում, տրաֆիկը դուրս է գալիս և երբեք չի վերադառնում։
Գրեք ցանկը նախքան որևէ բան կարգավորելը։ Եթե պլանն ասում է, որ թունելով անցնում է միայն կորպորատիվ նախածանցը, ապա հաճախորդը չպետք է ունենա լռելյայն IPv6 երթուղի, և սպասարկիչը չպետք է հայտարարի այդպիսին։
Հաճախորդի ինտեգրումը որոշում է մնացածը
Որոշ թունելային հաճախորդներ IPv6-ը կարգավորում են բացահայտ։ Օրինակ՝ Apple-ի Network Extension-ը վերցնում է հասցե, նախածանց և երթուղիների հավաքածու թունելի համար, այնպես որ այն օգտագործող հավելվածը չի սպասում Ethernet ոճի հայտարարության։ Մյուսները հենվում են կապով եկող երթուղիչի հայտարարությունների վրա։ Երկու մոդելներն էլ օրինական են և պահանջում են տարբեր սպասարկիչային վարք, ուստի սխալի ընտրությունը ստեղծում է հաճախորդ, որը հավիտյան սպասում է հաղորդագրության, որը ոչ ոք չի ուղարկում։ Բացահայտեք մոդելը նախքան սպասարկիչը փոխելը։
Հին միջերեսի անունը, ինչպիսին է ppp0-ը, ոչինչ չի ապացուցում այսօր աշխատող ստեկի մասին։ Ժամանակակից հաճախորդը կարող է օգտագործել փաթեթային թունելի API՝ PPP միջերեսի փոխարեն, և ենթադրել, որ այն վարվում է որպես պատմական միացում, աշխատող ձևավորումը կոտրելու միջոց է։ Հարցրեք հաճախորդի տարբերակը և մատակարարման եղանակը, ոչ թե միջերեսի անունը։
Գրեք այն պլանը, որն անհրաժեշտ է հաճախորդին
Ամբողջական նկարագրությունը ներառում է երեք բան՝ ինչ հասցե ունի հաճախորդը, ինչ նպատակակետեր պետք է կրի թունելը, և ինչպես է ցանցը վերադարձնում պատասխանները։ Link-local հասցեն ոչ մեկին չի պատասխանում, իսկ ընդունված հայտարարությունը պատասխանում է միայն մեկի մի մասին։ Ստուգեք յուրաքանչյուր կետը առանձին՝ կանաչ ցուցիչ ընդունելու փոխարեն։ Այնուհետև գրանցեք, թե որ մեխանիզմն է տրամադրել յուրաքանչյուր պատասխանը, որովհետև այդ գրառումը հաջորդ IPv6 հաշվետվությունը դարձնում է երկու րոպեի ստուգում։
Պահեք գրառումը ծառայության փաստաթղթերի հետ և թարմացրեք այն, երբ հաճախորդը փոխվի։ Պլանը, որը ճիշտ էր PPP հաճախորդի համար, կարող է սխալ լինել փաթեթային թունելի հաճախորդի համար նույն ծառայությունում։ Չորս հարցերը մնում են նույնը, շարժվում են միայն պատասխանները։