რას აწესრიგებს IPv6CP და რას სჭირდება ჯერ კიდევ პრეფიქსი
link-local მისამართი PPP ინტერფეისზე კონფიგურაციის ნაბიჯია და არა 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, არაფერს ამტკიცებს დღეს მომუშავე სტეკზე. თანამედროვე კლიენტს შეუძლია PPP ინტერფეისის ნაცვლად პაკეტური გვირაბის API გამოიყენოს, და ვივარაუდოთ, რომ ის ისტორიულ კავშირს ექცევა, ნიშნავს მუშა დიზაინის დაშლას. ჰკითხეთ კლიენტის ვერსია და მიწოდების მეთოდი და არა ინტერფეისის სახელი.
დაწერეთ გეგმა, რომელიც კლიენტს სჭირდება
სრული აღწერა მოიცავს სამ რამეს: რომელი მისამართი აქვს კლიენტს, რომელი დანიშნულებები უნდა ატაროს გვირაბმა და როგორ აბრუნებს ქსელი პასუხებს. link-local მისამართი არცერთზე არ პასუხობს, ხოლო მიღებული გამოცხადება მხოლოდ ერთის ნაწილზე პასუხობს. შეამოწმეთ ყოველი პუნქტი ცალ-ცალკე, ნაცვლად მწვანე ინდიკატორის მიღებისა. შემდეგ ჩაწერეთ, რომელმა მექანიზმმა მოგვცა თითოეული პასუხი, რადგან ეს ჩანაწერი შემდეგ IPv6 ანგარიშს ორწუთიან შემოწმებად აქცევს.
შეინახეთ ჩანაწერი სერვისის დოკუმენტაციასთან და განაახლეთ, როცა კლიენტი შეიცვლება. გეგმა, რომელიც სწორი იყო PPP კლიენტისთვის, შეიძლება მცდარი იყოს პაკეტური გვირაბის კლიენტისთვის იმავე სერვისზე. ოთხი კითხვა იგივე რჩება; იცვლება მხოლოდ პასუხები.