goo blog サービス終了のお知らせ 

rabbit51

it's since Nov.30 2005
May.29 2014, transferred from broach

フレッツ 光ネクストのサービスタイプ(ハイスピードからギガライン)を変更した

2025-02-14 22:00:00 | ネットワーク
2025年中に変更あるいは終了するPC・ネットワーク関連サービスの対応について」の(1)を実行した。


(1)タイプ変更の申し込み
2月1日(土曜日)からとの事で昨年12月19日に届いた通知には、申込先「0120-116410」(受付時間:9:00-17:00 *平日・祝日のみ受付、土日・年末年始[12/29-〜1/3]は休業)とある。
電話で「タイプ変更」の申し込みが出来ない。ウェブ「https://flets.com」の「各種お手続き(変更・解約)」で「フレッツ光 プラン変更のお手続き」を選択。「フレッツ 光ネクスト ファミリー/マンション・ギガラインタイプへプラン変更(戸建て)」で申し込み画面が出てこない。工事料金の説明。「お手続き方法(詳しくはこちら)」が変更手続きの画面だった。
ウェブ申し込みには、「お客様ID」と「アクセスキー」が必要だった。

2月3日(月)午後1時48分 「0120116300」から電話。タイプ変更の確認だった。光ネクスト ハイスピードタイプからギガラインタイプへの変更工事料金は、無料。ひかり電話とフレッツ・テレビは、別途工事費が掛かるとの事!。再確認をお願いすると「光クロス」へのタイプ変更でないので無料との事でした。このページでは、「フレッツ光クロス」へのタイプ変更工事が無料。付加サービス(電話交換機工事費など)は、割引の対象外のようだ。しかし、このページには、特に記載が無い。ひかり電話、フレッツ・テレビの付加サービス工事料も無料で良かった。

2月8日(土)の午前4時から5時の間に切り替え工事が実施される。電話は、通話していると5秒間ほど「音声」が聞こえなくなる。フレッツ・テレビは、特に影響が無い。インターネット接続(PPPoEやiPoEなど)は、セッションが5秒間切断される。IPv6プレフィックスは変更無し。ホームゲートウェイの再起動(電源のオン・オフ)は、不要だが、インターネット接続やひかり電話に不具合があれば、再起動(電源のオン・オフ)で再確認が必要との事。不具合が発生した場合は、「0120-000-113」。

2月8日(土)午前5時5分53秒にNVR510で接続している「ぷららIPv4 over PPPoE」が切断された(NVR510のアラーム音で確認)。切断後の午前5時21分21秒に再接続される。切断時間は5秒でなく15分くらいだった。
インターネット接続を確認すると正常にアクセスが出来た。IPv6 Prefixの変化も無い。IPv4のアドレス(ひかり電話)も変化無し。


ネットワーク速度を計測してみた。
タイプ変更前(2025/2/7 10:32)


タイプ変更後(2025/2/8 7:38)

本当に変更された?
ハイスピードのIPv6速度は、最大1Gbps/上り・下り。IPv4速度は、最大200Mbps/下り、100Mbps/上り。
ギガラインのIPv6速度は、最大1Gbps/上り・下り。IPv4速度は、最大1Gbps/上り・下り。

タイプ変更後(2025/2/10 17:32)

それなりの速度が出るようになった。ギガライン変更を確認。

IPv4は、Transix IPv4overIPv6で計測。IPv4PPPoEは、ぷららIPv4 PPPoEで計測



PR600MIにひかり電話の内戦端末登録エラーが記録。
登録エラーの端末は、正常に使用できる。
PR-600MIの再起動で登録エラー記録は停止した。


コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

AirMac Time Capsule(A1470)2TB磁気ディスクを交換した

2025-02-12 15:00:00 | ネットワーク
AirMac Time Capsule(model A1470)にTime Machineのデータを保存していた。
USでは、AirPort Time Capsule

Time Machineが準備中のまま進まない状態になった。Time Machineの保存先をNAS(DS220J)に変更すると正常に完了する。
下記を参考にAirMac Time Capsuleの磁気ディスクを交換することにした。
https://www.itti.jp/life-style/airmac-time-capsule/

交換する磁気ディスクは、Seagate Barracuda 2000GB(ST2000DM001)からWestan Digital Blue 4TB(WD40EZAX)とした。

AirMac Time Capsuleの裏カバーを外し、前記ガイドを参考に磁気ディスクを取り出す。


磁気ディイスクを外す前に三つのコネクタを外す。

「1」のコネクタはケーブル方向へ外す(両端のロックを外しながら)。
「2」と「3」のコネクタは、ケーブル方向と90度、PC基板から離す方向へ外す。ケーブルを基板から離す様に外す。
「3」のコネクタをケーブル方向へ外そうとしてコネクタを壊してしまった。ガイドをよく読んで作業をする事が肝心。
幸い、こわれたコネクタ本体にコンタクトを挿入して、アロンアルファで固定する事で、修復ができた。非常に小さいのでルーペが必要だった。
壊した3Pのコネクターは、ステータスランプ(LED)に接続されていた。

上が使用されていたSeagateの磁気ディスク。下が交換用のWestan Digitalの磁気ディスク。

磁気ディスクは、ゴムのスペーサーで本体に固定されいる。磁気ディスクの形状が異なるので、ゴムスペーサーをWestan Digitalの形状に合わせてカットした。

磁気ディスク交換後、裏蓋を戻す前に、動作チェック。
・電源を接続する→「オレンジ点灯」→「オレンジ点滅」
AirMac Time Capsule 設定ガイド」の「19 AirMac Time Capsuleが応答しない場合」を参考に「出荷時の設定にリセット 」した。
・「AirMacユーティリティ」を使い、ベースステーション設定、インターネット設定、ワイヤレス設定、ネットワーク設定とディスク設定を行なった。

磁気ディスクは、「ディスク消去」を行う事でフォーマット?がされ利用できる様になった。

Time machineのデータ保存も復帰した。
1TBに容量制限したNASサーバーds220jと4TBディスク拡大復帰したAirMac Time Capsuleの二つにデータをバックアップ保存するよう設定した


 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ぷららメールサービスのsmtp仕様が変更されていた

2024-07-14 13:00:00 | ネットワーク
6月25日から毎日送られてくるSynolog DS216JとDS220Jのバックアップ通知メールが届かない。
26日、27日には、DS216Jからは届いた。DS216J及びDS220Jのメール通知確認を行うと送信が出来る。様子見をしていたらDS216J及びDS220J共にメール通知がされなくなった。エラーは、認証の失敗と出てくる。時間帯により認証に失敗するのかと思っていたが全く通知されなくなったので調べてみた。

DS216J


DS220J


opensslによる手打ちメール送信は問題なく送信できる。
SMTP接続後の「auth login」の認証も問題ない。
「mail from」でぷららのメールアドレス以外のアドレスを設定するとエラーが発生。
ドメインを合わせてもエラーが発生。

ぷららの「お知らせ」を確認しに訪問。
2024年6月21日にそれらしき通知がある。実施の5日前であるがメールお知らせ通知は無かった。



「送信者認証を実施したメールアドレスとそのメールの送信者情報メールアドレスが一致するかを確認」との事。「mail from」がぷららの契約メールアカウントでないと送信できなくなった。
まあ、しょうがないか。。。いくつかのメール送信設定を変更して対応した。

2010年4月19日から実施されているらしいこの対策

「sub mission port」からの認証接続であれば、この対策はメール送信を遅くするだけなのでやめてほしい。
送信時の認証で誰がこのような送信をしているのか「ぷらら」が認識できるのでアカウント停止にすれば良いだけだと思う。

 

6月27日 「ぷらら」および「BUSINESSぷらら」の一部オプションサービス等の提供終了について」でプライベートホームページも来年2025年3月31日で終了とアナウンスされている。
ぷららISPでは、毎月契約金額相当のポイントが付与され、ポイント対象のぷららサービス(プライベートホームページ)を使ってきたのだが、ポイント対象の使いたいサービスがメールアカウント以外、無くなってきた。そろそろISPの変更を検討する必要がありそうだ。
ISP変更で一番問題なのが「メールアドレス」。悩む。。。

 
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ぷららメールで廃止されたSMTP認証CRAM-MD5と未提供のDIGEST-MD5を確認

2023-11-16 11:00:00 | ネットワーク
ぷららメールサーバーがセキュリティ対策を実施」でSMTPの認証方式「CRAM-MD5」が廃止された。暫定対策のため「 Panasonic ドアフォン VL-SWH705KLのメール通知が停止した-調査結果」でDebian10にPostfixメールサーバーを稼働させCRAM-MD5認証でメールを受け、ぷららメールサーバーへPLAIN認証を使いTLS接続で中継させた。
平文パスワードを送信する必要がある「LOGIN」と「PLAIN」認証だけにするとは、どの様な「セキュリティ」対策なのだろうか?
「LOGIN」「PLAIN」認証より「CRAM-MD5」認証の方がよほどセキュリティが高い気がする。
「DIGEST-MD5」認証とか「OAUTH」認証とかを加えるなら理解出来るが、、、

今更だが、Postfixメールサーバーで「CRAM-MD5」と「DIGEST-MD5」の認証をsmtpコマンドレベルで確認してみた。

(1)CRAM-MD5
「CRAM-MD5」は、検索するとコマンドレベルでの確認事例が出てくる。
smtp接続後、コマンドで「auth cram-md5」で認証方法を提示すると「base64でエンコードされたチャレンジ文字列」応答がある。
チャレンジ文字列をアカウントのパスワードをkeyとしてHMAC-MD5でhashコードを生成する。
ユーザIDとhashコードをスペース連結した文字列をbase64エンコードしてチャレンジ応答とする。
CRAM-MD5でSMTP認証テスト」を参考にして掲載のシェルスクリプトをmacOS Big Sur(11.7.10)で実行したがエラーとなる。
cram-md5.sh
#!/bin/bash

if [ $# -ne 3 ]; then
  echo "構文:"
  echo "cram-md5.sh [ユーザID] [パスワード] [Base64コード]"
  exit 1
fi
USERID=${1:?}
PASSWD=${2:?}
WORD=${3:?}

function hmac-md5() {
  CODE=${1:?}
  KEY=${2:?}
# normal openssl require awk because the output is (stdin)= 'result'
#        echo "$CODE" | base64 -d  | openssl dgst -md5 -hmac "$KEY" | awk '{print $2}'
# openssl in macOS Big Sur
        echo -n "$CODE" | base64 -d  | openssl dgst -md5 -hmac "$KEY"
}

echo
echo "出力:"
echo "以下のコードを貼り付けてください"

echo
echo -n  "${USERID}" $(hmac-md5 "${WORD}" "${PASSWD}") | base64 | tr -d '\n'
echo
echo

exit 0
赤字の修正で正しいレスポンスコードが生成される。
Debian10には、「/usr/bin/gen-auth」がインストールされていた。
/usr/bin/gen-auth
gen-auth cram-md5 someone@somehost.plala.or.jp himitsunokotoba PDk1NTA5Njk2LjM0NjA3MDhAc29tZWhvc3QucGxhbGEub3IuanA+
c29tZW9uZUBzb21laG9zdC5wbGFsYS5vci5qcCA5MTY4ZmZmNWZlNGRiMmEwMDUzN2NlYmI4OGQ5ODg3MA==

echo -n "c29tZW9uZUBzb21laG9zdC5wbGFsYS5vci5qcCA5MTY4ZmZmNWZlNGRiMmEwMDUzN2NlYmI4OGQ5ODg3MA==" | base64 -d
someone@somehost.plala.or.jp 9168fff5fe4db2a00537cebb88d98870
$ openssl s_client -connect somehost.plala.or.jp:587 -starttls smtp -quiet
250 CHUNKING
auth cram-md5
334 PDk1NTA5Njk2LjM0NjA3MDhAc29tZWhvc3QucGxhbGEub3IuanA+
c29tZW9uZUBzb21laG9zdC5wbGFsYS5vci5qcCA5MTY4ZmZmNWZlNGRiMmEwMDUzN2NlYmI4OGQ5ODg3MA==
235 2.7.0 Authentication successful
quit
221 2.0.0 Bye

(2)DIGEST-MD5
DIGEST-MD5(RFC2831)を検索してもコマンドレベルでの確認事例を見つけられなかった。「今更ながら DIGEST-MD5 SMTP認証」が詳細にプロトコルを記載していた。これを参考にDIGEST-MD5を確認してみた(「今更ながら CRAM-MD5 SMTP認証」も参考になった)。
「今更ながらDIGEST-MD5 SMTP認証」には、パラメータ類とhash計算結果が書かれているのでmacOSのopensslを使い計算式をシュミレートしてみた。同記事 「2)レスポンスMD5ハッシュの生成」で式
A1 = { H( { username-value, ":", realm-value, ":", passwd } ),
           ":", nonce-value, ":", cnonce-value }
の H( { username-value, ":", realm-value, ":", passwd } を計算するとHEX表記で
$ echo -n "info.example.com:example.com:userpassword" | openssl dgst -md5
0e50b2e5e12c4b08c865045a4bb780d1
記載値と一致する。この値を使い、HEX(H(A1))値を計算する
md5a1x=`echo -n "info.example.com:example.com:userpassword" | openssl dgst -md5 -binary`
echo -n $md5a1x | od -t x1
0000000    0e  50  b2  e5  e1  2c  4b  08  c8  65  04  5a  4b  b7  80  d1
0000020
echo -n "$md5a1x:JQMKtdgbEhMra4GdAYmAjQ==:lWF{[QuiRj}_L[PW" | openssl dgst -md5
7ab35907e69a040ad638cb3cd61ba9ff
値が違う。。。
示されたハッシュ値は「46 a5 d6 cc c1 56 d8 ca 8d a9 70 72 3d 45 5d 17」
「H( { username-value, ":", realm-value, ":", passwd } )」を「HEX( H( { username-value, ":", realm-value, ":", passwd } ) )」としてハッシュ値を確認もしてみた。
$ md5a1x=`echo -n "info.example.com:example.com:userpassword" | openssl dgst -md5`
$ echo $md5a1x
0e50b2e5e12c4b08c865045a4bb780d1
$ echo -n "$md5a1x:JQMKtdgbEhMra4GdAYmAjQ==:lWF{[QuiRj}_L[PW" | openssl dgst -md5
352faec92f18b88e728c0ae086ead7f5
やはり違うようだ。
同記事「2-2) A2 データ列の生成」の式
A2 = { "AUTHENTICATE:", digest-uri-value }は
echo -n "AUTHENTICATE:smtp/mx.example.com" | openssl dgst -md5
e7280b0554e7e6636bd6a32ec6d5d2cf
で一致する。

smtpコマンドデータを検証するため、XPS8300上のDebian10にpostfixを稼働させ、VAIO上のDebian10を使い、DIGEST-MD5認証でメール送信する設定をしたEvolutionメールツールで送信を行い、Wiresharkでsmtpコマンドをキャプチャして確認した。
auth digest-md5
334 ---challenge(base64)
--- response(base64)
334 ---- rspauth(base64)
\r\n
235 2.7.0 Authentication successful
「auth digest-md5」smtpコマンドに対しサーバーから「334 ---challenge」の応答がある。
base64デコードしてnonce値、realm値を得る。
その他のパラメータは「qop=auth,charset=utf-8,algorithm=md5-sess」。charsetの値は、「"」無し。
responseデータからcnonce値、digest-uri値を得て、opensslで確認すると、式H( { username-value, ":", realm-value, ":", passwd }は、md5バイナリー値にnonce値とcnonce値を":"で結合したデータがA1となる事が判った。 
記事のA1ハッシュ値は、
「46 a5 d6 cc c1 56 d8 ca 8d a9 70 72 3d 45 5d 17」
でなく
「7a b3 59 07 e6 9a 04 0a d6 38 cb 3c d6 1b a9 ff」
となる。従って、「2-3) response ハッシュ値の算出」のハッシュ値は、
「9a ac 0f 21 5f 22 9c f8 20 83 b8 64 72 a2 78 8d」
となる。
「KD は2つの文字列を':'で連結の意」と注釈されているが、「RFC2617の3.2.1 The WWW-Authenticate Response Header」の解説で結合後にハッシュ化した値とされている。

「2-4) サーバに返すレスポンスデータ列の生成(base64)」は、
「dXNlcm5hbWU9ImluZm8uZXhhbXBsZS5jb20iLHJlYWxtPSJleGFtcGxlLmNvbSIsbm9uY2U9IkpRTUt0ZGdiRWhNcmE0R2RBWW1BalE9PSIsY25vbmNlPSJsV0Z7W1F1aVJqfV9MW1BXIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL214LmV4YW1wbGUuY29tIixyZXNwb25zZT05YWFjMGYyMTVmMjI5Y2Y4MjA4M2I4NjQ3MmEyNzg4ZCxjaGFyc2V0PXV0Zi04」
となる。
base64デコード値は、
「username="info.example.com",realm="example.com",nonce="JQMKtdgbEhMra4GdAYmAjQ==",cnonce="lWF{[QuiRj}_L[PW",nc=00000001,qop=auth,digest-uri="smtp/mx.example.com",response=9aac0f215f229cf82083b86472a2788d,charset=utf-8」
(*charset=の値は、「"」でクォートしていない)

記事の「3)認証確認」で「クライアント側は、肯定応答をするために同じように A2 データ列を上記のものに変更したレスポンスハッシュ値を算出し、サーバ側に送り返します。」と解説されていたが、wiresharkの例では、単に「\r\n」を返すだけだった。
「rspauth」は、「A2 = { ":", digest-uri-value }」のハッシュ値(HEX)と定義されている。digest-uri-valueは、変化無いので、
「rspauth=8252052849c337d2b318ef3b11d8db83」
となる。

一応、肯定応答を記事のように作成してみた(base64)
「dXNlcm5hbWU9ImluZm8uZXhhbXBsZS5jb20iLHJlYWxtPSJleGFtcGxlLmNvbSIsbm9uY2U9IkpRTUt0ZGdiRWhNcmE0R2RBWW1BalE9PSIsY25vbmNlPSJsV0Z7W1F1aVJqfV9MW1BXIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL214LmV4YW1wbGUuY29tIixyZXNwb25zZT04MjUyMDUyODQ5YzMzN2QyYjMxOGVmM2IxMWQ4ZGI4MyxjaGFyc2V0PXV0Zi04」
base64デコード値
「username="info.example.com",realm="example.com",nonce="JQMKtdgbEhMra4GdAYmAjQ==",cnonce="lWF{[QuiRj}_L[PW",nc=00000001,qop=auth,digest-uri="smtp/mx.example.com",response=8252052849c337d2b318ef3b11d8db83,charset=utf-8」

(3)DIGEST-MD5のチャレンジレスポンス生成スクリプト
macOSで動作するperlスクリプトを作成してみた
digest-md5.pl
#!/usr/bin/perl
# digest-md5 smtpfqdn userid password challenge
#
use Digest::MD5 qw(md5 md5_hex md5_base64);
use MIME::Base64;

$fqdnhostnm=$ARGV[0];
$userid=$ARGV[1];
$password=$ARGV[2];
$chleg=decode_base64($ARGV[3]);
#----
$chleg =~ /nonce="([^"]*)"/; $nonce=$1;
$chleg =~ /realm="([^"]*)"/; $realm=$1;
$chleg =~ /qop="([^"]*)"/; $qop=$1;
$chleg =~ /charset=([^,]*)/; $charset=$1;
$chleg =~ /algorithm=([^,]*)/; $algorithm=$1;
#----
$cnonce=`openssl rand -base64 16`;
chomp $cnonce;
$md5a1=md5_hex(md5("$userid:$realm:$password"),":$nonce:$cnonce");
$digesturi="smtp/$fqdnhostnm";
$md5a2=md5_hex("AUTHENTICATE:$digesturi");
$md5a2r=md5_hex(":$digesturi");
$response=md5_hex("$md5a1:$nonce:00000001:$cnonce:$qop:$md5a2");
$rspauth=md5_hex("$md5a1:$nonce:00000001:$cnonce:$qop:$md5a2r");
$drx="username=\"$userid\",realm=\"$realm\",nonce=\"$nonce\",cnonce=\"$cnonce\",nc=00000001,qop=auth,digest-uri=\"$digesturi\",response=$response,charset=$charset";
$drxra="username=\"$userid\",realm=\"$realm\",nonce=\"$nonce\",cnonce=\"$cnonce\",nc=00000001,qop=auth,digest-uri=\"$digesturi\",response=$rspauth,charset=$charset";
print "Digest-Response: \n";
print encode_base64($drx,""),"\n";
printf("\nResponseAuth: %s\n",encode_base64($drxra,""));


(4)DIGEST-MD5のチャレンジレスポンス生成スクリプトで接続確認
openssl s_client -connect debian10.familyname:587 -starttls smtp -quiet
depth=1 CN = Private Network CA, OU = Root Certificate Authority, O = 1A72E31E-EA31-4576-AAE6-8C03A00091CD, C = JP
verify error:num=19:self signed certificate in certificate chain
verify return:0
250 CHUNKING
auth digest-md5
334 bm9uY2U9IncxNWdkdm1oeEhKMExwVmVjWWlXbzE3cDNWcmpNZCtXMVI4eWFmeXNHaEk9IixyZWFsbT0iZGViaWFuMTAuZmFtaWx5bmFtZSIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==
dXNlcm5hbWU9InNvbWVvbmVAc29tZWhvc3QucGxhbGEub3IuanAiLHJlYWxtPSJkZWJpYW4xMC5mYW1pbHluYW1lIixub25jZT0idzE1Z2R2bWh4SEowTHBWZWNZaVdvMTdwM1Zyak1kK1cxUjh5YWZ5c0doST0iLGNub25jZT0iQUtFZ0kveEpPRVNTMXNJS0MwRXNhZz09IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL2RlYmlhbjEwLmZhbWlseW5hbWUiLHJlc3BvbnNlPWEwMGYyN2I5NDNjZDk0Nzg4MWE1YzIwNTc0MDlmYWY3LGNoYXJzZXQ9dXRmLTg=

334 cnNwYXV0aD03NGI5Nzg1ZDkxNmUzYTYwMTcxODJhMWZjMGE1MWM2Mg==
--<RETURN KEY>--
235 2.7.0 Authentication successful
レスポンス応答は、RETURN KEYで応答した。
 ./digest-md5.pl debian10.familyname someone@somehost.plala.or.jp himitunokagi bm9uY2U9IncxNWdkdm1oeEhKMExwVmVjWWlXbzE3cDNWcmpNZCtXMVI4eWFmeXNHaEk9IixyZWFsbT0iZGViaWFuMTAuZmFtaWx5bmFtZSIscW9wPSJhdXRoIixjaGFyc2V0PXV0Zi04LGFsZ29yaXRobT1tZDUtc2Vzcw==
Digest-Response: 
dXNlcm5hbWU9InNvbWVvbmVAc29tZWhvc3QucGxhbGEub3IuanAiLHJlYWxtPSJkZWJpYW4xMC5mYW1pbHluYW1lIixub25jZT0idzE1Z2R2bWh4SEowTHBWZWNZaVdvMTdwM1Zyak1kK1cxUjh5YWZ5c0doST0iLGNub25jZT0iQUtFZ0kveEpPRVNTMXNJS0MwRXNhZz09IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL2RlYmlhbjEwLmZhbWlseW5hbWUiLHJlc3BvbnNlPWEwMGYyN2I5NDNjZDk0Nzg4MWE1YzIwNTc0MDlmYWY3LGNoYXJzZXQ9dXRmLTg=

ResponseAuth: dXNlcm5hbWU9InNvbWVvbmVAc29tZWhvc3QucGxhbGEub3IuanAiLHJlYWxtPSJkZWJpYW4xMC5mYW1pbHluYW1lIixub25jZT0idzE1Z2R2bWh4SEowTHBWZWNZaVdvMTdwM1Zyak1kK1cxUjh5YWZ5c0doST0iLGNub25jZT0iQUtFZ0kveEpPRVNTMXNJS0MwRXNhZz09IixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJzbXRwL2RlYmlhbjEwLmZhbWlseW5hbWUiLHJlc3BvbnNlPTc0Yjk3ODVkOTE2ZTNhNjAxNzE4MmExZmMwYTUxYzYyLGNoYXJzZXQ9dXRmLTg=
レスポンス応答を「今更ながら DIGEST-MD5 SMTP認証」記載に従って応答(ResponseAuthを送信)し、認証が成功する事を確認した。

 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

フレッツ光NGNのIPv6(IPoE)インターネット接続業者(VNE)とIPv6 Prefix #4

2023-09-25 23:00:00 | ネットワーク
2023年9月20日 12:34:56にフレッツのprefix情報レコードの更新が行われた。

フレッツ光NGNのIPv6(IPoE)インターネット接続業者(VNE)とIPv6 Prefix #3」と比較して調べてもprefix情報の変更が無い。

2011/01/14 12:59:13 3社VNEでPrefix/23
2013/02/04 12:14:50 3社VNEでPrefix/30に変更
2018/02/02 11:27:52 4社追加され7社VNE体制
2018/08/31 10:03:19 1社追加され8社VNE体制
2020/09/17 09:23:31 1社追加され9社VNE体制
2023/03/22 10:27:31 1社追加され10社VNE体制
2023/09/20 12:34:56 プレフィックス変更なし 謎の「0000」レコード更新
=== NgnRouteInfo ===
0000,2023/09/20 12:34:56--
1111,2404:01a8:7e00:0000:0000:0000:0000:0000/40--東日本電信電話(NTT-EAST)(JPNIC)
1211,2404:01a8:0000:0000:0000:0000:0000:0000/32--東日本電信電話(NTT-EAST)(JPNIC)
1212,2001:0c90:0000:0000:0000:0000:0000:0000/33--東日本電信電話(NTT-EAST)(JPNIC)
1311,2408:0210:0000:0000:0000:0000:0000:0000/30--東日本電信電話(NTT-EAST)(JPNIC)
1411,2400:2410:0000:0000:0000:0000:0000:0000/30--BBIX-IPv6 ソフトバンク(APNIC)
1412,2409:0010:0000:0000:0000:0000:0000:0000/30--MF-Transix-E-1 インターネット・マルチフィード(JPNIC)
1413,240b:0010:0000:0000:0000:0000:0000:0000/30--日本ネットワークイネーヴラ(JPNIC)
1414,2404:7a80:0000:0000:0000:0000:0000:0000/30--ビッグローブ(APNIC)
1415,2405:6580:0000:0000:0000:0000:0000:0000/30--朝日ネット(JPNIC)
1416,2400:4050:0000:0000:0000:0000:0000:0000/30--NTTコミュニケーションズ(OCN)(JPNIC)
1417,2401:4d40:0000:0000:0000:0000:0000:0000/30--フリービット(JPNIC)
1418,2001:0f70:0000:0000:0000:0000:0000:0000/30--アルテリア・ネットワーク(JPNIC)
1419,240b:c0c4:0000:0000:0000:0000:0000:0000/30--RAKUTEN Mobile  Network, Inc(APNIC)
1421,2406:ab48:0000:0000:0000:0000:0000:0000/30--デジタル庁(JPNIC)


 

コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする